Services / Next.js work
For when you already know what you want built on.
Next.js and React work for teams who have picked the stack: new builds, migrations off WordPress, and filling a gap on an existing codebase.
- Best for
- Teams and founders who have already settled on React or Next.js and want someone who works in it daily.
- What it costs
- Fixed price against a written scope for defined pieces of work. Open-ended work on someone else's codebase is quoted in short blocks so you can stop after any of them.
- How it runs
- A new build follows the same two to four week shape as any site. Work on an existing codebase starts with a week of reading before I promise anything.
01 / Summary
The short version
If you have arrived at this page you probably do not need convincing about the stack, so this is about what the work looks like.
Most of what I ship runs on Next.js App Router with TypeScript, and the site you are reading is one of them. Server rendering is the default, so these pages arrive as finished HTML instead of an empty shell that fills in later. It matters for what Google indexes and for what the first second feels like on a phone.
If what you need is five pages of text and a contact form, this is the wrong page. A static site builder will cost you less and I will tell you so on the call.
02 / Deliverables
What you get
- 01New builds on Next.js App Router with TypeScript throughout
- 02Migrations from WordPress, Wix or a legacy React app, with redirects mapped so you keep your search positions
- 03Server components, streaming and caching set up deliberately, not left on defaults
- 04Contract work inside an existing codebase, matching the conventions already there
- 05Playwright or Vitest coverage on the paths where a failure costs you something
- 06Deployment on Vercel or wherever you already are, in your account
03 / Process
How it runs
- Step 01
Call
What exists now, what has to keep working, and who else touches the code.
- Step 02
Read
On an existing codebase I read before I quote. You get a short written note on what I found, including anything I think is a problem.
- Step 03
Scope
Pieces of work small enough to finish and check, each with a price. You approve them one at a time or all at once.
- Step 04
Ship
Preview deployments per change, so review happens on a URL rather than in a meeting.
05 / Questions
Common questions
01Can you work inside our existing repository?
Yes, and that is a good deal of the work. I match the conventions already in the codebase and leave my own preferences at the door. On AtTalentFit other developers built against interfaces I wrote, and nothing merged unread. If your team has a review process, I go through it like anyone else.
02We are on WordPress. Is moving worth it?
Sometimes. Moving is worth it when the site is slow in a way that plugins cannot fix, when editing has become frightening, or when you are paying for hosting that scales badly. It is not worth it when WordPress is doing the job and the real problem is the content. I will say which one I think you have.
03What happens to our Google rankings if we migrate?
They survive if the migration is done properly, which mostly means mapping every old URL to a new one with a permanent redirect and keeping the page titles and headings intact. Rankings drop when someone launches a new site with new URLs and no redirects. That is a planning failure rather than something inherent to migrating.
04Do you use the App Router or the Pages Router?
App Router for new work. If you are on Pages Router and it is working, there is no urgent reason to move, and a partial migration is a normal way to live for a long time.
05Can you just review what we have?
Yes. A read of the codebase with written findings is a small fixed piece of work and it is often the honest first step. Occasionally the finding is that you do not need me.