Two of our own projects sit at opposite ends of the same decision, and looking at them side by side is a better answer to "should I use a CMS or build my own" than any generic advice would be — because we made a genuinely different call on each, for reasons specific to what each business actually needed.
This site: a headless CMS, because the content is the variable
This site runs on Sanity, a headless CMS: content is authored in a structured schema — every page's copy, every case study, every blog post — and served over an API to a Next.js frontend we control completely. The reason a headless CMS was the right call here is specific: what changes on a marketing site is almost entirely content — new case studies, updated copy, a new blog post — while the structure (how a case study page is laid out, what a pillar page contains) changes rarely. Sanity draws exactly that line: editors get a clean interface for the part that changes often, developers keep full control of the part that doesn't, and a built-in fallback means a CMS outage never takes the actual site down.
TG Spaces: a custom admin panel, because the logic was the product
TG Spaces is a different kind of build entirely. It's a booking and events platform we built end-to-end for a Dutch co-working and creative venue, and its core isn't content — it's business logic: a booking lifecycle with payment and access state, Google Calendar availability sync across multiple studios, invoicing with discount ledgers, role-based staff access. None of that maps onto "content that needs editing." It maps onto a system that needs to behave correctly under real operational rules. So instead of reaching for a generic CMS and bending it to fit, we built a 24-section admin panel from scratch on Next.js, Prisma, and Supabase — purpose-built for exactly what the venue's business actually does, with the public marketing site as one module inside a much larger system.
The tradeoff there is real and worth naming: a bespoke system costs more upfront than a generic CMS, and it depends on the codebase staying well-organized as it grows — which is why TG Spaces was built on strict "single source of truth" conventions from day one: typed registries for statuses and permissions, pure business logic kept separate from framework code, a generated map of the whole system. Skip that discipline on a custom build and you get something that's expensive to maintain forever. Keep it, and a custom system stays as easy to extend in year three as it was in month one.
The actual question to ask
Not "CMS or custom build" as an abstract preference — "is what changes here content, or behavior?"
- If most of what will change over the site's life is words, images, and structured content — a case study, a price, a new page — a headless CMS gives editors real independence without touching code, and gives developers a stable content contract to build against.
- If what actually needs to change is business logic — how a booking is validated, what happens when a payment fails, who's allowed to see what — no CMS is going to model that well. That's a case for a purpose-built system, accepting the higher upfront cost in exchange for logic that fits the business instead of the business bending to fit a generic tool.
Most sites are more of the first than people assume, and most people default to the second because "we're building an app" feels more serious than "we're managing content." The mismatch — a custom-built system carrying what was really just a content problem, or a generic CMS straining to model real business logic — is where a lot of unnecessary cost quietly accumulates.