02Web Development
Built fast.Built tohand over.
A slow website is a design flaw you can measure. We set a performance budget before the first line of code and hold the line through build — then hand you something you can maintain without us.
01The problem
Speed is not a phase at the end
Most sites are built and then optimised, which is the wrong order and the reason so few of them are fast. By the time someone runs a performance audit, the decisions that cost the most — the framework, the fonts, the third-party scripts, the image strategy — have already been made and are expensive to unpick.
The other half of the problem is ownership. A build that only its author can change is a liability dressed up as an asset. You should be able to take the work to another developer, or bring it in-house, without a rebuild.
02What it involves
What the work actually is
- Performance budget
- A weight and timing target agreed before build, with every image, font and script weighed against it. Exceeding it is a decision, not an accident.
- Semantic, accessible code
- Real HTML elements doing their own jobs, so keyboard use, screen readers and browser behaviour work without custom patching.
- CMS where it earns its place
- Editable where you need to edit, static where you do not. Not every page needs a database behind it.
- Core Web Vitals
- LCP, CLS and INP measured on throttled connections and mid-range hardware, because that is where your visitors are.
- Security & headers
- Content Security Policy, HSTS and sensible defaults configured at the edge rather than left to the host.
- Handover
- Documented, dependency-light, and yours. No proprietary lock-in and no retainer required to change a heading.
03How it runs
How the work runs
-
01
Set the budget
A page-weight and timing target derived from your audience — their devices, their connections — not from a generic benchmark.
-
02
Build the foundation
Markup, tokens and components first. Accessibility and semantics are the starting structure rather than a later audit.
-
03
Build the pages
Templates assembled from the system, with every state handled. Content goes in early so nothing is tested against placeholder text.
-
04
Measure honestly
Throttled network, throttled CPU, real devices. A result that only holds on a fast laptop on office wifi is not a result.
-
05
Hand over
Documentation, access, and a walkthrough. You should be able to run it, edit it, and move it elsewhere.
04What you get
What you end up with
- A measured performance budget, and the numbers against it
- Semantic, accessible, documented front-end
- CMS configured to your actual editing needs
- Security headers, caching and deployment configured
- Handover documentation and a walkthrough
05Related work
Where this shows up
06Honestly
When this is the wrong service
If you do not yet know what the site should say or look like, build is premature — design comes first, and building to an undecided design is how budgets disappear. If you have a working site that is simply slow, that is often a focused engagement rather than a rebuild.
Probably better: Web DesignOngoing Support
07Questions
Web Development — common questions
01 What do you build with?
Whatever the project genuinely needs, biased hard towards less. Many marketing sites do not need a framework at all, and shipping one anyway costs your visitors load time for your convenience. Where a CMS is needed we pick one you can leave.
02 Will I be locked in?
No. The code is yours, documented, and deliberately dependency-light. If you want to move to another developer we will help with the handover rather than make it difficult.
03 How fast is fast?
We target a Largest Contentful Paint under 2.5 seconds on a throttled connection with a throttled CPU — the conditions a real visitor on mobile data experiences, not a fibre connection on a new laptop.
04 Can you build a design someone else made?
Yes, often. We will review it first and tell you where it will cost you performance or accessibility, because finding that out during build is worse for both of us.
08Also relevant