Web development
Websites that are still fast a year later
Plenty of sites launch well and then rot quietly. A plugin here, a tracking script there, an image nobody resized, and by the second year the homepage takes four seconds to show a sentence. We build for the state of the site after everyone has stopped paying attention to it.
What this covers
From a brochure site to a working application
The same principles apply at both ends of that range. What changes is how much of it is content and how much is behaviour.
Marketing sites
Fast, editable and structured so that adding a page next year doesn't require a developer. The content model gets designed before the layouts, which is the step most rebuilds skip.
Web applications
Dashboards, portals, booking systems and internal tools. Authentication, roles and an audit trail are part of the build rather than something added after the first security review.
E-commerce
Storefronts and checkout flows connected to the stock, pricing and payment systems you already run, rather than a second source of truth that drifts out of sync by Friday.
APIs and integrations
Connecting your site to a CRM, an ERP, a payment provider or your own backend. Including the unglamorous parts: retries, error handling and what happens when the other end is down.
Performance
Core Web Vitals treated as a requirement with a number attached, not a report someone reads after launch. This is also the part of SEO you have direct control over.
Accessibility
Keyboard navigation, colour contrast, semantic structure and screen reader behaviour, tested rather than asserted. It widens your audience and it is increasingly a procurement requirement.
Where we come in
The three calls we get most
"Our site is slow and we've been told it's costing us."
Usually true, and usually fixable without a rebuild. We measure first and tell you whether this is an afternoon of work or a genuine structural problem.
"The agency that built it has gone quiet."
No repository access, no documentation, and a hosting account in someone else's name. The first job is getting you ownership of your own site, before anything else.
"We've outgrown the no-code version."
The tool did its job for two years and now the workarounds outnumber the features. Often the right move is keeping the parts that still work and replacing only what’s stuck.
How it works
Content model first, pixels second
We agree the page inventory and the content model before anything is designed. It sounds dry, and it is, but it’s the step that stops a six-week rebuild turning into a six-month rewrite when someone asks where the case studies go.
After that you see working pages in a staging environment early and often, on your own devices rather than in a slide. Feedback on something real is worth more than sign-off on something imagined.
At handover you get the repository, the deployment pipeline, the hosting account in your name, and a written document explaining how to run it. If you never speak to us again, everything still works.
On rebuilding and search rankings
Replatforming loses rankings when URLs change and nobody maps the redirects. It is entirely avoidable. We build the redirect map as part of the work and check it before launch, not after somebody notices traffic has halved.
Tools
What we work with
Mainstream, well-documented tooling with a large pool of developers who can pick it up after us.
- Next.js
- Astro
- React
- TypeScript
- Node
- Tailwind
- PostgreSQL
- Prisma
- Vercel
- Cloudflare
- AWS
- Playwright
- GitHub Actions
- Core Web Vitals
Answers
Questions about building a site
Will rebuilding hurt our Google rankings?
Not if the URL structure and redirects are handled deliberately. We map every existing URL to its new home before launch and keep the metadata and structure intact.
Do we have to use a particular CMS?
No. We’ll recommend one based on who edits the site and how often, and we are happy to build against something you already own. There’s more on that on our CMS page.
Can you work with our designer?
Yes, and it usually goes well when they're involved from the content model stage rather than handed a page list. We can also handle the design if you'd rather have one team.
Who hosts it, and who owns the accounts?
You do, in your own name, whether that's Vercel, Cloudflare or your own AWS account. We'll set it up and take our access away whenever you ask.
What happens after launch?
Nothing you have to buy. If you want updates, monitoring and dependency patching handled, that's a monthly arrangement. If you'd rather take it in-house, the documentation is written for that.
Can you fix a site rather than replace it?
Often, and we'll say so if that's the honest answer. Plenty of slow sites need image handling, caching and a few dependencies removed rather than a new build.
Related
Often needed alongside this
Get in touch
Send us the URL and we'll tell you what we'd change.
If there's an existing site, a link is the fastest possible brief. If there isn't one yet, a paragraph about the business will do.