App Router applications built the way the framework intends, by someone who ships them to production rather than to a preview URL.
Next.js rewards getting a few decisions right and punishes getting them wrong for the life of the project. Where state lives, what renders on the server, how data is cached and invalidated: these are not refactors you do later, they are the shape of the application.
I build App Router applications in TypeScript, on current versions rather than the patterns that were current two majors ago. This site runs Next.js 16 with React 19 and Tailwind CSS 4, including the parts most projects avoid: server components talking to a real database, streamed rendering, and a build that produces a standalone container.
Frontend work here is not decoration over somebody else’s API. It comes with the data layer attached, which is usually where the performance problems actually are.
Concretely, what is in the box. Anything not listed is worth asking about rather than assuming.
Server and client components split along the line that makes sense for your data, route handlers, server actions for mutations, and layouts that do not re-fetch the world on every navigation.
Static, dynamic, streamed or revalidated, chosen per route and justified. Cache invalidation wired to your writes so content updates without a deploy.
Core Web Vitals treated as a requirement. Bundle splitting, image handling, font loading and the request waterfalls that quietly dominate real load times on mid-range phones.
Server-rendered content crawlers can read, metadata and canonicals handled per route, structured data that matches what the page actually says, and a sitemap that reflects real content.
Keyboard reachable, visible focus, and contrast verified against WCAG AA with axe-core rather than estimated by eye. Interactive enhancements that degrade to working HTML when JavaScript does not run.
Pages Router to App Router, and major version upgrades where the breaking changes are real: proxy replacing middleware, Turbopack builds, Tailwind 4’s CSS-first config.
The same five steps every time. The point of writing them down is that you can tell where a project is without asking.
Thirty minutes on what you are building, who it is for, and what has to be true for it to count as done. You leave with a written scope and a rough shape of the work, whether or not we go ahead.
Data model, API surface, auth model and hosting decided before any feature code. This is where the expensive mistakes get made, so it happens in writing first.
Work ships to a staging URL continuously, not in one reveal at the end. You see progress weekly and can redirect while redirecting is still cheap.
Auth and access control, input validation, rate limiting, error handling and the failure paths that only show up under real traffic. Treated as part of the build, not a later pass.
Containerised deploy, TLS, backups and a written runbook, into your infrastructure or mine. You get the repo, the credentials and a document that explains how to run it without me.
Every claim on this page points at something you can read. These are the three that matter most here.
Commit runs on Next.js 16 with Convex, Clerk and the Stream video SDK, with a synchronised Monaco editor, role-based routing enforced before a protected page renders, and a standalone container build. The site you are reading now runs the same major version against PostgreSQL through server components.
Read the Commit case studyAt NSEG Pvt Ltd, lifting shared state into React Context cut redundant API calls from fifteen or sixteen per page to a single request on initial render, removing repeat fetches across navigations and the server load that came with them.
See the full resumeIntegrating a rich-text editor into a Next.js application meant resolving SSR hydration mismatches and keeping editor content synced to controlled form state, then handling the image lifecycle so deleted posts did not leave orphaned uploads behind.
See the full resumeThree shapes cover almost everything. Which one fits is usually obvious within ten minutes of the first call.
You know roughly what you want built
A written scope, a milestone schedule and one price agreed before work starts. Best when the requirements are stable enough to write down.
Ongoing product work
A set number of days a month on a standing backlog, re-prioritised as you learn. Best when the roadmap is still moving.
One defined problem
A performance problem, an auth rebuild, a deployment that needs to stop falling over. Scoped in days, not months.
There is no fixed price list here, because a number quoted before the scope exists is a guess dressed up as a quote. These are the things that actually decide it:
The questions that come up on nearly every first call.
App Router for new work. I take on Pages Router codebases for maintenance and for migrations, but I would not start something new on it today.
Yes, and it starts with a read-through and a written assessment rather than an immediate estimate. Most inherited Next.js projects need the data and caching strategy settled before anything else is worth doing.
Yes. It is worth saying that many problems that look like frontend problems are shaped by the API, so expect feedback on the endpoints where it would change the result.
Content renders on the server so crawlers see it without executing JavaScript, metadata and structured data are handled per route, and Core Web Vitals are treated as a requirement. Rankings depend on far more than the build, so I will not promise positions.
Vercel where that suits you, and self-hosted Docker on a Linux VPS behind Nginx where cost or data residency rules it out. This site is the second kind.
Tell me what you are building and what has to be true for it to count as done. You get a straight answer on fit and timing, including when the answer is no.