Services / Web / Redesigns & rescues

Slow, dated, or abandoned mid-build, we take it from here

Not every project starts from nothing. Some start from a site that has accumulated twenty plugins and four seconds of load time; some start from a repository the last developer stopped answering emails about. Both are fixable, and the first step is identical: an honest assessment of what is actually there.

Start the conversation →See the technology

Why it matters

The cost is the wait

Websites do not fail all at once. They accumulate: a plugin here, a tracking script there, a page built in a hurry for a campaign that ended two years ago. One day the site takes four seconds to appear on a phone, nobody can say what half the code does, and the person who could has left. Rankings drift down, the bounce rate drifts up, and the quotes to fix it vary by a factor of five because nobody wants to look inside first.

The other version is a rescue. A build that stopped part-way, a developer who has gone quiet, a platform chosen for reasons nobody can now reconstruct. These projects are usually salvageable and almost always cheaper to finish than to restart, but only once somebody has established what is genuinely there, which is real work, and which we do as a paid piece with a written deliverable rather than as a free guess in a sales call.

Either way, the risk everybody worries about is the same: losing the search traffic you already have. That is a solved problem when it is treated as a project (a full inventory of existing pages, a redirect map, structured data preserved, and monitoring through the switchover) and a genuine disaster when it is treated as a checklist item on launch day.

What you actually get

Built to be trusted

What a redesign or a rescue actually involves, beyond the visible change.

An honest audit first

Speed measured on real devices, accessibility, security exposure, search health, code quality, and what each dependency is genuinely doing. You get the findings as a document you own, whether or not you go on to hire us for the work itself.

Search rankings protected as a deliverable

Every existing page inventoried, matched to a destination and redirected, with structured data, canonical addresses and internal links carried across. Monitored daily through launch so a drop is caught in days rather than in next quarter's numbers.

Speed as a measured target, not an adjective

We agree the numbers up front, measure them from real visitors rather than a laptop on office wifi, and enforce them automatically afterwards so the site cannot quietly get slow again over the following year.

A design refresh proportionate to the problem

Sometimes a site needs a new brand expression. Often it needs the existing one applied consistently and legibly. We will tell you which, because a full redesign you did not need is an expensive way to solve a speed problem.

Rescue without the rebuild, where possible

Where the existing codebase is sound, we stabilise it, document it and carry on. Rebuilding is a decision with a real cost, and it should follow evidence rather than a developer's natural preference for starting again.

Migrated in stages, if that suits you

A section at a time behind the same domain (the blog first, the shop later) so the cost and the risk are spread rather than concentrated into one enormous launch weekend.

Where it earns its keep

Same pattern, different desks

The three situations we are usually called into.

01 · Retail & consumer brands

The site that got slower every year

The problem: A long-running site carrying years of plugins, tracking scripts and old campaign pages. It takes several seconds to become usable on a phone, mobile conversion is visibly worse than desktop, and rankings have been slipping without any obvious cause.
What we build: An audit establishing what each script actually costs, a rebuild of the public site on a fast foundation, imagery converted and resized automatically, and a full redirect map so the accumulated search equity moves across intact.
What changes: A site that becomes usable in a fraction of the time on mobile data, a documented speed budget that prevents the same slow decay recurring, and rankings watched daily through the switchover.

02 · B2B & professional firms

The brand moved on and the website did not

The problem: New positioning, new services and a new logo, applied to an old site in patches. Pages contradict one another, the services listed do not match what the firm now sells, and editing anything requires the one person who knows where the templates live.
What we build: A content inventory with a decision on every page (keep, rewrite, merge or delete), a consistent design system applied across whatever survives, and a content system the marketing team can drive without help.
What changes: A site that says one thing rather than four, a smaller and considerably better set of pages, and a marketing team that can publish without raising a ticket.

03 · Funded startups & stalled builds

The developer stopped replying

The problem: A half-finished platform, no documentation, no handover, and no certainty about what works. The instinct is to start again; the budget rarely allows it and the deadline never does.
What we build: A paid technical review producing a written assessment (what exists, what is safe, what must be replaced and what merely needs finishing), followed by stabilisation, tests around the critical paths, and completion of the remaining work.
What changes: A clear-eyed picture within a fortnight instead of a rewrite by reflex, and in most cases a working product finished for a fraction of the cost of starting over.

The technology

The tools behind it, named

Rescue work starts with whatever is already there. These are the platforms we most often inherit, and what we rebuild onto when rebuilding is the right call.

6 layers · 32 technologies

What we usually inherit

We have taken over sites on all of these. Inheriting one is not a problem in itself. The only question is whether it is worth keeping.

