Step 01
Scope
Agree routes, rendering strategy and where data comes from.
Production React, not a prototype that happens to run.
Next.js and React development for web applications and marketing sites - typed, accessible, server-rendered where it helps, and built to be maintained.
React is where most product interfaces live, and Next.js is the framework that makes React practical in production: routing, rendering strategy, data fetching and deployment handled without assembling it yourself.
I build the interface layer - components, state, forms, routing and integration with your API or CMS - with the same attention to the design detail I would apply as a designer, because I am one.
The usual pipeline loses fidelity at the handoff. A developer makes a hundred small judgement calls the design did not specify - what happens at an awkward width, how a long string wraps, what the loading state looks like - and each call is a chance to drift.
When the same person designs and builds, those calls get made by someone who knows the intent. It is also faster, because the specification conversation between two people simply does not need to happen.
Next.js lets you render statically at build, on the server per request, or on the client, and mixing these correctly is most of what separates a fast site from a slow one.
Marketing pages are usually static. Dashboards behind a login are usually client-rendered or server-rendered per request. Content that changes occasionally sits well with incremental regeneration. I choose per route rather than applying one strategy everywhere.
TypeScript throughout, so refactoring is safe. Components that cover their real states rather than only the happy path. Forms with proper validation and error handling. Accessible markup - semantic elements, keyboard navigation, focus management and sensible labelling.
Accessibility in particular is treated as part of the build rather than an audit at the end, because retrofitting it is considerably more expensive than doing it as you go.
On an existing codebase I start by reading it and matching its conventions rather than importing my own. A contribution that looks foreign to the rest of the repository creates maintenance cost long after I have moved on.
I am comfortable joining an existing team and process - code review, branching conventions, whatever you already run.
Yes. I start by reading the codebase and matching its existing conventions rather than importing my own, because contributions that look foreign to the rest of the repository create maintenance cost after I leave.
Astro for content-led sites where shipping minimal JavaScript matters most: marketing sites, blogs, documentation, portfolios. Next.js where you need application behaviour - authentication, dashboards, server-side logic or API routes. Many projects legitimately could use either.
Yes, by default. Typed code is meaningfully safer to refactor, which matters most on exactly the projects that live long enough for someone else to maintain them.
How a next.js & react development engagement actually runs, start to finish.
Agree routes, rendering strategy and where data comes from.
Develop typed, accessible components against the design.
Wire the CMS or API, handle loading and error states properly.
Test across devices, measure performance, deploy.
Full Time Contract Available. Tell me about your project, your timeline and your budget, and I’ll reply with an approach and a rate.
Start a project
