Think about the first time you got into a rental car in a foreign country. The engine, the seats and the dashboard were all unfamiliar, and you adjusted within minutes. Then you reached for the indicator and turned on the windscreen wipers. You did it again at the next corner, and the one after that.
That small moment explains most of what goes wrong when software gets rebuilt. People don't mind new materials. They mind when the things they reach for without thinking are no longer where their hands expect them.
Every product that lives long enough collects patches: a feature squeezed in here, a fix there, a screen that grew one more button than it was designed for. Eventually someone asks whether it's time to start over. Sometimes it is. But the history of software is full of rebuilds that cost more than they saved, and they tend to fail in the same way.
The rebuilds people remember
In 2000, the programmer and writer Joel Spolsky published an essay called "Things You Should Never Do", about Netscape's decision to rewrite its browser from scratch. The rewrite took years. While the company was busy rebuilding what it already had, competitors kept shipping. His point was blunt: old code looks messy because it contains years of fixes for real problems, and throwing it away means throwing those fixes away too.
In 2010, the news site Digg launched a redesigned version 4. It changed how the site worked, not just how it looked. Features long-time users depended on disappeared. Many of them left, and a large share of that audience moved to Reddit. Digg never recovered its position.
In 2018, Snapchat redesigned its app and moved things people used every day. The backlash was loud. More than a million people signed a petition asking for the old version back, and the company spent months adjusting.
In 2012, Microsoft shipped Windows 8 without the Start button that had anchored the interface since Windows 95. Users hated it. The next year, Windows 8.1 brought a Start button back, and Windows 10 restored a full Start menu.
One of the most expensive recent examples came in May 2024, when Sonos released a rebuilt version of its speaker app. The new app was meant to be a better foundation, but it launched missing features people relied on, like sleep timers and parts of local music library support, and it was buggy for many users. The backlash lasted months. The company apologized publicly, delayed new products to fix the app and warned investors the problems could cost it US$100 million or more in revenue. Its CEO stepped down in early 2025.
None of these failed because the new version was ugly. They failed because they changed what people did and where they did it, or removed it altogether, all at once.
When to rebuild
The urge to rebuild is strongest when everything is on fire: bugs piling up, customers complaining, the team exhausted. That's usually the worst time.
A rebuild in the middle of a crisis means redesigning a product you don't fully understand yet, while it's still changing every week. The patches are annoying, but they're also information. Each one is a record of something real that the original design didn't anticipate.
The better moment is when things are calm:
The product is stable. Error reports have dropped and aren't arriving in waves.
The urgent list has shrunk. You're no longer fixing things just to keep customers.
You know what the product really is, because you've watched people use it long enough.
The patches have started to fight each other. New features no longer have a natural place to go.
There's another signal worth watching: when the platform underneath can't express how your product works anymore. If you're forcing a content management system or an online store builder to do something it was never designed for, and doing it by hand every time, that's not a patching problem. That's a foundation problem.
Keep the controls where they are
Here's the rule that separates rebuilds people barely notice from rebuilds people revolt against.
Don't change what things do or where they are. Change how they're built and how they look.
In practice, that means:
Functions stay the same. Everything people could do before, they can still do, the same way.
Layout changes as little as possible. Menus, key buttons and main sections stay roughly where people expect them.
The internals can change completely. Code, data structure, architecture, security and error handling can all be replaced.
The interface can change. Visual style, components, typography and details.
Even the feeling can change. The product can feel entirely new while working exactly as before.
Back to the car. Redesigning the center console, with new materials, a new screen and new trim, is easy. Drivers adapt in a day. Moving the air conditioning controls into the door is a different story. Every driver will reach for the old spot for weeks, and some will be annoyed every single time. People build habits around functions and positions. They barely notice styling.
Protect your front desk
There's an old observation about hotels that makes the same point from a different angle. A hotel might renovate its rooms every few years: new furniture, new colors, new bathrooms. Its lobby and front desk often change far less. Returning guests recognize it. For some, it's the place their parents first brought them years ago. The rooms can keep up with the times because the front desk stays familiar.
Every product has a front desk: the screen people land on, the menu they navigate by, the one action they do fifty times a day. Find it. Protect it. Let everything else move on.
What really changes underneath
The most valuable parts of a rebuild are often invisible to users. That's a good thing. A rebuild is usually about three things they'll never see:
Security. Replacing old patterns with safer ones, tightening who can see what.
Structure. Reorganizing data and code so new features have somewhere natural to go, instead of being squeezed in.
Error handling. Making the product fail gracefully, catching problems before users hit them, and knowing immediately when something goes wrong.
Users experience these as "it just works better now". That's exactly the outcome you want.
Two ways to replace a system
Engineers tend to talk about two broad approaches to replacing a system that's in use.
The strangler fig. The software writer Martin Fowler named this pattern in 2004, after a fig that grows around a host tree until it can stand on its own. Instead of replacing everything at once, you build new parts alongside the old system and move traffic over piece by piece, until the old system can be switched off. Twitter did something like this in the early 2010s, when it gradually moved its busiest services off the Ruby on Rails code it launched with, onto faster systems, while the site stayed up. The famous "fail whale" error page became much rarer along the way.
The full switch. You build the new version completely, test it thoroughly and replace the old one in a single move. This works best when the rebuild keeps functions and layouts stable, so users don't have to relearn anything on switch day.
Neither is always right. The strangler fig suits large, complex systems where one big switch would be too risky. The full switch suits smaller products, or rebuilds that are mostly about internals and interface, where running old and new side by side would only add confusion.
Test fully, switch once
A common assumption is that big changes should roll out in small pieces. For many products that makes sense. But when a rebuild keeps functions and layouts stable, a single switch can be cleaner than a long period where old and new parts live side by side.
The trick is doing all the risky work before anyone sees it. Rebuild on a separate environment, a local or staging copy, and test the new version completely against real scenarios. Only switch when it's genuinely ready. Then switch once.
If you've kept the controls in place, there's no need to warn every customer individually or run training sessions. A short announcement inside the product is enough, because nobody will lose their way. If you find yourself planning long explanations for a redesign, that's a sign you've changed too much at once.
Don't forget the data
The riskiest part of any rebuild or migration isn't the interface. It's the data: past orders, customer records, licenses, histories.
Before moving anything, make sure you have a complete, tested backup, and a way to confirm that everything arrived on the other side. If some history lives in another service, like a payment provider's records, know how you'd recover it before you need to. And if customers might worry about their data, tell them plainly that it's safe. Silence during a migration feels much worse than a short, clear message.
The exception: your marketing site
Here's the part that sounds like a contradiction. Products should be rebuilt rarely and carefully. Marketing sites should almost never be rebuilt from scratch at all. They should be patched, constantly.
A marketing site is your front line. Your offer, pricing, proof and positioning change all the time, and the site has to keep up. That fight never ends, so there's never a calm moment to wait for. A big-bang rebuild of a marketing site often goes stale by the time it launches. Steady improvements, one page and one section at a time, keep it honest and current.
So the rule depends on what you're working on. For a product people rely on daily: wait for calm, keep the controls in place and rebuild underneath. For the site that sells it: keep patching, and never stop.
Before you rebuild, ask
Is the product stable, with the urgent fixes mostly behind you?
Which functions and positions do people rely on most, and can you keep them exactly where they are?
Is the problem the design, or the foundation underneath it?
Have you tested the new version fully, away from real users?
Is your data backed up, verified and recoverable?
Would the change fit in one short announcement?
Is this the product, or the marketing site? The site gets patched instead.
Layerice is a software design and development studio for businesses. We rebuild products without making people relearn their work.