Every site I build is a Next.js application using the App Router, TypeScript, and Tailwind. It goes into your GitHub organisation and deploys to your Vercel account. There is no proprietary layer, no subscription required to keep your own website online, and no export step that produces unusable code.
This matters more than it sounds. The most common expensive problem in early-stage marketing sites is a site trapped in a tool the team cannot modify, at exactly the moment they need to move fast.
Static by default, dynamic only where it earns it
Marketing pages are prerendered at build time and served as static HTML from the edge. There is no server round trip and no client-side data fetch standing between a visitor and your headline.
Dynamic rendering is used only where it is genuinely required — a personalised dashboard, live data, a preview environment. Applying it uniformly across a marketing site is the most common cause of a slow Next.js app.
The JavaScript budget is a real constraint
React components that do not need interactivity render on the server and ship no JavaScript at all. Components that do — a carousel, a pricing toggle, a mobile menu — are isolated as client components and loaded only where used.
A marketing site done this way typically ships under 100kb of JavaScript. The same site assembled in a page builder frequently exceeds a megabyte, and most of that weight is spent rendering text.
A CMS your marketing team can use without asking an engineer
If the site needs a blog, changelog, or editable pages, I wire a headless CMS — usually Sanity or Payload — with schemas shaped around your content rather than a generic page builder. Editors get structured fields and live preview, and cannot accidentally break the layout.
For teams comfortable with pull requests, MDX files in the repo are often simpler and free. Which is right depends on who publishes, not on which is technically nicer.
Handoff that assumes I disappear
The code uses ordinary Next.js patterns with no unusual abstractions, so any React developer can pick it up. The README covers running it locally, where content lives, and how to deploy.
This is deliberate. A studio that makes itself difficult to replace has misaligned incentives — you should keep working with me because the work is good, not because leaving is expensive.