Before you approve a rebuild, get somebody to say what is actually wrong

The conversation that starts these

A founder gets in touch and says the site needs a rebuild. I ask what is wrong with it. The answer, almost every time, is some version of: it feels dated, it does not reflect where we are now, it is embarrassing when we send it to investors.

None of those is a bad reason to be unhappy. All of them are impossible to act on, and more importantly impossible to check afterwards. If you approve a rebuild because the site feels dated, there is no version of the finished thing that can be evaluated, because feels dated has no opposite you can test against. You will know whether you like it. You will not know whether it worked.

So the first thing I do now, before talking about scope or budget, is ask a founder to write down the problem in a form somebody else could disagree with. That single exercise talks about a third of people out of the project, which is a strange thing for someone selling website work to say and is nonetheless the right outcome.

The other thing worth saying early: I have taken rebuild projects that I thought were the wrong call, because the founder had decided and my job was to build a good site. Those went fine as projects and badly as investments, and I stopped doing it. If somebody cannot say what is wrong, the finished thing will be judged on whether it is liked, and being liked is not a spec anyone can hit reliably.

Three reasons that hold up

In my experience there are three reasons to rebuild that survive scrutiny, and it is worth checking whether yours is one of them before going further.

The positioning genuinely changed. You sell to a different buyer than you did two years ago, or the product does something materially different, and the site is arguing for a company that no longer exists. This is the strongest reason and it is the one where a rebuild is clearly cheaper than incremental correction, because almost every page is wrong at the level of argument rather than of detail.

The system underneath cannot support what you need next. You need multiple languages, or a proper resource library, or a component model that lets people ship a page without a developer. Sometimes the existing build genuinely cannot get there. Worth being sceptical here, because this reason is available to anyone who wants a rebuild and does not want to say so.

The visual language is honestly dating you, in a market where that is a signal. This is real in some categories and imaginary in others. If you sell design tooling it matters. If you sell payroll compliance software your buyers are not making a judgement about your gradient.

Notice what is missing from that list. Traffic being flat is not on it. Conversion being disappointing is not on it. Pages being wrong is not on it. Those are all real problems, and a rebuild is a poor instrument for any of them.

The question that does most of the work

If I had one question to ask a founder before a rebuild it would be this: what changed about the company, or has only the site changed?

If the company changed, rebuild. Positioning, buyer, product shape, price point. The site is arguing for a company that no longer exists and no amount of editing gets it there, because the structure itself is organised around the old argument.

If only the site changed, do not rebuild. What happened is drift. Pages accumulated, contradicted each other, went out of date, and the accumulated wrongness now reads as the site being bad. A rebuild resets that to zero and buys you about four good months, after which the same process starts again with the same absence of anyone watching. You will be back, and the second rebuild is not cheaper.

The reason this question works is that it is answerable and it is checkable by someone else. Your head of sales knows whether the company changed. Nobody has to interpret anything.

Questions to answer before you commit money

This is the list I now send before quoting. It takes a couple of hours, mostly spent finding out that nobody knows some of the answers, which is itself the finding.

If you cannot answer most of these, the rebuild will happen anyway and it will produce a nicer version of the same situation. That is not a catastrophe, it is just a large amount of money for four good months.

The two answers that predict the outcome

Two of those items carry most of the predictive weight, and I would look at them before the rest.

Naming three wrong pages. Founders who can do this immediately have been paying attention, and their rebuild tends to go well because the brief is grounded in specifics. Founders who cannot are describing a feeling, and their rebuild tends to become a long argument about taste, because there is nothing else to argue about.

Naming the owner. If the answer is the marketing team, or our agency, or we will figure that out after launch, the decay clock starts on the day the new site ships. This is the single strongest predictor I have found of whether a site will need rebuilding again in three years, and it costs nothing to establish beforehand.

What a rebuild is genuinely good at

I do not want this to read as an argument that rebuilds are a scam. They are good at specific things and it is worth being clear about which.

They are good at resetting an argument. If the story changed, restructuring the whole site around the new story in one coordinated pass is much better than editing your way there page by page, because the intermediate states are incoherent.

They are good at removing accumulated structure nobody will remove incrementally. The six landing pages nobody wants to delete individually get resolved as a matter of course when the information architecture is redrawn.

They are good at forcing decisions. A rebuild is one of the few events that gets a whole company to agree what it says about itself. That is genuinely valuable and it is worth naming as a benefit, because it is often the real reason a rebuild is being proposed even when the stated reason is something else.

