A website is not a brochure.
It is your best salesperson.
Most business sites are built to look finished, not to perform. We build sites that load fast on a mid-range phone, get crawled properly, and are structured so the next page you add ranks without a rebuild.
How we structure a build: semantic markup, measured field performance, and the technical checks that decide whether the site can rank.
The site that wins the pitch is rarely the site that performs
Design reviews happen on a large desktop monitor over fast office wifi. Customers arrive on a three-year-old Android phone on mobile data. Almost every serious performance problem we inherit was invisible in the room where the site was approved.
- “Make it look modern and premium”
- “We want a big video on the homepage”
- “Can we have animations on scroll?”
- “Match this design we saw”
- “Just make the old content fit”
- How fast the first meaningful content appears on a mid-range phone
- Whether the page can be crawled, parsed and understood without JavaScript
- Whether the URL structure survives the next hundred pages you publish
- Whether someone non-technical can edit a page without breaking layout
- Whether every old URL redirects to its correct replacement on launch day
The most expensive mistake: launching without a redirect map. A redesign that changes URLs without one-to-one redirects can discard years of accumulated search equity in a single afternoon — and recovering it takes far longer than the rebuild did.
What you actually receive
Every engagement lists its artefacts up front. You should never have to ask what “website development” includes, and you should own everything at the end of it.
| Deliverable | Format | What it is for |
|---|---|---|
| Sitemap & URL plan | Document + spreadsheet | Fixes the information architecture and URL structure before anyone writes code, so the site can grow without future migrations. |
| Wireframes | Figma | Page-level structure and content hierarchy agreed before visual design, which is where most expensive late changes come from. |
| Design system | Figma library | Components, type scale, spacing and colour tokens so new pages stay consistent without a designer. |
| Front-end build | Source repository | Server-rendered, component-based code you own outright and can hand to any developer. |
| CMS configuration | Live environment | Editable page blocks with guardrails so non-technical staff can publish without breaking layout or performance. |
| Schema markup | JSON-LD | Organisation, breadcrumb, service and FAQ markup so search engines can parse what each page is. |
| Redirect map | Spreadsheet + config | One-to-one mapping of every old URL to its replacement, which is what protects existing rankings at launch. |
| Analytics & events | GA4 + Search Console | Conversion events defined and firing, so the site's performance is measurable from day one rather than months later. |
| Accessibility pass | Report + fixes | WCAG AA contrast, focus states, labels and keyboard navigation — increasingly a legal requirement, not a nicety. |
| Handover pack | Docs + recorded walkthrough | Credentials, architecture notes and editing guides so you are never dependent on us to make a change. |
Scope varies by project size — a five-page site does not need the same design system as a two-hundred-page one. The proposal lists exactly which of these are included before you sign anything.
Five stages, in this order, for a reason
Structure before pixels, pixels before code, code before content migration. Working out of order is what causes rebuilds.
Analytics review, current rankings, what pages actually earn traffic, and what the site needs to do commercially.
Sitemap, URL plan and wireframes. Content hierarchy resolved before any visual design begins.
A component system rather than a set of page pictures, so every future page inherits the same rules.
Server-rendered front end, CMS wiring, schema, accessibility and performance budgets enforced as we go.
Redirects applied, Search Console verified, analytics confirmed firing, then 30 days of fixes included.
The things we will not ship without
These are not upsells. A site that fails on any of them is not finished, and we would rather argue about it during the build than after launch.
Measured on field data from real devices, not a lab score on a fast laptop. Performance budgets are enforced during the build, because retrofitting speed afterwards is far harder than protecting it.
Server-rendered HTML so crawlers, AI answer engines and assistive technology all receive the actual content rather than an empty shell that needs scripting to fill.
Headings used for structure rather than for font size. It is the cheapest ranking factor available and one of the most commonly broken.
A one-to-one redirect map applied at launch. Without it a redesign discards accumulated authority, which is the single most damaging launch mistake we see.
Contrast, focus states, labels, keyboard paths and alt text. It widens your audience, reduces legal exposure, and correlates closely with clean semantic markup.
Source code, domain, hosting and analytics in your accounts. No proprietary page builder that holds the site hostage if you ever change agency.
Four shifts worth building for
Building to today's baseline means launching already behind. These are the changes we design around now.
Assistants and AI summaries extract from server-rendered markup. Sites that render content only in the browser get skipped entirely, which is becoming a meaningful traffic risk.
Interaction to Next Paint measures every interaction, not just the first. Heavy client-side JavaScript that once passed now fails, and it is the vital most sites currently struggle with.
The European Accessibility Act and equivalent rules elsewhere are turning WCAG conformance from good practice into a compliance requirement for many businesses.
The value of a build is now partly in how safely a non-technical person can publish. Sites requiring a developer for every change quietly stop being updated.
Three builds, three different problems
Composite scenarios drawn from situations we see repeatedly — they illustrate method, not the account of any single named client.
The targets we set for a website build
Performance targets written into the proposal, measured on field data after launch rather than claimed at handover.
These are planning targets rather than a record of past client averages; we agree a realistic range against your own baseline before an engagement starts. Performance depends partly on decisions you own — a site loaded with third-party tracking scripts after launch will not hold these numbers, and we will tell you when a request will cost you speed.
What clients ask before commissioning a build
Direct answers on cost, platform, timelines and what happens to your rankings.
It can, badly, and it is the most common way businesses lose organic traffic. The risk comes almost entirely from changing URLs without one-to-one redirects, dropping heading structure, or removing content that was ranking. We crawl the existing site first, map every URL, and treat the pages currently earning traffic as fixed requirements rather than things to redesign freely.
It depends on who maintains it. WordPress is sensible when your team publishes frequently and needs a familiar editor; it becomes a liability when it accumulates plugins nobody audits. A modern framework build is faster and more secure but needs a developer for structural change. We recommend based on your team, not on what we prefer to build.
It scales with page count, integrations and how much content needs writing or migrating. A focused site for a small business sits far below a multi-location or catalogue build. What moves the number most is not visual design but integration complexity, so we scope those first and give a fixed price rather than an hourly estimate.
Typically six to twelve weeks. The stage that slips is almost always content — not design or development. Projects that finish on time are the ones where content is being written in parallel from week one rather than gathered at the end.
Yes, completely. Source code, domain, hosting and analytics all sit in your accounts, and handover includes documentation plus a recorded walkthrough. We do not build on proprietary systems that make leaving difficult, because a client who stays only because leaving is hard is not a client relationship worth having.
Yes, and often that works well. If you have a brand system we build to it. If you have a designer producing page comps we will ask for a component system instead, since page pictures do not tell a developer what happens at other screen sizes or with longer content.
Thirty days of fixes are included, covering anything that does not work as specified. Beyond that we offer ongoing support, but it is optional — you own the code and can take it anywhere. We also verify analytics and Search Console are reporting correctly, since a site nobody measures cannot be improved.
Ready to build something that performs?
Send us your current site. We will crawl it, show you what is holding it back technically, and outline what a rebuild would need to protect and improve.
Further reading
Go deeper on this
The thinking behind the work. These guides go deeper on the methods this page describes — written by the team that runs them.
The 5-Second Website Test: Does Your Site Pass?
Visitors decide in 5 seconds whether to stay or leave. The exact first-impression checklist we run on every client website before launch.
Read the guide →Web DesignThe 2026 CRO Guide: Turning Traffic Into Revenue
A practical 2026 conversion rate optimization guide — the tests, page structure and psychology that turn existing traffic into more leads and sales.
Read the guide →