WordPress
WooCommerce
Webflow
Shopify
Ghost
Statamic

What we rebuild onto

A foundation where pages are rendered ahead of the visitor and mistakes are caught before launch rather than by your customers.

Next.js
React
TypeScript
Tailwind CSS
Astro

Content, moved intact

Years of pages, posts and images migrated rather than retyped, into an editor your team can genuinely use afterwards.

Sanity
Storyblok
Payload
Contentful
Cloudinary

Protecting the traffic you already have

The inventory, the redirect map and the monitoring that decide whether a relaunch is invisible to Google or the start of a bad quarter.

Google Search Console
Google Analytics
Matomo
Screaming Frog

Proving it is actually better

Measurements before and after, plus automated checks that stop the improvement quietly decaying over the following year.

Lighthouse
GitHub Actions
Vitest
Cypress
Chromatic
Playwright

Launch and aftercare

A rehearsed switchover with a documented way back, then monitoring that tells a person before it tells your customers.

Cloudflare
Vercel
Let's Encrypt
Sentry
Better Stack
Uptime Kuma

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

The audit takes one to two weeks. What follows depends entirely on what it finds, which is rather the point of doing it first.

Audit, as a paid deliverable

One to two weeks producing a written assessment: speed measured on real devices, search health, accessibility, security exposure, code quality, and a plain-language account of what each part of the site is costing you. It is yours regardless of what you decide next.

Fix or rebuild, decided on evidence

Some sites need a rebuild. Some need a week of targeted work (images, third-party scripts, caching, a handful of templates), for a fraction of the cost. We present both options with the numbers attached and let you choose.

Inventory every page

Every existing address, its traffic, its rankings and its destination. Nothing gets deleted by accident, and the pages quietly earning you enquiries are identified before anybody touches them.

Build alongside the live site

The new site is built and reviewed on a private preview while the current one keeps trading. Nothing is switched over until you have clicked through the real thing yourself.

Rehearse the switchover

Redirects tested in bulk, DNS and certificates prepared in advance, analytics carried across, and a documented way back. Launches go wrong when they are attempted for the first time on the day.

Watch the numbers for a month

Rankings, crawl errors, speed and conversion tracked daily after launch. Most migration problems are entirely fixable if they are spotted in the first fortnight, and genuinely expensive if they are spotted in the first quarter.

Before you commit

The questions worth asking

Will we lose our Google rankings?

Some movement in the first few weeks is normal even on a well-executed migration. Search engines have to recrawl and reassess, and it settles. What causes lasting damage is missing redirects, changed page structure and lost content, and those are preventable with the inventory-and-redirect work above. We will not promise that your rankings will improve, because that depends on far more than a rebuild. We will commit to protecting what you already have and to monitoring it daily through launch.

Can you fix our site without rebuilding it?

Frequently, and we will say so when it is true. A significant share of slow sites can be substantially improved by dealing with images, third-party scripts, caching and a few templates, days of work rather than months. The audit exists precisely to establish which situation you are in, which is why we sell it as a standalone piece rather than bundling it into a pitch.

How bad is it, really?

That is what the audit answers, in writing and in plain language. What we can say generally is that sites are rarely as bad as their owners fear and rarely as good as the previous developer claimed. The genuinely serious findings tend to be security ones (abandoned plugins, exposed admin routes, credentials committed into the code) and those are usually quick to fix once someone has actually looked.

Our last developer disappeared. Can you take it over without them?

Usually. What matters is whether you have access to the hosting, the domain and the code repository. That is the first thing we check. If any of the three is missing, recovering it becomes step one and can take time. Missing documentation is inconvenient but entirely normal; missing access is the thing that actually blocks a handover, and it is worth confirming you hold all three before you ever need them.

Can we do this in stages instead of one big launch?

Yes, and for larger sites it is often the better route. Sections move across one at a time behind the same domain, which spreads the cost, reduces the risk of any single launch, and lets you see the benefit early. The trade-off is a period where two systems run side by side, which adds some complexity and a little cost, worth it above a certain size, and unnecessary below it.

How long before we see a difference?

Speed improvements are immediate and measurable on day one. Conversion effects usually show within weeks. Search effects are the slow ones: expect a settling period of a few weeks and a fair comparison at around three months, because anything measured earlier is measuring the recrawl rather than the outcome.

Send us the site and the bad news

Give us the address, or the repository nobody has touched in six months. We will tell you what is actually wrong, what it would take to fix, and whether it needs rebuilding at all.

Start the conversation →

Explore more

The rest of Websites & Web Platforms

Company websites Online stores Customer portals Internal tools Web apps & SaaS ← All of Web