Inheriting somebody else’s build.
What we check before touching it.
Most of our rebuilds start as a rescue. The first day is not design work, it is establishing what you actually control and making sure nothing can be lost while we work.
Start a projectThe first conversation, before any work
Most rescues come to us in one of four shapes, and which one you are changes the price more than anything on the page does.
The developer has gone quiet
The site works but nobody can change it. The first job is establishing what you actually control: the domain, the hosting, the code, the database, the payment account. Often the answer is "less than you think", and finding out early is the whole value of the first week.
It is slow and nobody knows why
Usually the platform rather than the hosting: a theme with a stack of plugins and four render-blocking scripts is slow on any server. We measure before recommending, because moving a slow site to faster hosting buys a fraction of a second and a rebuild buys the rest.
It breaks when it matters
Checkout failures, forms that never arrive, orders that vanish. We reproduce the failure before claiming a fix, and the usual culprit is a write that fails silently rather than anything dramatic.
It needs to do something it was never built to do
The commonest one. A brochure site that now has to take payments, or a shop that now has to talk to a till. Sometimes that is an extension; sometimes the honest answer is that the foundation will not carry it.
What we check in the first day, every time
This list is not theoretical. Every item on it is something we have found on a real live site.
Does a copy of the code exist anywhere safe?
We have found live sites whose newest work existed on no laptop and in no repository — only in the deployment. Until there is a copy in version control, nothing else should be touched, because a single mistake is then unrecoverable.
Are there secrets committed where they should not be?
A live payment key in an example environment file, a password in a readme, an admin passcode in a note. If one is found it gets rotated, because scrubbing history is not enough once it has been published.
Who holds the domain, the DNS and the mail?
Mail records are the ones that break during a website change. We list every mailbox and anything that sends email before touching DNS, because losing mail is worse than having an old site for another week.
Is anything serving that should not be?
We have found deployments still answering the public a week after they were supposed to be down, with a flag in a dashboard claiming otherwise. Only a request to the live URL proves what is being served.
Does the database match the code?
Migration files in a folder are not evidence. We read the live schema, because the two disagree more often than anybody expects, and a missing column is how pages quietly degrade.
Do the writes that matter actually fail loudly?
Orders, payments and enquiries. A write that returns a success and saves nothing is the single most expensive bug class we find, and it is invisible until somebody counts.
Where do enquiries go, and do they arrive?
We send a real one. Broken forms, mail in spam and a contact page nobody has tested in two years are the cheapest fixes available and they are nearly always there.
What does search already know about it?
Before anything changes, we take the current positions and the indexed URLs. A redesign that drops rankings usually does it by forgetting the old addresses, and that is entirely avoidable.
The order we fix things in
| Order | What | Why first |
|---|---|---|
| 1 | Get a safe copy and rotate anything exposed | Everything else is reversible once this is true |
| 2 | Fix the money and the leads | A broken checkout or a lost enquiry costs more per day than anything cosmetic |
| 3 | Preserve the addresses | 301s from every old URL before any structure changes |
| 4 | Make it measurable | Analytics and Search Console verified, so the rebuild can be judged rather than argued about |
| 5 | Then speed, then design | In that order, because speed is measured and design is felt |
When we would tell you to keep it
We are not short of work, so this is an honest section rather than a humble-brag.
The site is fine and the problem is elsewhere
Plenty of businesses arrive convinced the website is the issue when the enquiries are arriving and nobody is following them up, or when nothing is being asked of customers at the counter. A rebuild would not fix either.
It is a content problem wearing a design problem
If the pages do not say anything specific, a new design will be a prettier version of the same silence. Sometimes the right spend is words and photographs on the site you already have.
The platform suits a team that will keep it patched
If somebody in-house genuinely maintains it and publishes to it weekly, replacing it with something only we can change may be a step backwards.
You are about to change the business
If the model is shifting in six months, rebuilding now means paying twice. We would rather stabilise what you have and build the real thing once.
Before you ask.
We have lost contact with our developer. Can you still help?
Will a redesign lose our Google rankings?
Can you just make it faster?
Do you take over WordPress sites?
What if you find something bad?
Ready to get started?
Tell us what you need. We will scope it, price it and build it.
Start a project →