Service

Website Engineering

The platform is a consequence of the requirements, not a starting position. A brochure site, a catalogue of forty thousand products and an editorial publication are three different problems, and only one of them is a CMS question.

Request thisProject or day rate

Engagement
Fixed scope, or day rate
Typical length
Two weeks to three months
Handover
Documented code, your hosting, your repository
Best for
A build, a rebuild, or a platform move

Deliverables

What You Actually Receive

Named up front, so there is something to hold the work against when it is finished.

01

Platform Decision, Written Down

Which platform, why, and what it costs you later. Recorded before the build, so the reasoning survives after the person who made it moves on.

02

The Build

Templates, content modelling, editorial workflow, and the integrations the business already depends on. Performance budgets are set at the start, not audited at the end.

03

Compliance In The Build

Consent, analytics and accessibility handled during the build, where they cost hours, rather than after launch, where they cost a retrofit.

04

Documented Handover

A README that describes the deployment, the environments and the decisions, good enough to hand to a stranger.

In detail

How The Work Runs

Choosing The Platform

WordPress earns its place when editors need to work without a developer, when the content model is broadly conventional, and when a large plugin ecosystem is an asset rather than a liability. WooCommerce earns its place on the same terms, with the added condition that the catalogue and checkout stay inside what it does well.

Past a certain point they stop paying. Deeply custom data models, heavy integration surfaces, or applications that happen to have a public front end are cheaper and steadier built directly.

Signal Points to WordPress Points to a custom build
Editing Non-developers publish weekly Content changes rarely, or by import
Content model Pages, posts, a handful of types Deeply relational, or externally owned
Commerce Catalogue and checkout fit WooCommerce Bespoke pricing, quoting or fulfilment
Integrations A few, with maintained plugins Many, or with systems nobody has heard of
Traffic shape Steady, cacheable Spiky, personalised, or logged-in
Team after launch Agency or freelancer maintains it In-house developers own it

Nothing here is decisive on its own. Most projects sit on both sides of the table, and the job is weighing which column the expensive parts fall in.

That decision gets made once, in the open, with the trade-offs written down.

Performance Is A Budget, Not A Phase

A page weight and request budget is agreed before the first template is written, and every addition is measured against it. This is the only reliable way to ship a fast site: retrofitting performance means removing things people have already been promised.

A budget that is only checked at the end is not a budget. It is an apology written in advance.

A typical starting budget, adjusted to what the site actually has to do:

Metric Budget Hard stop
HTML, gzipped 20 KB 40 KB
CSS, gzipped 15 KB 30 KB
JavaScript, gzipped 0 KB 60 KB
Requests, first view 12 25
LCP, 4G mobile 1.5 s 2.5 s

The same applies to the third-party tags marketing will ask for after launch. There is a defined amount of room for them, and it is finite.

What Happens At The End

The code is yours, in your repository, on your hosting, with the deployment documented. No agency licence, no proprietary page builder that only I can operate, and no arrangement where leaving means rebuilding.