3 min read
Rebuild the site, or fix what you have?
Most teams treat a rebuild as a solution. It isn't. It's the most expensive guess you make when you don't know which part is broken.
Furkan ÇolakDeveloper

Most enquiries reach us with the same sentence: “The site feels dated, let’s rebuild it.” So we ask the follow-up: which job the site is failing to do. The answer usually doesn’t come. The sentence isn’t a diagnosis. It’s a sign that nobody has made one.
A rebuild is not a solution. It’s the most expensive guess you make when you don’t know which part is broken.
What’s underneath “let’s rebuild it”
The impulse almost never comes from visitors. A team that has lived with a site for six months gets tired of it; a visitor has spent forty seconds there in total and hasn’t looked long enough to notice the design. Jakob Nielsen calls this exposure hours: the side that finds the design boring is the side that sees it every day (NN/g, “Fresh vs. Familiar”).
That doesn’t mean the site is fine. It means boredom isn’t a measurement.
What incremental work actually buys you
Being cheaper is the secondary advantage of fixing things in place. The primary one is that you can still see the link between what you changed and what happened.
Simplify the comparison on the pricing page, halve the fields on the enquiry form, and two weeks later you hold a piece of knowledge. Change the navigation, the copy, the visual language and the form flow in the same week, and whether the numbers go up or down you won’t know why, so next time you’ll guess again.
That’s the least discussed cost of a rebuild: it resets what you’ve learned.
The two cases where a rebuild is right
Nielsen defends radical change in only two scenarios, and both match what we see.
The first is having no habit worth protecting. If the site gets three hundred visitors a month and the target is thirty thousand, there is no risk of breaking familiarity; there is no familiarity to break.
The second is a structure that has lost its own logic. When years of additions have produced four separate navigation schemes that don’t touch each other, fixing pages one at a time just adds a fifth. The problem isn’t in the pages; it’s in the relationship between them, and you can’t repair a relationship piecemeal.
Most requests fall into neither case.
Three questions to answer first
Where do people stop? Set up one funnel in analytics and find the drop. The answer should look like “two percent of pricing-page visitors reach contact”, not “the homepage isn’t pretty”.
How many people have you watched? Most teams commission a rebuild without ever watching five prospects struggle with the current site. Those five sessions tell you more than a three-month project will.
What number makes this a success? If it isn’t written down beforehand, the measure of success after launch becomes “the new one looks nicer”. By that measure every project succeeds and nothing is learned.
With those three answers, the right path is usually obvious. Without them, the correct first job isn’t a rebuild. It’s producing the answers.
Recommended articles

Choosing a typeface and loading it on the page
Loading six cuts instead of three adds a few hundred kilobytes, and nobody can see the difference.

How to move a domain without taking email down
Address records and mail records live in the same zone and do entirely different jobs. A migration touches only one of them.

What hreflang links to what on a multilingual site
A set of hreflang annotations that is not reciprocal gets ignored entirely. Every page has to list itself as well.