A performance budget that bites
Page weight and Core Web Vitals thresholds agreed up front and enforced in the build. Exceeding the budget fails the deploy, so speed cannot erode release by release.
Website Development
BuildA website is not a brochure. It is the first shift of your sales team.
Fast, accessible, search-legible websites built on a performance budget — and handed over as a codebase you own, not a platform you rent.
Typical stack
- Next.js
- React
- TypeScript
- Tailwind CSS
- PostgreSQL
- Vercel
- Playwright
Written for: A business whose current site was built by someone unreachable, loads slowly, and cannot be edited without a quote.
Who it is for
Is this built for a business like mine?Built for businesses whose website has a job to do.
Not every business needs a custom build — a template genuinely is enough for some. These are the cases where it is not, because the site is load-bearing.
What we see
Paid traffic lands on a page that takes six seconds on 4G, and the phone number is below the fold on a phone.
What we build
A site built to a mobile performance budget where calling and booking are the primary actions, not buried under a hero video.
The detail that matters
The budget is enforced in CI. A page that breaks it does not deploy.
What we see
Ad spend scales, the site does not, and every performance problem costs conversion on every session at once.
What we build
Storefronts and landing systems where speed is a build gate, and product structured data is emitted rather than bolted on.
The detail that matters
Structured data comes from the same content source as the page, so it cannot drift out of sync.
What we see
Marketing cannot ship a page without an engineer, so the roadmap and the website compete for the same people.
What we build
A content-modelled site where a new page or service is a content change, and navigation, sitemap and schema follow automatically.
The detail that matters
Adding a service updates the menu, the footer, the sitemap and the schema with no code edit.
What we see
Patients cannot find opening hours or book online, and the site fails an accessibility audit that a public-facing service is expected to pass.
What we build
Location-aware pages, real booking integration, and WCAG 2.2 AA verified rather than claimed.
The detail that matters
Accessibility is tested in the pipeline, not asserted in a paragraph like this one.
What we see
Shippers are asked to email for a quote and to phone for a status, because the site is a brochure sitting in front of a TMS it cannot reach.
What we build
Customer-facing quoting and track-and-trace wired into the TMS, so the two highest-volume questions stop arriving as phone calls.
The detail that matters
We integrate on the TMS’s terms — file drop, EDI, a legacy endpoint — rather than requiring you to modernise first.
What we see
The direct booking journey is slower than the aggregator’s, so guests use the aggregator and the commission is paid on every one.
What we build
A direct booking path built to a mobile performance budget, reading live availability, with the enquiry-to-quote flow for groups and events.
The detail that matters
Measured against commission avoided, because that is the only number that decides whether this paid for itself.
What we see
Sign-up drop-off is highest at the verification step, and nobody can say which screen loses them because the funnel is not instrumented.
What we build
Onboarding flows built to a mobile performance budget with the verification step instrumented per screen, so abandonment is a number rather than a theory.
The detail that matters
Regulated copy and disclosures are content, versioned with the page — so what a user was shown on a given date is recoverable.
What we see
Trade customers cannot see their contract pricing, their order history or real stock without phoning inside sales.
What we build
An account-aware trade portal showing real pricing, live stock and reorder history, with the catalogue generated from the ERP rather than maintained twice.
The detail that matters
One source for the catalogue. A portal whose product data drifts from the ERP creates more calls than it removes.
And who it is not for
If you need a five-page site live next week for a fixed low budget, a good template on a good platform will serve you better than we will. That is a real recommendation, not modesty.
The problem
Do they understand what is actually going wrong?Most websites are slow, unowned, and quietly leaking.
The pattern is consistent. A site was built three years ago by an agency that has moved on, it scores badly on the metrics search engines actually use, editing anything requires a quote, and nobody can point to the page where visitors give up — because that page is not measured.
It takes five seconds on a phone, which is where most of the traffic is.
Changing a headline needs a developer, so the copy is three years old.
The code lives in an agency’s account and the only way to leave is to rebuild.
It fails accessibility basics — keyboard traps, unlabelled controls, contrast that does not pass.
What we build
What exactly would I be buying?Four decisions, made before the first screen is designed.
Nearly every failure above traces to a decision that was never consciously made. We make them at the start, in writing, because they are cheap then and expensive later.
Content modelled, not hard-coded
Pages are generated from a content source, so adding a service updates the menu, the sitemap and the structured data at once. Nothing is maintained in four places.
Accessibility as a gate
WCAG 2.2 AA, checked automatically on every build and manually with a keyboard and a screen reader. It is a pass condition, not a section in the proposal.
Legible to machines
Server-rendered HTML, semantic structure and structured data, so search crawlers and answer engines get the content without executing anything.
How it works
How does this actually function?What the build pipeline refuses to ship.
Quality that depends on remembering is quality that degrades. These checks run on every commit and block the deploy rather than filing a warning.
Commit
Lint & types
Accessibility
Performance budget
BlockedDeploy
Accessibility runs automated checks on every route, and a manual keyboard and screen-reader pass before each release.
The performance budget is a number in the repository. Exceeding it is a failed build, not a conversation.
Every deploy is previewable at its own URL, so review happens on the real thing rather than a screenshot.
What changes
What is different afterwards?What is different afterwards.
It loads before they leave
Built to a mobile budget from the start rather than optimised afterwards, which is the only version of this that holds.
Core Web Vitals passing on mobile, verified per release.
Your team can change it
Content lives where content belongs. Copy, services and pages change without a developer and without a quote.
Routine content changes made in-house, not ticketed.
You can leave
The repository and the hosting are in your accounts from day one. Ending the relationship is an access change, not a rebuild.
Full code and infrastructure ownership, from the first commit.
How we deliver
How does this start, and what do I get at each step?Six stages, and every one has an exit.
You can stop after any stage with something useful in hand. That is the point of naming the artefacts rather than the activities.
- 01
Intent mapping
Which pages exist, who arrives on each, what they are trying to do, and what the page must make easy. Structure follows that, not a template.
- Page inventory with the intent each serves
- Content model
- The pages we recommend not building
- 02
Budgets and gates
Performance, accessibility and browser support fixed as numbers before design begins, so they constrain design rather than survive it.
- Performance budget
- Accessibility target and test plan
- Browser and device matrix
- 03
Design system
Tokens, type scale and components built as a system, so page fifty looks like page one without anyone policing it.
- Token set and type scale
- Component library
- Contrast verified across every pairing
- 04
Build
Pages assembled from the system and the content model, with the gates running from the first commit.
- Working site on preview URLs
- CI pipeline with gates active
- Structured data emitted from content
- 05
Verification
Real devices, keyboard-only navigation, screen reader, throttled network. Not a desktop score screenshot.
- Accessibility audit report
- Performance results under throttling
- Cross-browser results
- 06
Handover
Repository, hosting, domain and documentation, in your accounts, with training recorded.
- Everything transferred to your accounts
- Editing and deployment documentation
- Recorded training session
Questions
But what about the thing that worries me?The questions people actually ask.
Do we own the code?
Yes, from the first commit, in your repository and your hosting account. There is no licence, no proprietary builder and no version of leaving that requires a rebuild.
How long does a site take?
A focused marketing site is typically six to ten weeks. Anything with real integrations — booking, commerce, an existing back office — depends on those systems, which is why the intent mapping stage exists before a number is quoted.
Can our team edit it without a developer?
Copy, pages and services, yes. Structural changes to how a page type works are a development task, and we are explicit during design about where that line falls so it is not a surprise later.
What about SEO?
The technical foundation is part of the build — server-rendered HTML, semantic structure, structured data generated from content, sitemap, and speed. Content strategy and authority building are a separate discipline, and we do that too, as a separate engagement.
What happens after launch?
Support is a choice, not a lock-in. Some clients keep us on a retainer, some take it in-house with the documentation. Both are fine, because the ownership position makes both possible.
The other half
A working site produces conversations.
Every form, chat widget and phone number on a site that finally converts creates inbound volume — usually more than the team that asked for the site was staffed for. We run those queues as well, so the launch does not quietly become somebody’s second job.
Live Chat SupportStart
What is the next step?Tell us the problem, not the specification.
A short call is usually enough to say which half of the business your problem belongs to, roughly what it costs, and whether it is worth doing at all.
Related services
- DevelopmentMobile App DevelopmentNative and cross-platform apps built where a mobile app is the right answer — offline capability, device hardware, or a workflow people run all day in the field.
- Digital MarketingSearch & Answer Engine OptimisationTechnical foundations, content that answers real questions, and structure that lets answer engines quote you — because a growing share of searches never produce a click.
- AI EngineeringAI AgentsAutonomous agents that plan, call real tools against real systems, and leave a trace of every action — with human approval gates on anything consequential.