Built properly, explained plainly.
For businesses that have outgrown a page builder. Modern where it helps, boring where boring is better, and documented so you are never dependent on us.
Development is where a design either becomes a fast, durable website or becomes a maintenance problem. The difference is rarely which framework was used. It is whether the person building it treated performance, accessibility, and readability as requirements or as things to get to later.
Below is every significant technical decision, what it means in plain terms, and why it matters to your business. If a decision cannot be explained that way, it is usually complexity being sold as sophistication — and it is left out.
Every decision, in plain terms
Six choices that shape what the finished site is like to visit and to own.
- 02.1
Server-rendered HTML
The page arrives from the server already built, instead of arriving as a blank shell that JavaScript has to fill in.
Why it matters. It appears faster on a slow phone, it works if a script fails, and a search engine can read it without doing extra work. This single decision does more for both speed and search visibility than any optimisation applied afterwards.
- 02.2
Semantic HTML
Headings are headings, buttons are buttons, navigation is a nav — not a page built entirely from generic containers.
Why it matters. Screen readers can navigate it, keyboard users can reach everything, and search engines can tell what is a heading and what is a caption. It also costs nothing: it is the same amount of code, written correctly.
- 02.3
As little JavaScript as the page allows
Interactive code ships only for the parts that are genuinely interactive — a menu, a form — rather than for the whole page.
Why it matters. JavaScript is the most expensive thing a page can send. Less of it means the site responds immediately when someone taps, especially on the mid-range phones most of your visitors actually own.
- 02.4
A component system
Buttons, cards, and layouts are defined once and reused, instead of being rebuilt on each page.
Why it matters. A change to the button style is one edit, not forty. New pages are cheap to add because they assemble from parts that already exist and already match.
- 02.5
Preview deployments
Every change gets its own private URL before it reaches the live site.
Why it matters. You see and approve changes in a real browser rather than in a screenshot, and nothing untested ever appears on the site your customers are looking at.
- 02.6
Your repository, your hosting
The code lives in a Git repository in your account, deployed to a host in your name.
Why it matters. There is no lock-in. Another developer can pick the project up without asking us for anything, which is exactly the position you want to be in.
Performance is not a phase
There is no optimisation sprint at the end, because by then the expensive decisions are already made.
Core Web Vitals are three measurements of whether a page feels good to use: how long until it looks ready, whether it jumps around while loading, and whether it responds when you tap. Every one of them is decided by architecture rather than by tuning.
So the checks run during the build, against field data rather than a lab score, and again before launch. If you want the full explanation, we wrote one up.
- LCPLargest Contentful PaintHero imagery sized and prioritised; fonts self-hosted so text never waits.
- CLSCumulative Layout ShiftEvery image, embed, and late-loading element has its space reserved.
- INPInteraction to Next PaintInteractive code limited to the components that are actually interactive.
What we will talk you out of
Scope we could bill for and usually should not.
A CMS you will not use. If you plan to change copy twice a year, a content management system adds cost, a login to forget, and a permanent security surface. We will ask honestly how often you expect to edit, and if the answer is rarely, we will suggest just asking us.
A custom app when a page will do. Booking, payments, and scheduling all have mature services that already handle the hard parts, including the legal ones. Integrating one is usually better than building your own.
A single-page application. Marketing sites are documents. Turning one into an app makes it slower, harder to index, and more fragile, in exchange for a page transition nobody asked for.
This is also why the pricing page talks about scope rather than packages — the cheapest version of a project is usually the one with the least invented in it.
What you receive, and what you do not
Named artefacts on the left. On the right, the limits of this clause — printed beside the scope rather than in a later document.
- A production codebase in a repository you own — included
- Static rendering wherever the page allows it — included
- Responsive implementation verified from 320px up — included
- Accessible components with real focus and error states — included
- Deployment configuration and a documented handover — included
Everything above is handed over in your own accounts and stays yours. See when each piece arrives.
- Native iOS or Android applications — not included
- Backend systems beyond what the website itself needs — not included
- Ongoing feature development after handover, unless separately quoted — not included
- Migrating data out of a system you no longer have access to — not included
- Third-party licence and subscription fees — not included
- Maintaining code we did not write — not included
If you need one of these, say so at discovery and it gets quoted as its own line — never absorbed silently and billed later.
Questions about clause 02
No references yet
Case studies are published as projects finish and clients approve what can be shown. Nothing is invented in the meantime.
Read first
- 01How much does a website cost?What actually drives the price of a business website — scope, page count, content, integrations, and custom design — and how to read a quote you have been given.
- 02What are Core Web Vitals?A plain explanation of LCP, CLS, and INP — what each one measures, what makes them bad, and why they matter to a business website beyond the score itself.
- 03What pages should a small business website have?The pages a small business site genuinely needs, the ones that are usually a waste, and how to structure them so both visitors and search engines can follow.
Talk through a build.
Describe the business and what is not working. You get a straight answer on whether clause 02 is the right fit, what it involves, and what it costs.