When to go headless (and when not to)

Every few months a founder arrives in our inbox asking whether they should "go headless." Usually they've heard the word at a conference, read a blog post from a Contentful sales team, or watched a competitor rebuild their site with some exotic stack.

The honest answer is: probably not yet. Here's how to actually think about it.

What "headless" means

A traditional CMS like WordPress couples the content management backend with the frontend rendering. The CMS decides how your content looks, where it goes, and handles the HTTP responses.

A headless setup decouples these. Your content lives in a backend (Contentful, Sanity, Strapi, or a custom API) and your frontend fetches it via API - typically at build time or request time. The frontend can be anything: Next.js, a native app, a digital signage screen, a voice assistant.

That decoupling is the point. But it comes with real costs.

The case for headless

You're publishing to multiple surfaces. If your content needs to appear on a web app, a mobile app, and a third-party integration simultaneously, a headless CMS with a single content API is the right answer. Maintaining separate WordPress installs for each is a maintenance nightmare.

You need fine-grained frontend performance control. Headless gives your frontend team full control over rendering strategies - static generation, streaming, incremental revalidation - without workarounds. You decide exactly what gets cached, when, and how.

Your editorial and engineering teams are separate. A well-configured headless CMS (Sanity's Studio, Contentful's web app) gives non-technical editors a clean interface without exposing them to WordPress PHP internals or template files. When your content team is five people, this matters.

You're building a product, not a brochure. If your "website" is really a product - user accounts, dynamic data, real-time content - a headless architecture keeps your content model separate from your application logic.

The case against headless (for most startups)

You're a team of two and you need to ship in six weeks. Headless is genuinely more complex. You need to configure a CMS, design a content schema, build API integrations, and handle edge cases like draft previews. That's 2–3 weeks of work before your designer has placed a single component.

Your content rarely changes. If your marketing site has eight pages and your team updates them quarterly, the editorial flexibility of a headless CMS adds no value. The content won't outpace the developer.

You don't have a content team yet. Headless CMSs are optimised for editorial workflows. If "the content team" is the founder writing copy in a Notion doc and pasting it in, you're adding complexity for zero benefit.

You're pre-product-market fit. Your information architecture will change ten times before you find PMF. Headless content schemas are harder to restructure than markdown files or a simple WordPress template. Premature optimisation applies to content architecture too.

The decision framework

Ask these questions in order:

1. Are you publishing to more than one surface? If yes, headless is worth considering. If no, keep reading.
2. Does your frontend team need full rendering control? If yes (you care deeply about performance, ISR, streaming), headless is worth the overhead. If no, a traditional or hybrid approach is fine.
3. Do you have a non-technical content team today? If yes, a headless CMS with a good editing UI adds value. If no, MDX files or a simple solution may be faster.
4. Will you have this problem in six months, or do you have it now? If it's a future problem, solve it in the future. Build what you need today.

The middle path: Next.js with local content

For most startups we work with, the right answer at the beginning is Next.js with local content files - MDX for blog posts, TypeScript data files for structured content - deployed to Vercel. You get full rendering control without a CMS dependency.

When you've hit product-market fit, you have a content team, and you're publishing to multiple surfaces, that's when you migrate to Sanity or Contentful. The migration is straightforward because your Next.js structure doesn't need to change - you're just swapping where the data comes from.

This is the path we follow for Titung's own site.

When we recommend Sanity specifically

If a client is ready for headless, we default to Sanity. Reasons:

• GROQ query language is more expressive than GraphQL for most content use cases
• Sanity Studio is fully customisable React - you can build exactly the editorial UI your team needs
• Real-time collaboration with no conflict resolution headaches
• Portable Text handles rich content without locking you into a rendering framework

Contentful is a fine alternative if you're already in a corporate procurement process. We don't recommend Strapi for hosted projects - too much infrastructure overhead for what you get.

The bottom line

Headless architecture is a real solution to real problems. But it's a solution for a specific stage of scale, not a default starting point. Build the simplest thing that works, keep your architecture reversible, and add headless when the complexity pays for itself.

Most startups that come to us asking for headless don't need it yet. We tell them that - even when it means a smaller initial project.

Architecture decisions like this one are part of our Custom Builds service - we help you pick the right stack for where you actually are, not where a conference talk says you should be.

---

If you're not sure which architecture is right for your situation, tell us about your project and we'll give you a straight answer.