What it is bad at

It is bad at anything that requires the site to keep being right. A rebuild is an event, and correctness is a process. Handing a company a new site does not give them the practice of keeping it correct, and the new site starts drifting the day it launches.

It is bad at answering questions you did not know your buyers were asking, because the brief is written from what you currently believe. A rebuild will faithfully build the site you thought you needed, which is different from the site your buyers needed.

It is bad at conversion in the way people hope. There is a strong instinct that a better looking site converts better, and sometimes it does, but attributing it is nearly impossible because everything moved at once. If conversion is the problem, changing one page and watching is cheaper, faster, and produces an answer rather than a feeling.

And it is bad value if the underlying issue is that nobody owns the site, because you are paying to reset a symptom while the cause is untouched.

A rebuild is an event. Being right is a process. Buying the first does not give you the second.

What the money buys, compared honestly

It helps to put the two options side by side in cost terms, because the comparison is rarely made explicitly and the numbers are not close.

A rebuild is a fixed, large, one time spend with a delivery date, and it produces a site that is correct on the day it launches. A correction programme is a smaller recurring spend with no launch, and it produces a site that stays correct. Those are genuinely different products and the second one is what most founders describe wanting when they ask for the first.

The comparison that matters is not price against price. It is price against how long the result lasts. A rebuild that is correct for four months and then drifts costs the full amount every three years. A correction practice that keeps the site right does not reset, and it also removes the reason for the next rebuild.

I am not going to put invented numbers on this, because the ratio depends entirely on your team and your site. But you can calculate your own in about ten minutes: take the last rebuild quote, divide by thirty six, and ask whether that monthly figure would have bought somebody paying attention. For most companies I have had this conversation with, the answer is uncomfortable.

The mistake almost everyone makes with the budget

Website budgets are shaped like a project because that is how they get approved. A number, a scope, a delivery date. Everything after delivery becomes an ad hoc arrangement, and ad hoc arrangements are the first thing cut when a quarter is tight.

The version I argue for is to split the number in the same conversation. Reserve a portion for the twelve months after launch, and name what it is for: keeping pricing consistent, turning repeated sales questions into pages, fixing the things that will be discovered in month three.

Founders resist this because it looks like paying for a smaller site. It is more accurately paying for a site that is still correct in eighteen months, which is the thing they actually wanted when they asked for a rebuild.

If you cannot get that reserve approved, it is worth knowing that now rather than discovering it later. It tells you that internally this is a project rather than an asset, and you should plan for the three year cycle rather than pretend you are escaping it.

What to do instead, when it is drift

If the honest answer is that only the site changed, the alternative is not doing nothing. It is a much smaller and much less exciting piece of work.

Fix the contradictions first, starting with pricing, because that is the one a buyer is most likely to catch. Decide which page is canonical for each fact and point the others at it. Take the three questions sales answers most often and give each one a page or a section with a heading that answers it. Delete or consolidate the campaign pages that compete with each other, or at minimum decide which one is canonical and stop sending the others.

That is usually a few weeks rather than a few months, and it addresses the actual complaint. The site stops being wrong. Whether it also stops feeling dated is a separate question, and asking it separately is the point.

How to evaluate the decision afterwards

Whichever way you go, write down beforehand what you expect to be different, and make it something a person could check. Not a metric target, which invites gaming and gets defended rather than examined.

Useful expectations sound like: the sales team stops sending a workaround link for the integrations question. Nobody asks us what a seat costs on a discovery call. We can add a customer story without a developer. Those are checkable in six months by asking one person.

Then actually check. The reason the three year cycle repeats is that nobody ever evaluated the last rebuild, so nobody learned whether the reasoning held. Writing down two checkable expectations before spending the money is the cheapest thing in this entire article and it is the one most often skipped.

Where this connects to what we do

We spent six years building Webflow sites for SaaS teams, startups and agencies, and I have quoted for a lot of rebuilds. The ones that went well had a founder who could name what was wrong. The ones that turned into taste arguments had a founder who could not, and that was visible in the first call rather than in month three.

Creogen is the thing we are building for the case where the answer is drift rather than a changed company: tying findings to specific URLs, recording what a change was meant to do, and checking afterwards. Creobot is the input side, collecting the questions visitors ask that no page answers. Both are in private development and neither is required for anything in this article.

The checklist above is a two hour exercise with no software. If it talks you out of a rebuild, that is a good outcome and I would rather have that conversation than take the project.