Development
React developer for web applications and portals
When the thing you need is closer to an application than a website — a dashboard, a customer portal, an internal tool people use all day — React is usually what it gets built in. I build those, and I join codebases that already exist.
When this makes sense
- A spreadsheet or a manual process has become the tool the team runs on
- Customers need to log in and do something, not only read a page
- You have a React frontend and need someone senior on it who will also go into the backend
- The content only exists once the browser has built it, so Google and the AI assistants see an empty page
How it works
- 01
Scope
We agree what it has to do and what it explicitly does not, in writing. That is what a fixed price is based on.
- 02
Build
Working software in front of you along the way, deployed where you can click it. Changing direction is cheap early and expensive late, so the demos come early.
- 03
Ship
Deployed, documented, and yours — the code and the infrastructure both. You can hand it to another developer whenever you want.
What the work covers
- Frontend and the API behind it, so nothing waits on a second supplier
- Authentication and permissions, with tests covering who can see and change what
- Accessibility and real-device testing, not only a desktop browser
- Tests where breakage costs money, and a deployment anyone on your side can run
- Server rendering or pre-rendering for the pages that have to be found in Google and quoted in an AI answer
React, Next.js or Vue
React is a library for user interfaces and the most widely used of its kind, which means there are many developers who can keep working on what you have built. For an application that users log into and work in all day, a plain React app built with Vite is often the simplest choice. If parts of the same product also need to be found in Google, Next.js, which is built on top of React, is usually better, because the pages are delivered as finished HTML.
Vue solves the same problems as React and is just as good at them. If you already have a Vue application there is rarely a reason to switch. Starting from nothing, I usually recommend React, because the next developer is easier to find and more ready-made components and integrations exist for it. The choice of technology matters less to the result than having the backend, the data model and the permissions thought through from the start.
From spreadsheet to internal tool
A typical React project here starts with a spreadsheet or a collection of forms that a team has built its working day around. It works until two people edit the same file, somebody deletes a formula, or management wants a figure that takes half a day to pull out. The answer is a small system with a real database behind it, login with roles, a history of changes and the screens the team actually uses, and no more.
I build the backend alongside the frontend, usually in TypeScript or Laravel with Postgres, so one person has the whole chain in view. The first version goes live early so the team can use it while the rest is built, and changes are prioritised by what people actually miss in their day rather than by a long list of requirements written in advance.
Common questions
- What does a React application cost?
- It depends on how many screens, kinds of user and integrations the application needs. The scope, the price and the delivery date are agreed in writing before anything is written. Larger applications are split into deliveries, and each part gets its own price.
- Do I need a React application, or would a website do?
- If visitors mostly read, a website is cheaper to build and cheaper to keep. The moment people log in and change things, you are building an application whether you call it one or not, and the cost of pretending otherwise arrives later as a rebuild. I will tell you which one you have.
- Do you do the backend as well?
- Yes. I work across the full stack: Node and TypeScript, PHP and Laravel, Python, Go, with Postgres or MySQL underneath. Most of the expensive problems in a web application live at the seam between frontend and backend, which is exactly where handing the two halves to different suppliers hurts.
- Can you take over or join an existing React codebase?
- Yes, and it is a large part of the work. It normally starts with a technical review — I would rather know what is in there than promise a delivery date over code I have not read.
- Can Google and ChatGPT read a React application?
- Only what is served as HTML. A pure client-side app ships an empty shell and builds the content afterwards — Google runs JavaScript on a later pass and not always, and most AI assistants do not run it. For a dashboard behind a login none of that matters, and no hours should go on it. If part of the product has to be found from outside — prices, services, a catalogue, a blog — those pages get server-rendered or pre-rendered, with markup and an /llms.txt on top. It is the same work as the technical SEO and GEO engagement.
- Which React setup do you use?
- Whatever the project is already on, if it is on something. For new work: TypeScript throughout, a real router, TanStack Query for server state, and Tailwind. This site runs that stack, server-rendered, so you can look at the result before you buy it.
Other stacks I work in
Not sure which one to pick?
Send a couple of lines about what you are trying to achieve. You get a reply within 24 hours, and an honest yes or no.