WordPress is a good choice for most content sites and a bad choice when it is installed with forty plugins and a purchased theme. We build the first kind.
New build, or an existing site that has become difficult to change.
A complete WordPress and WooCommerce build for a Swiss life-sciences company, connecting product ordering with events, blogs and a resource library.
WordPress, WooCommerce · Delivered through an agency partnerExplore the case studyThe theme is written for your site. Templates match the design at every breakpoint, the markup is semantic, and the front end is not carrying half a megabyte of CSS for components your site does not use. If you do not have a design yet, explore our web design service.
Editors get a set of blocks that produce your layouts and nothing else. Fields are labelled in the language your team uses, not in developer shorthand, and the ones that would break the design are not exposed. Advanced Custom Fields where structured content needs a proper model.
When no existing plugin does the job, or when the one that does brings four features you do not want and a settings page nobody understands. Custom plugins for post types, integrations, admin tooling and scheduled jobs — kept in your repository like the rest of the code.
Multiple sites — regions, brands, franchises — sharing one codebase and one update path, with the parts that differ genuinely separated. Worth doing when it is right, and expensive when it is not; we will tell you which case you are in.
Migrations from another CMS, from a static site, or from a WordPress install that has become unmaintainable. Content, URLs and redirects treated as assets to be preserved. See CMS migration.
Said plainly, because it is the difference between two very different quotes:
If a project genuinely suits an off-the-shelf theme, we will say so. Paying us to rebuild something you could have bought is not a good outcome for either of us.
The measure of a WordPress build is not how it looks on launch day. It is whether the person who updates it in eighteen months can do so without ringing anyone: blocks that map to the layouts you actually publish, previews that match the front end, media handled automatically, and a short written guide for the people doing the editing — written for them, not for a developer.
Scope. What the site does, what page types it needs, and how content is structured. The content model is agreed here, in writing, because changing it later is the expensive kind of change.
Build. Theme, blocks and fields, on a staging URL you can see from early on. One named contact and a fixed check-in rhythm.
Content. Either you load it, or we migrate it. Either way it happens before testing, not after, so the design is tested against real content.
Launch. Redirects, analytics, Google Search Console, backups and monitoring in place on the day.
Handover. Repository, deployment instructions, editor guide, and a walkthrough call.
WordPress needs maintaining. Core, plugins and PHP versions move, and an unattended install is the most common way a site gets defaced.
You can run that yourself — the handover tells you how — or put it on a support agreement where updates, backups, monitoring and fixes are handled to a published SLA. It is optional and it stays optional.
To scope a WordPress project we need your current website, the page types you need and who will edit them. Include any designs, content outlines and plugins you want to keep. We agree who supplies or migrates the content before quoting. The written scope sets out what the site does, what page types it needs and how content is structured. The content model is agreed at this stage, in writing, because changing it later is the expensive kind of change. Plugins you already use are audited at scope, and you get the list with a recommendation against each one. A page speed target is agreed at scope and the build is held to it. We also answer whether WordPress is the right choice before the quote. Tell us whether it is a new site or an existing one, and when it needs to be live. If an existing site is involved, the work can start with a written assessment, which is a smaller commitment than a rebuild.
For a content site that a non-technical team edits, WordPress is usually still the right choice. For an application with accounts and permissions, it usually is not, and for that kind of project see web development. We answer this before the quote. WordPress is a good choice for most content sites and a bad choice when it is installed with forty plugins and a purchased theme. We build custom themes written for your site, with a set of blocks that produce your layouts and nothing else, and Advanced Custom Fields where structured content needs a proper model. We do not build on page-builder plugins, because they are quick to start, slow forever afterwards, and make the site hard to move. If a project suits an off-the-shelf theme, we will say so. WordPress also needs maintaining, because core, plugins and PHP versions move. You can run that yourself after handover or put the site on an optional support agreement.
Yes, we work on existing WordPress sites. It starts with a written assessment of what is there, what is safe to change, and what is holding the rest of it hostage. That is a smaller commitment than a rebuild and it frequently avoids one. Plugins are audited as part of that. Some get kept, some get replaced by a few lines in the theme, and some are the reason the site is slow, and you get the list with a recommendation against each one. Most WordPress sites are slow because of what was installed on them, and WordPress itself is rarely the cause. If the install has become unmaintainable, we can migrate it, with content, URLs and redirects treated as assets to be preserved. An unattended install is the most common way a site gets defaced, so keeping core, plugins and PHP versions current matters. After the work you can maintain the site yourself or put it on an optional support agreement with a published SLA.
A WordPress site we build is held to a page speed target that is agreed at scope. Most WordPress sites are slow because of what was installed on them, and WordPress itself is rarely the cause. We write the theme for your site, so the front end is not carrying half a megabyte of CSS for components your site does not use, and the markup is semantic. We do not build on page-builder plugins or apply your colours to a purchased theme. We do not install a plugin for something that is fifteen lines of code. On an existing site, plugins are audited at scope, and some of them turn out to be the reason the site is slow. Performance is a build task for us: page speed, heading structure, metadata, canonical tags and redirects are part of the build and are checked before launch. Testing covers real devices and performance checks against the budget agreed at scope.
No, you do not have to use our hosting. A WordPress site we build runs on standard PHP and MySQL hosting. If you want it managed, hosting is available separately. The handover includes the repository, deployment instructions, an editor guide and a walkthrough call, so the site can be deployed on the hosting you already have or on new hosting later. We do not build on page-builder plugins, partly because they make a site hard to move. WordPress does need maintaining wherever it is hosted. Core, plugins and PHP versions move, and an unattended install is the most common way a site gets defaced. You can run that maintenance yourself, and the handover tells you how, or you can put the site on a support agreement where updates, backups, monitoring and fixes are handled to a published SLA. That agreement is optional and stays optional. On launch day, redirects, analytics, Google Search Console, backups and monitoring are in place.
We audit the plugins you already pay for at scope. Some get kept, some get replaced by a few lines in the theme, and some are the reason the site is slow. You get the list with a recommendation against each one. When you first contact us, include the plugins you want to keep along with your designs and content outlines. We do not install a plugin for something that is fifteen lines of code and then leave you to update it for five years. When no existing plugin does the job, or the one that does brings four features you do not want and a settings page nobody understands, we write a custom plugin. Custom plugins for post types, integrations, admin tooling and scheduled jobs are kept in your repository like the rest of the code. For paid plugins on a support agreement, upgrades that need a decision are flagged to you before they run.
You own the code. You receive the full repository, with no licence conditions of ours attached. That covers the custom theme written for your site, the blocks and fields, and any custom plugins, which are kept in your repository like the rest of the code. Handover includes the repository, deployment instructions, an editor guide and a walkthrough call. Every project ends with the code in a repository you own, yours from the first commit, with a readable commit history and a README that tells a developer how to run it. Nothing in it only works while we are involved. The site runs on standard PHP and MySQL hosting, so you are free to host it where you choose. We do not build on page-builder plugins, which make a site hard to move, and we do not sell a purchased theme with your colours applied. After launch, a support agreement is optional and stays optional, and the handover tells you how to maintain the site yourself.
Tell us whether it is a new site or an existing one, and when it needs to be live.
Or email us at [email protected].
Agency looking for a build partner? White-label WordPress development
