A website is not a page.It is a system that has to hold.
Most sites are assembled once and then quietly decay. A custom build treats content, rendering, delivery and measurement as four separate decisions, each one made on purpose, each one owned by you afterwards.
Below is exactly how we think about that work. Read it as a walkthrough, not a pitch. If it matches how you want your site built, the conversation is easy.
Custom is not always the right answer, and we will tell you when it is not.
A template is a perfectly good decision under the right conditions. The problem is that most teams outgrow those conditions without noticing.
- Your site is under roughly twenty pages and the structure is stable.
- Content changes are copy edits, not new content types.
- Nobody is running experiments against the page.
- Traffic is modest and organic search is not the main channel.
- Marketing waits on a developer to publish anything meaningful.
- Every new page type needs a plugin, and every plugin needs another plugin.
- Page speed became a recurring agenda item rather than a one time fix.
- You want to test a hypothesis and the honest estimate is next quarter.
If your situation sits firmly in the left column, we will say so and point you at the faster route. There is no version of this where we sell you a build you do not need.
Four layers. Four decisions. Each one has a failure mode.
Almost every slow, awkward or unmaintainable website can be traced back to one of these four being chosen by accident.
Decision. Which CMS, and more importantly what the content model looks like inside it. Types, fields, relationships, validation.
If it goes wrong. Editors start pasting layout into rich text fields. Two years later the content cannot be reused anywhere else.
Decision. Which pages are static, which are streamed, which hydrate at all. Chosen per template, based on how the content behaves.
If it goes wrong. Everything renders on the client. The first paint waits for JavaScript, and search engines see an empty shell.
Decision. Where responses are cached and how long each URL stays fresh. Cache rules follow how often content actually changes.
If it goes wrong. Either stale pages your team cannot flush, or nothing cached at all and every visitor pays full cost.
Decision. What counts as a conversion, what fires the event, and how field vitals are collected from real visitors.
If it goes wrong. You optimise against a lab score while real users on real phones keep bouncing, and nobody can prove why.
Measurement feeds back into content. That loop is the whole point. A site that cannot tell you which page earned the enquiry is a brochure with a hosting bill.
From request to interactive, step by step.
Speed is rarely one big problem. It is five small ones stacked on top of each other, and each has a specific fix.
A visitor on a mid range phone asks for the page. Nothing has been drawn yet.
Cached at the edge and returned as ready HTML, so the first meaningful content does not wait on a round trip to origin.
One family, preloaded, with a metrics matched fallback. Images sized and served as AVIF with a WEBP fallback.
Only the parts that need behaviour become interactive. A static section stays static and costs nothing.
Real vitals from real visitors flow back in, split by device and template, so the next fix targets the worst page rather than the average.
Every commit is measured against these ceilings, with a reason attached to each.
A number without a reason gets negotiated away in week six. A number with a reason survives the whole project.
Keeps the critical response inside the first network round trip, which is where the first paint is won or lost.
Parsing cost, not download cost, is what stalls mid range Android devices. Less script means a faster time to interactive.
Every extra weight is another blocking request and another opportunity for text to reflow after paint.
Modern formats cut weight substantially, and declared dimensions remove the layout shift that hurts the score most.
The budget runs in the pipeline, not in someone's head. A pull request that pushes a page over its ceiling fails the check and has to justify itself before it merges. That is the only way a fast site stays fast after launch.
Your content model decides how your team will feel every single week.
Two CMS setups can look identical in a demo and be completely different to live with. The difference is whether content is structured or just stored.
Marketing ships a new page type without opening a developer request.
One piece of content appears in listings, feeds and structured data at once.
Structured content moves to a new front end. Rich text soup does not.
Some of it is authored. Most of it should generate itself.
Anything a person has to remember to do on every page eventually stops happening. Systems do not forget.
- Title and description written for the page, not the brand
- Canonical declared explicitly
- Social preview text and image
- Heading structure that matches the actual argument
- Sitemap built from the CMS, never a stale static file
- Structured data derived from the content type
- Breadcrumbs from the route tree
- Related links from real relationships
- Redirects as an editable list, not buried config
- Internal linking rules with clean anchor text
- Crawl rules reviewed when templates change
- Index coverage watched after every release
Four phases, each one ending in something you can hold.
No phase closes on a status update. Every phase closes on an artefact you keep whether or not we continue.
Whoever owns the message
Content inventory, page types, the argument each template has to make
Marketing plus one decision maker
Content model, key templates designed, the performance budget agreed in writing
Weekly review, nothing more
Working templates on a preview URL from the first week, updated continuously
Everyone who will touch the site
Migration, redirect map, CMS training and the repository in your organisation
The repository, the pipeline, the CMS account and the analytics property are yours from day one, not transferred at the end. Nothing about the arrangement depends on you being unable to leave.
The questions worth answering directly.
Why would we pay for this when a platform costs a fraction?+
For a small stable site you should not. The cost comparison only changes when the platform starts charging you in developer time, plugin licences and page speed. Compare the total for two years, including the hours your team spends working around the tool, and then decide.
Who edits the site after launch?+
Your marketing team, in a CMS shaped around your content rather than a generic page builder. Day to day publishing needs no developer. We train the team during handover and leave written documentation behind.
What happens if we stop working with you?+
Nothing breaks. The code sits in your repository, the pipeline runs under your account, and the stack is mainstream enough that any competent team can pick it up. We will run a handover session with whoever takes over.
Can we run A/B tests without ruining performance?+
Yes, if the assignment happens before the page renders rather than in a blocking client script. We handle it at the edge with a lightweight cookie, or integrate a testing platform in a way that keeps it off the critical path.
How do you handle a migration from an existing site?+
Content is exported and remapped into the new model rather than pasted across. Every existing URL is accounted for in a redirect map that we test before launch, so search equity survives the move.
What does the timeline actually depend on?+
Content readiness, almost always. Build work is predictable. Waiting on copy, approvals and asset access is what stretches a project. We plan around that honestly rather than quoting a week count we cannot control.
Send us the URL of your current site. We will come back with what the field data says, where the seconds are going, and the two or three structural issues worth fixing first. If the answer is that you do not need a rebuild, that is what we will tell you.
Start with a review, not a proposal.
A short conversation about how your site is built and where it is holding you back.
Book a call, or send the brief.
Tell us where you are stuck. We come back with a fixed price roadmap, timeline and exactly who on our team is on it, inside 24 hours. No decks, no pressure.