A website you can change yourself, in about ninety seconds.

No. If you can use email and attach a photograph, you can use this. Most people we train are comfortable within an hour and stop thinking about it entirely within a fortnight. The whole point of building it this way is that the difficult parts were done once, up front, so that using it afterwards is not difficult.

You cannot, in any way that matters. The layouts only offer choices that look right, nothing you can click will take the site down, and every previous version is kept — so if you change your mind about anything, it goes back the way it was. The things people are nervous about were designed out before you ever log in.

Yes, and they should. Everyone gets their own login, and you decide who can do what. A receptionist might be able to change opening hours but not prices; a practice manager might be able to publish anything. If you want changes checked before they go live, that can be turned on as well.

It moves across. We go through what is there, bring over the pages that are earning their place, and point out anything duplicated, out of date or that nobody has visited in a year so you can decide whether to keep it. You will not lose anything without being asked first.

You own all of it, from the first day rather than the last invoice. The website, the accounts it runs on and everything you have written are in your name throughout, and we work inside them as your team rather than holding them and handing them over at the end. If you stopped working with us tomorrow you would keep everything, and any competent web company could pick it up — we build with widely used tools on purpose, precisely so that is true.

Usually six to twelve weeks from starting to being live, and twelve to twenty when there is a shop, several markets or unusual approval steps involved. The thing that makes it longer is almost never the building — it is waiting on words and photographs, or a decision nobody can make. We tell you at the start exactly what we need from you and when, so that is visible rather than a surprise in week eight.

There is no honest single price, because it depends on the shape of what you need — how many genuinely different kinds of page there are, how much of your content already exists, what it has to connect to, and whether you need a second language. What we can promise is that we work it out properly first, then fix the price before anyone starts, so the number you agree is the number you pay.

Not necessarily, and we will tell you if it does not. Sometimes the site is fine and the real problem is that nobody is answering the enquiries it already produces. Sometimes a few fixes get you most of the way. We would rather say that on the first call than sell you a rebuild you did not need.

It removes a set of common problems and introduces one. Gone: plugin-generated markup that breaks silently, theme bloat you cannot control, and a rendering path you do not own. Introduced: nothing renders unless somebody builds it, so metadata, canonicals, hreflang, sitemaps and structured data have to be designed into the templates rather than assumed. Done properly a headless build outperforms what it replaced, mostly on Core Web Vitals and on structured data that cannot drift. Done carelessly it ships a fast site that search engines cannot read.

Only if the redirects are discovered rather than designed. We export twelve months of Search Console data and your backlink profile first, map every resolving URL to its destination with traffic and links attached, agree that map before the build starts, ship the 301s in code, and monitor index coverage through the weeks after launch. On Get Well Clinic that meant restructuring eighteen indexed URLs into a twenty-four page hierarchy with none left returning 404.

For most marketing sites, Prismic or Storyblok, because visual page building is what actually determines whether marketing uses the thing. Sanity or Payload win when the content is unusually structured or the CMS and the product are the same application. Contentful earns its price at enterprise governance and localisation scale. We publish a full public comparison of every platform we work with, including the ones we do not recommend.

Almost certainly headless, and probably not composable yet. Every composable stack is headless, but composable means orchestrating several specialised services behind one experience, which earns its complexity at multi-brand, multi-team scale. For one marketing site in one or two languages, a headless CMS with a well-built front end is the whole answer. Buying composable first is the most common way these projects get expensive before they get useful.

No. Next.js is our default because it is right often enough, but Astro is usually better for content-heavy marketing sites where almost nothing is interactive, and Nuxt makes sense when the team already works in Vue. Because the CMS is headless the front-end choice stays genuinely reversible, which is much of the point of building this way.

You can, and for some estates it is the pragmatic answer — the editorial familiarity is real and the plugin ecosystem solves problems you would otherwise build. What you keep is the plugin surface, the update treadmill and a content model shaped by twenty years of backwards compatibility. What you gain over a purpose-built headless platform is mostly that nobody has to learn anything. If the deciding constraint is that editors already know WordPress, say so early and we will scope it honestly rather than talking you out of it.

Draft mode with a signed token, rendering the same component tree as production against the CMS draft API, at the canonical URL of the eventual page. No separate preview build and no second code path. On platforms with a visual editor we wire the click-to-edit overlay to the same route so editors get in-context editing rather than a side-by-side approximation.

Publish fires a webhook, the webhook revalidates by tag rather than by path, and the tags are derived from the document and its references so a change to a shared component invalidates every page embedding it. The failure mode to avoid is time-based revalidation as a substitute for thinking about dependencies — it looks like it works right up until an editor is watching a stale page and does not believe you.

Codegen from the schema, output checked into the repository, and generation run in CI so a divergence fails the build rather than surfacing as a runtime undefined on a production page. Where the platform's generator is weak we write the mapping ourselves, but it is always generated from a single source of truth and never maintained by hand.

One content model with a locale dimension, not duplicated document trees per market, and routing where the locale is a segment rather than a subdomain unless there is a real organisational reason. Hreflang generated from the routing so it cannot drift when someone adds a page, x-default set explicitly, and the language switcher resolving to the equivalent page rather than the homepage — which is the bug in almost every localised site we are asked to fix.

That is the entire point, and it is a function of the content model rather than the platform. If the model was designed around the pages that existed at launch, every new page needs a developer no matter what you bought. We design the blocks so a page is assembled rather than built, and we put guardrails on them so assembling one cannot take the site off brand. On SUMM that produced two languages on every page with zero developers in the publishing path, running since 2023.

Your team, and that is the design goal rather than a hope. The stack is deliberately unexotic, the schema is documented in the repository with the reasoning attached, and the handover includes a working session rather than a link to a Notion page. If you would rather we stayed on to run it, that is a monthly arrangement and it is not a prerequisite for anything.