A WordPress site you won’t have to rebuild in three years.

Yes, for most sites. But the reason people are asking is real and worth being precise about. WordPress has been losing ground for the first time in a decade: 40.2% of all websites and 58.8% of the CMS market as of September 2026, down from a peak around 43.6% in early 2025. The security picture underneath that number is the part that should matter to you while you are choosing. Of the 11,334 vulnerabilities found across the WordPress ecosystem in 2025, 91% were in plugins and two were in WordPress core. So the risk is not really the platform. It is how much of your site is made of other people’s plugins, which is a decision made during the build, and it is the one we take most seriously.

Less than most people expect for the amount of custom work, and we will give you a real number on the first call rather than a range that fits everybody. What moves it is custom functionality: integrations, unusual content structures, anything with permissions behind it. Page count barely matters — a hundred pages built from five templates is less work than twenty pages where every one is bespoke. Multi-region and platform work goes higher.

Most WordPress builds run 8 to 16 weeks. Work goes live in increments along the way instead of arriving as one reveal at the end, so you are looking at real pages within the first few weeks.

Not for anything we build. We build block themes with custom blocks where an editor genuinely needs one. That keeps the site fast, keeps it editable, and leaves no proprietary layer sitting between your content and the platform.

Yes. Maintaining and rescuing page-builder sites is ordinary work for us; a good part of what we look after every month was built by somebody else, on something we would not have chosen. What we will not do is start a new build on one.

No. If you are selling in a fairly standard way we build it on Shopify, which does that job better than a plugin stack bolted onto a content site. If your commerce is unusual enough that a store will not do, whether that is subscription logic, complex pricing, or something that has to own its own data, then you need a custom platform. We build both. Neither one is this page.

Almost certainly not. Headless splits WordPress into a back end and a separately built front end. That buys you one specific thing, usually a shared content source across several applications, and it costs you a second codebase, a second deployment, and an editing experience that no longer shows anyone what a page will look like. We have built it. We have not met a case for it in a while. If you have one, it will be obvious in the first conversation.

Yes, and that is a build decision before it is a training one. Blocks and patterns get set up so editors change content and not layout: the things that would break a page are simply not exposed. If your team also needs the content model designed around how they actually publish, and training on it, that is its own engagement and we do it.

We build to WCAG 2.2 AA as a matter of course — semantic markup, keyboard-operable components, visible focus states and real contrast — because retrofitting those into a finished site costs several times what building them in does. Where you need the work evidenced rather than assumed, for a procurement review or a demand letter, that is a full ADA compliance and accessibility audit, and it is its own engagement.

You keep everything. The repository, the documentation, the hosting account, the domain. All of it sits in your name during the build instead of being transferred at the end. A site we built can be picked up by another team without calling us, and that is deliberate.

We do, if you want us to. Updates, off-site backups with restores actually tested, malware scanning and monitoring for uptime, SSL expiry and form delivery are a website maintenance plan, and it is a separate agreement from the build. Plenty of clients run their own. What we will not do is hand over a site and leave the question unanswered.

Yes, we build multisite. Region-specific content is a content-model decision before it is a technical one: which content is shared, which is translated, which is genuinely different per market. We have run that at scale on a global claims business with region-specific content across its whole site and its own Elasticsearch-powered search.

If WordPress work is continuous and you can keep a good developer busy and current, in-house is often the right answer and we will say so. It stops being the right answer when the work is lumpy: a build, then months of nothing, then a migration. Or when one person becomes the only one who understands the site. That second one is the failure we get called about most. Not a bad developer. A single one, who left.

Yours can, and every site we build is set up for it. WordPress 7.0 plus the AI plugin gives a site a way to be read and updated by an AI client instead of only by a person in a browser, and Chek Managed AI is our connector on top of that. Your team can ask questions of the site, or change it, from the tools they already work in. It is in limited release right now rather than generally available.