A bespoke WordPress,
not a bought theme.

WordPress carries a considerable share of the web, and it drags a bad reputation it only half deserves. What is slow, vulnerable and impossible to change is almost never WordPress: it is a bought theme nobody maintains, some thirty plugins piled up over the years, and a site nobody dares update any more.

We build it differently. A versioned foundation, where the site’s code lives in a repository and deploys automatically. A theme written for you, not bought. Plugins chosen one by one, with a written reason for each. And maintenance that exists from day one, because a WordPress site left alone decays without warning.

We also deliver Webflow and Shopify, which lets us tell you when WordPress is not the right choice.

The question is settled on three criteria, and none of them is a technical preference.

The three situations where WordPress wins

• A precise functional need that already exists. A member area, booking, membership, a catalogue with particular rules, a connection to a business system. The ecosystem covers cases that closed platforms do not, or only at the price of a full build.
• A significant editorial volume. A site publishing several times a week, with several contributors, distinct roles and review before publication. That is the tool’s home ground and it remains excellent there.
• A requirement for control. The site belongs to you, it runs where you want, and you can leave. No hosted platform offers that reversibility.

The three situations where we advise something else

A team that wants to publish without ever depending on a supplier and without worrying about updates: a hosted platform will cost them less in mental load. A showcase site of a few pages with no particular need: WordPress is oversized. And an online store whose catalogue is the heart of the business, where other platforms take on more on your behalf.

We have set out the first of those decisions in Webflow or WordPress and the last in Shopify or PrestaShop.

The criterion that really settles it

Who will look after the site in two years? WordPress calls for regular upkeep that hosted platforms take on for you. If nobody, in house or at a supplier, has that time at a fixed point, the choice turns against you. That is not an argument against the tool, it is a decision about organisation.

It is what most distinguishes our WordPress projects from common practice, and it is invisible to the visitor.

The code lives in a repository, not on the server

The widespread practice is to edit the files directly on the hosting, sometimes through the admin editor. It is quick and it produces three problems: nobody knows who changed what, no rollback is possible, and the slightest update overwrites the changes.

With us, the theme and the configuration live in a versioned repository. Every change is dated, attributed and reversible. Deployment is automated: one command, a new version live in one go, and the ability to return to the previous one within seconds.

Plugins are declared, not installed by hand

The list of plugins and their versions are part of the code. That means we know exactly what is running, that a test environment is identical to production, and that no plugin can appear without somebody having decided it.

Every plugin kept has a written reason. It is a modest discipline that avoids the classic drift: thirty plugins whose purpose nobody can account for, a third of which no longer serve, and which nobody dares remove for fear of breaking something.

A theme written, not bought

An off-the-shelf theme has to cover every possible use, so it carries code for needs that are not yours. That weighs on speed and complicates every change.

We write the theme from your templates. The site contains only what it uses, and editing stays simple because the blocks are built for your content, not for a demonstration catalogue.

The wide spread of WordPress makes it a permanent target. That is not a weakness of the software, it is a consequence of its popularity, and it can be handled.

How a site actually gets compromised

The common picture is of a targeted attack. The reality is more mundane: automated sweeps test thousands of sites looking for a known weakness, almost always an un-updated plugin or a weak password. Nobody chose you, your site answered.

And what follows does not look like the picture either. A compromised site almost never displays a triumphant message: it goes on working normally while a discreet administrator account has been created, invisible pages are published, or emails go out in your name. The consequences come afterwards, when the domain is flagged as dangerous and legitimate emails stop arriving.

What we apply on every site

• Updates to the foundation and the plugins at a fixed rhythm, tested before production, with critical patches applied without waiting.
• Accounts kept up to date: access for people who have left disappears, and the list of administrators is known and checked.
• Unique passwords per site. A reused password turns the compromise of one service into the compromise of all the others.
• Unnecessary entry points closed rather than left open by default, particularly on the programming interface side.
• Backups whose restore has been tested. A backup never restored is not a backup, it is an assumption.

