A straight recommendation before any build
A comparison of a headless build against a conventional one for your specific case, including the version of the answer where you do not need this at all.
Web development
A separate front end, only when the reason is real
Splitting the front end from the CMS solves a genuine problem for some teams and adds a build pipeline to everyone else's life. We do headless and static work for the first group, and we tell the second group plainly which one they are in.
Who this is for
For teams whose content already has to appear in more than one place: a website, an app, a partner feed, or several country sites drawing on one library. On a brochure site or a single marketing build it adds a pipeline and a second thing to maintain for no gain, which is an answer we give more often than the other one.
What you get
What we deliver
A front end you can deploy on its own
A static or hybrid front end on a mainstream framework, deployed independently of the CMS, so a content change and a code change never queue behind each other.
The editor your team already knows
WordPress can stay exactly where it is as the content back end, so the people writing keep the screens they were trained on and only the public front end changes.
Preview that shows the real page
Editors see unpublished changes rendered on the actual front end before they publish, rather than guessing from a CMS preview that looks nothing like the live site.
Publishing that rebuilds only what changed
Hitting publish triggers a build of the affected pages rather than the whole site, so fixing a typo does not mean waiting for every page to regenerate.
The dynamic parts still working
Forms, search, carts and logged-in areas run against APIs on the routes that need them, so the marketing pages stay static without giving up anything interactive.
One library, several front ends
Companies here rarely publish to one destination. The same product story has to appear on the website, on a Facebook page, on a marketplace listing, and sometimes on a separate site aimed at overseas clients or an app a partner controls. When a description changes and four places have to be edited by hand, one content source feeding several front ends is a structure rather than a fashion, and that is the case worth building for. The second reason is geography. A dynamic page whose origin sits abroad pays for a trip to another country on every request, while a static build is just files, which a content delivery network can hold at a point of presence in or near the region. Neither reason is about which framework is currently fashionable.
Questions
What people ask before they buy this
Do our editors lose the WordPress editor?
No, unless you want them to. In most of these builds WordPress stays in place as the content back end and only the public front end is replaced, so nobody has to relearn how to publish. Moving to a different CMS is a separate decision, and it should be made deliberately, not arrive as a side effect of a technical choice.
Can a static site still handle payments, forms and logins?
Yes. Static means the page shell is built ahead of time, not that the page is inert. Checkout, search, forms and member areas run against APIs from the browser or from a small server function on just those routes. The pages that never change stay prebuilt, and the pages that must change stay live.
How long does a content change take to appear?
As long as the build takes for the pages you touched, which is why builds are set up to regenerate only the affected pages. Content that must be accurate to the second, such as stock levels or prices, is fetched at request time instead of baked into the build. The real work is agreeing upfront which content is allowed to be a few moments old.
Will this actually be faster for visitors here?
A static build takes the server work out of the path, and the files can be cached at a point of presence much closer to your audience than an origin server in another country. That is a real gain when your origin is overseas and most of your traffic is not. It is not a substitute for keeping the page light: a heavy static page is still a heavy page.
When would you tell us not to do this?
When the site is one front end with a handful of templates and a small editing team. Headless adds a build step, a second deployment and a second set of things that can break, and on a straightforward marketing site a well-built theme is quicker to change and cheaper to keep running. That is a first-conversation answer, not a halfway-through-the-project one.
Who can maintain it after handover?
Any developer comfortable with the framework we used, which is precisely why we choose mainstream ones rather than something only we know. You get the repository, the deployment configuration, the environment variables documented, and a run book covering builds, previews and rollback.
Web development
Related services
Ready when you are
Tell us what you are building and we will tell you honestly how we would approach it.