The thing most clients ask us about first is speed. "Our site feels slow. Can you make it faster?" The thing they ask us about second, usually a month or two later, is cost. "Every change is more expensive than we expected. Can you make that better too?"
Those two questions are almost always connected, and on most Drupal sites they have the same answer.
Why the "modern website" pattern got expensive
Over the last ten years, a particular recipe took over the Drupal world: build the content in Drupal, build the frontend as a separate JavaScript application, connect the two with a REST or JSON:API layer. The appeal is understandable. The frontend gets to feel modern, the backend stays Drupal, and each half can be developed by its own specialists.
The cost is less visible until you are a year or two in. Every change to a page goes through two teams, two deployments, and two sets of release notes. Every new field on a content type has to be added to the backend, exposed through the API, described in the frontend's type system, and wired into the component that displays it. A change that took one afternoon on an old-school Drupal site now takes most of a sprint. Over a year, that compounds into a real line item on your budget and a real source of delay on your roadmap.
None of that makes decoupled architectures wrong. It makes them a very specific trade-off: you pay a steady tax on change in exchange for being able to reuse the same backend across multiple frontends (a website, a mobile app, a partner integration). If you are running a mobile app on top of your Drupal site, that tax is worth paying. If you are running one website, it almost never is.
What we do instead
We build sites where the frontend and the backend share a single codebase. The pages you see in the browser are React components — genuinely modern, fast, interactive — but they live inside Drupal, render on the server for the first paint, and receive the data they need directly, without an HTTP request in between.
You do not need to care about how. You do need to care about what changes.
The first page loads noticeably faster. Because the server renders the visible content and the browser does not have to wait for a second network round-trip to fill it in, the time from click to readable page drops below the one-second threshold where impatience sets in. For lead-gen and e-commerce sites, that single improvement tends to move conversion measurably within a few weeks of launch.
Navigation between pages feels instant. Once the first page is loaded, clicking through the site feels like changing tabs in a desktop app — no full-page refresh, no flash of blank content. This is the part of the experience that, in our experience, moves the "does this feel like a serious company?" dial more than any amount of visual design.
Your engineering budget buys more features. A feature request that has to cross two codebases in a decoupled setup is usually a much smaller project with us. That is not because we are faster typists. It is because we are only changing one codebase, running one test suite, and deploying one thing. Multiply that saving across a year of small requests and it is easily the cost of a whole new feature.
There is one team, not two. You have one project manager, one phone number, one invoice. When something needs to change, you do not have to guess whether it is "a frontend ticket" or "a backend ticket." It is just a ticket.
Does this work for every site?
Almost always, for the kind of sites we build — content-heavy, editorially active, one website per organization, sometimes with an admin area or a customer portal on top. It is not the right answer if your frontend is a native mobile app that happens to share a Drupal backend, or if your organization has genuinely separate frontend and backend teams with their own release cadences and deep specialisations. We can tell you which side of the line you fall on in one conversation.
For everyone else — which is most of the people who approach us — the coupled approach is faster to build, faster to use, cheaper to maintain, and easier to staff. And the sites we ship with it are the fastest Drupal sites we have delivered.
If that sounds like the thing you have been trying to get from your current site, we would love to show you what one of ours looks like. No spec required for the first call.