Why we built centr8.com on Next.js and Sanity

When you build software for a living, your own website becomes an awkward audition. Every prospect who lands on it is, consciously or not, judging whether the team behind it actually knows what it's doing. So when we sat down to build centr8.com, we treated it like a client engagement: define the constraints first, then choose the stack that fits them — not the other way around.

This is the honest version of how that went. We landed on Next.js for the front end and Sanity for content. Here's why each earned its place, where each made us compromise, and what the combination actually delivers in production.

The constraints we started with

Before naming a single technology, we wrote down what the site had to do. A marketing site for a technology firm has a specific job: rank in search, load instantly on a mid-range phone over a patchy connection, and let a small team publish case studies and articles without filing a ticket with engineering. Those three demands quietly eliminate a lot of popular options.

• SEO is non-negotiable. Most of our prospects find us through a search query, so pages have to render meaningful HTML on the server — not a blank shell that hydrates a second later.
• Speed is a feature. A slow site reads as a slow team. We wanted sub-second loads on the pages that matter and a Lighthouse score we wouldn't be embarrassed to screenshot.
• Content has to move without us. Marketing should be able to ship a new article or tweak a service page without a deploy, a developer, or a 2am Slack message.
• It has to scale down, not just up. This is a brochure-and-blog site today. Over-engineering it with a heavyweight CMS and a dozen microservices would have been a self-inflicted maintenance bill.

Why Next.js for the front end

Next.js solved the first two constraints in one move. Its hybrid rendering means we choose the right strategy per page rather than committing to one: static generation for the marketing pages that rarely change, and incremental regeneration so a freshly published article goes live without rebuilding the entire site. The result is pages that arrive as complete, crawlable HTML — exactly what search engines and a user's first paint both want.

Just as important, it's a stack our team already reasons about fluently. A framework you understand deeply is worth more than a marginally "better" one you'd be learning on the job. Concretely, Next.js gave us:

• Server-rendered, fully indexable pages out of the box — no client-side SEO workarounds.
• Automatic image optimization and code-splitting, so we ship the smallest payload that still looks sharp.
• A single codebase and deploy pipeline for the whole site, instead of stitching together a separate front end and API layer.
• A massive, well-documented ecosystem — when something breaks at 11pm, the answer usually already exists.

Why Sanity for content

The CMS choice is where teams most often over- or under-buy. A traditional, monolithic CMS would have coupled our content to its own theming system and fought us on every custom layout. We wanted the opposite: a clean content API our Next.js front end could consume freely, with editing that non-developers actually enjoy.

Sanity is a headless, API-first CMS, and that decoupling is the entire point. Content lives as structured, queryable data; the front end decides how to present it. For a small team publishing case studies and articles, the practical wins were clear:

• Editors get a fast, real-time editing studio — no rebuilds to preview a change.
• Content is structured and versioned, so a case study and a blog post share predictable fields instead of free-form HTML blobs.
• Its query language makes it trivial to pull exactly the data a page needs, and nothing more.
• The studio is itself just code we host, so the editing experience evolves alongside the site rather than locking us into a vendor's UI.

The trade-offs we accepted

No stack is free. Being honest about the costs is part of the point of writing this. A headless setup means content and presentation live in two places, so a brand-new content type requires both a schema change in Sanity and front-end work to render it — more moving parts than an all-in-one platform. There's also a real learning curve: Sanity's query language and Next.js's rendering modes both reward people who take the time to understand them, and punish those who copy-paste. And because we own more of the plumbing, we own more of the maintenance — keeping framework versions current is now our job, not a vendor's.

We took those trade-offs deliberately. For a technology firm whose site is also a portfolio piece, control and performance were worth more than the convenience of a turnkey builder. For a different business — a five-page brochure site with one editor and no growth plans — we'd often recommend something simpler, and we'd say so.

What it buys, and where to go next

The payoff is a site that loads fast, renders clean HTML for search engines, and lets our team publish without a deploy — while staying small enough that one engineer can hold the whole thing in their head. That's not the right answer for every project, but it was the right answer for ours, and we can defend every line of it. If you're weighing a similar build and want a partner who'll be this candid about the trade-offs before writing any code, that's exactly what our Web & Mobile App Development work is built around.