Everything is a client component
The whole tree marked as client-side, so the server rendering you are paying for does almost nothing.
[ Development / Next.js Development ]
Next.js that is fast in production too.
Next.js gives you four ways to render every page and no warning when you pick the wrong one. Most slow Next.js sites are not slow because of the framework — they are slow because of a rendering decision made early and never revisited.
Free build review · Fixed scope · Measured results
Freebuild and vitals review
Correctrendering per route
Measuredbefore and after
You ownthe repository
[ What goes wrong ]
Where Next.js projects go sideways.
The framework is not the problem. These six decisions usually are.
Slow first load
Huge JavaScript bundles shipped for pages that are mostly static text.
Data fetched in waterfalls
Sequential requests that could run in parallel, each one adding to time-to-content.
Builds that take forever
Full static generation of thousands of pages on every deploy, so shipping a typo fix takes twenty minutes.
Caching nobody understands
Stale content in production, or no caching at all, because the caching model was never deliberately chosen.
SEO quietly broken
Metadata generated client-side, so crawlers see an empty shell where the content should be.
[ How it works ]
Review, restructure, measure.
01 — Week 1
Review
Rendering strategy per route, bundle composition, data-fetching patterns and Core Web Vitals from real users. You get a written report with the impact of each fix.
02 — Week 2+
Build or fix
New features built, or the existing app restructured route by route, shipped as reviewable pull requests rather than one enormous branch.
03 — Launch
Verify
Real-user metrics compared before and after, build times measured, and the reasoning documented so the next developer keeps the decisions intact.
[ What actually changes ]
What I actually change.
Rendering strategy first, because it determines everything downstream. Micro-optimizations come last and matter least.
Architecture
- Rendering strategy per route — static, revalidated, streamed or dynamic, chosen deliberately.
- Server and client boundaries — interactivity isolated so most of the tree stays on the server.
- Parallel data fetching — waterfalls removed, with suspense boundaries where streaming helps.
- Caching and revalidation — a deliberate model per data source rather than framework defaults.
- Route and bundle splitting — so one heavy page cannot slow down every other page.
Delivery
- Core Web Vitals — largest paint, interaction latency and layout shift measured on real devices.
- Image and font optimization — correct sizing, modern formats and no layout shift on load.
- Metadata and structured data — rendered server-side so crawlers actually see it.
- Build time reduction — incremental generation instead of rebuilding everything on every deploy.
- Deployment — to your platform of choice, whether that is a managed host or your own AWS setup.
[ Example engagement ]
Twenty-minute builds down to three.
A marketing and docs site statically generating every page on each deploy, with most components marked client-side. Restructured with incremental regeneration and proper server components.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
3 minbuild time, from 20
68%less JavaScript shipped
1.1slargest contentful paint
All 3Core Web Vitals passing
[ Free · 48 hours ]
Get a build and vitals review.
Point me at your repository or live site. You get a written review of rendering strategy, bundle size and Core Web Vitals, with the fix ranked by impact.
[ Pricing ]
Pricing that fits your budget.
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Fixed project price
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
Monthly retainer
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
Hourly for small jobs
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Common questions.
App Router or Pages Router?
App Router for new projects. For an existing Pages Router application that works well, migrating purely for its own sake is rarely worth the disruption — the two can also coexist during a gradual move.
Do we have to host on a specific platform?
No. Managed platforms are convenient and often the right answer, but Next.js runs perfectly well in a container on your own infrastructure, and I can set either up.
Can you work with our design team?
Yes. I build from designs in any standard format, and will flag where a design will cost you performance before it gets built rather than after.
React or Next.js for our project?
If you need SEO, server rendering or routing, Next.js. If you are building an internal dashboard behind a login where none of that matters, plain React with a lighter setup is often simpler and cheaper.
Can you fix an app someone else built?
Yes, and that is most of this work. The review comes first so you know what you are buying before committing to the fix.
[ Related services ]
Related development work.
React DevelopmentComponent work, state architecture and performance fixes.Node.js DevelopmentAPIs, services and background workers that stay up.Laravel DevelopmentAPIs, dashboards and long-term maintenance of Laravel apps.Shopify DevelopmentTheme work, custom apps and checkout that converts.CI/CD & GitHub ActionsAutomated build, test and deploy pipelines with real rollbacks.WordPress DevelopmentCustom themes, plugins and integrations built to be maintained.
[ Let's talk ]
Tell me what you're building.
Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.