Why this is not sold as an option

A WordPress site delivered without upkeep is a site whose expiry date is known and unsaid. We would rather deliver fewer sites and hold them, which is what the website maintenance page describes, and we set out the mechanism of decay in this article.

It is the most common case, and it calls for a stage quotes often pass over in silence.

The entry audit, before any commitment

We look at the real state: the version of the foundation, the plugins and whether they are maintained, the theme and where it came from, changes made directly on the server, the state of the backups, the existing accounts, and speed measured on mobile.

That stage serves you as much as us. It may conclude that the site is sound and that work starts straight away. It may conclude that an overhaul is needed first, in which case it is costed separately rather than dissolved into a package.

The three states we meet

Sound but neglected. The foundation is correct, the updates have fallen behind, a few plugins should be removed. An overhaul of a few days is enough, and the site is good for years.

Edited directly on the server. The theme has been altered by hand, sometimes by several successive suppliers. You then have to reconstruct what was done before you can update anything without breaking the site. It is the longest situation to deal with.

At the end of the road. An update to the foundation breaks the site, the number of plugins exceeds what anyone can account for, and the slightest change requires technical intervention. There, a framed rebuild costs less than a year of fixes.

What we refuse

Taking on support for a site we know will break in the first quarter, without saying so. It is convenient at the point of sale and unsustainable afterwards. And migrating to WordPress a site that has no reason to go there: if the need does not call for what WordPress brings, the migration is a cost with nothing in return. We describe the opposite, moving out to a hosted platform, on the Webflow migration page.

“WordPress is slow” is a sentence we often hear and it describes a symptom, not a cause. A properly built WordPress site displays as fast as a site on a hosted platform. What slows it down is known, limited, and can be dealt with.

The four real causes, in order of impact

• The images. It is almost always the first line. Visuals uploaded at full resolution, served in the same format to everyone, weigh several megabytes per page. They display correctly, so nothing flags the problem, and the page takes four seconds to appear on a phone.
• Third-party scripts. A measurement tool added for a campaign, a chat widget trialled then forgotten, a pixel installed by a supplier who is no longer around. Each adds a request and execution time, and nobody ever removes them.
• No page caching. Without caching, every visit rebuilds the page from the database. That is work redone thousands of times for an identical result, and it costs around a second per page.
• An overloaded theme. An off-the-shelf theme has to cover every possible use, so it loads code for needs that are not yours, on every page, including those that have no use for it.

What we deal with during the build

Images are reworked and served in a modern format, at the real display size, with deferred loading for anything off screen. Page caching is in place from launch, not added afterwards when somebody complains. The theme contains only what the site uses. And every third-party script has a written reason, which makes a clear-out possible later.

How we measure

On a mid-range phone on an average connection, not on a computer on fibre. The gap between the two measurements is often a factor of three, and it is the bad one that matches your visitors. A measurement taken in good conditions gives a flattering and useless figure.

Why this is not settled once and for all

Performance degrades by itself: every publication adds images, every campaign adds a script. That is why it is part of the ongoing support and not of a one-off engagement, a subject covered on the SEO and performance page.

Two WordPress quotes cannot be compared without this detail, because the word covers very different realities.

What is always included

• The framing, the site map and the structural decisions, settled before the mockup.
• The design and writing of the theme, from your templates. No bought theme.
• Setting up the versioned foundation and the automated deployment.
• The launch, the redirects from the old site, and training in editing.

What is costed separately

The hosting, which is in your name. Paid plugin licences, when a single one genuinely covers a need. Writing the content, because it depends on who takes it on and because it is almost always the critical path. And connections to your business tools, because an integration with a management system is a project in itself.

The number of templates, which is the real variable

It is not the number of pages that makes the price, it is the number of different models. Three hundred pages built on five templates cost less than eight pages that are all different. It is also the simplest lever for adjusting a budget without degrading the result.