Headless CMS Development

Most content teams we meet are choosing between two frustrating options. A WordPress install gives editors a familiar screen, then slows the public site down with plugins and turns every theme change into a risk. A hand-coded site loads fast, but a changed opening hours line becomes a developer ticket.

A decoupled build splits those halves. Editors work inside a content platform such as Strapi, Sanity, Contentful, or WordPress running headless. The public site is a Next.js or React application that reads that content through an API.

What a decoupled build is

Content lives in one system and is delivered as JSON over REST or GraphQL. The front end fetches it at build time, at request time, or through a mix of both. Because the halves share only an API contract, either side can be replaced later.

We pick the platform around the editing team. Strapi keeps the content in your own database with hosting you control. Sanity gives you a hosted editor and an exportable dataset. Contentful fits larger editorial operations with several locales and review steps. Headless WordPress is the practical answer when the content team already knows WordPress. All of it sits on our web development work, so the front end, the API layer, and the deployment come from one team.

Who it is for

This model pays off when more than one person publishes, when content appears in more than one place, or when a faster front end changes business numbers. Typical cases:

• A company site with a marketing lead, a technical writer, and an outside agency editing pages
• A multilingual site where one product description feeds three languages
• A catalogue, job board, or marketplace where listings are structured records
• A product whose marketing site and web app share the same copy and images

It also fits builds where the front end does real work: search, filtering, or a checkout that shares content with marketing pages. That work is usually part of a larger corporate website development engagement.

When a monolith is the better decision

A monolith renders pages and serves the admin screen from one codebase. WordPress with a theme is a monolith, and so is a Django application with an admin panel.

We recommend that route when a handful of pages change a few times a year, when one or two people do all the editing, or when two systems and two hosting bills cannot be justified. A small site that rebuilds on every typo is slower to run than it needs to be. We say so and quote a WordPress or plain Next.js build instead.

What we deliver

Content modelling

We write the content types down before anyone builds a screen: fields, references, required values, validation, locales, and editor roles. A post referenced by an author and a category is a different model from a landing page that owns its blocks. Getting that shape right early keeps the front end free of special cases for years.

Preview and publishing workflow

Editors get draft and publish states, scheduled publishing, revision history, and permissions so an intern cannot push live by accident. Preview URLs render unpublished drafts in the real page layout, header and footer included, so approval happens on the page that will go live.

Build triggers and caching

Publishing fires a webhook. Depending on the route it calls a deploy hook for a full rebuild, an incremental revalidation endpoint for one page, or nothing when the page renders on request. A news archive and a homepage hero tolerate staleness differently, so we set the strategy per route and document it. Caching is configured at the CDN and API level so one change appears quickly without rebuilding the whole site.

Image pipeline

Uploads produce responsive renditions at the platform level, and the front end requests the size and format it needs, including AVIF and WebP where the browser supports them. Every image carries its width and height so the layout does not shift while pictures load.

Search, forms, and integrations

When your content has to be searchable, we index it and wire the search interface to that index. Forms, CRM handoff, translation, and payments sit behind the API layer, which we cover under API development and integration.

Migration and handover

We export content from your current site, reshape it into the new model, and redirect the old URLs, work that overlaps with CMS migration. At handover you get editor training, the content model documentation, and ownership of the CMS account, repository, and hosting.

How an engagement runs

Discovery takes about a week: content inventory, models, hosting decision, and which routes need instant updates. You see the content model and URL structure before design starts.

Build follows in two to four weeks for a site with an existing design, longer with a design phase or custom listing logic. We build the front end against a small set of real content, then connect the full set. Editors get a working session on the preview workflow before launch.

Launch is a staged cutover: staging URL, content migration, redirect check, then the DNS switch. We watch build times and revalidation for the first week, since that is when a missed webhook shows up.

What it costs

Headless work is quoted at our flat rate of $39 per hour, or as a fixed scope once we have seen the content model and the page list. Scope drivers are the number of content types, locale variations, workflow complexity, and whether the front end is a new design. Most engagements run between two and six weeks. A multi-page platform with editorial workflow and integrations lands in the range published in the hybrid platform typical order on our pricing page, which also lists monthly capacity plans from $2,699.

Running costs and rebuild latency

Running costs arrive as two bills. The content platform is either self-hosted, where you pay for a server or a managed host, or a hosted plan priced by seats and API usage. The front end runs on Vercel, Netlify, or Cloudflare Pages, where a site of this size usually fits a free tier.

Rebuild latency grows with page count. Incremental revalidation updates one page in seconds. A full rebuild of a few hundred pages takes a few minutes, and a site with thousands of pages takes longer than editors will accept, which is why we route those to request-time rendering. A published change should appear within seconds to minutes.

Proof

design.vasilkoff.com is our own designer portfolio, built on Next.js and served from Vercel with no database of its own. It proves the front-end half of this service in production: pre-rendered pages, no server to patch, and hosting that costs us nothing.

Vasilkoff.info is our AI estimator and support application, built on Next.js with its logic and data behind separate services and packaged as a widget other front ends can embed. It shows the same separation at application scale.

Related services

• Web development for front-end and back-end engineering across the rest of our stack
• Corporate website development for multi-page business sites with editorial teams
• API development and integration when the content API has to reach a CRM, search index, or third-party service
• Website speed and performance optimization for caching and image delivery work on an existing site
• Zero-maintenance static website when content rarely changes and a Markdown workflow is enough

Next step

Bring us the content types you think you need and the pages that have to render fast. We will say which parts belong in the CMS, which belong in code, and whether a monolith would serve you better.

Contact us with a link to your current site and a description of who edits it, or run the scope through the Vasilkoff.info estimator to get a first cost range before the call.