Rebuild or retrofit: Two bets, One question nobody is asking

There are two product teams I want to tell you about. They work in different companies, in different cities, and they've never met each other. But they're running the same experiment right now, and the results are starting to diverge in ways that are worth paying attention to.

Both teams were facing the same pressure at the start of this year. Competitors were shipping AI features. Users were asking why the product wasn't doing what other tools were starting to do. Leadership was asking the same question in slightly different language. Something had to change.

Team A decided to rebuild.

Not gradually. Not by adding AI to what existed. They made the call that their existing architecture was built around assumptions that AI had made obsolete, and that layering capabilities onto an outdated foundation would produce something worse than starting over. They started a parallel build. New data model, new interaction patterns, new assumptions about what the product was fundamentally for.

Team B decided to retrofit.

They took their existing product and began adding AI capabilities systematically. A summarisation feature here. An intelligent suggestion layer there. An AI-assisted workflow in the part of the product where users spent the most time. Fast, incremental, shipped to users within weeks rather than months.

I've been watching both teams for the better part of six months. And the thing I want to tell you is that neither of them is obviously winning.

But they're losing in completely different ways. And understanding why tells you more about this decision than any framework I've seen published on the subject.

When you renovate an old building, you work within constraints that were set by someone else's decisions. The load-bearing walls are where they are. The plumbing runs where it runs. Every improvement you make is a negotiation with the original architecture, and some of the things you want to do simply aren't possible without tearing out something structural.

Skilled renovators know which constraints are real and which are just unfamiliar. The best ones can take a building that looks tired and make it feel new without touching the bones. But there are limits. There are always limits. And the renovator who doesn't know where the limits are will spend money on surfaces while the foundations stay problematic.

New builds have different problems. No inherited constraints, but no inherited advantages either. Every decision has to be made from scratch. The timeline is longer than anyone admits at the start. And the gap between the architectural vision and the lived reality of the building tends to widen in proportion to how ambitious the vision was.

Team A is building new. Team B is renovating. But both are discovering that they underestimated what the work actually required. The new build team underestimated the timeline. The retrofit team underestimated the seams.

Team B's AI features are live. Users are engaging with them. Some of them are genuinely useful. But six months in, the product feels like two things sitting next to each other rather than one thing that thinks. The AI suggestions arrive without context about what the user was doing before. The summarisation feature works on content that the rest of the product wasn't designed to process in that way. There are seams. Users feel them even when they can't name them.

The team knows this. They're iterating. But each iteration is another negotiation with the original architecture, and the original architecture was designed for a user who navigated, clicked, and waited. It wasn't designed for a user who expects the product to anticipate.

Team A is still building. The parallel product is later than the original timeline, because parallel products are always later than the original timeline. The existing product is getting some maintenance but no new features, which is creating its own set of problems with the current user base. The new build is impressive in the parts that are done. But the parts that are done are not yet a complete product. And the distance between an impressive partial build and a shippable product is not always as short as it looks from the inside.

Here is the question both teams should have asked before they made their decision, and that most teams making this decision right now are not asking clearly enough.

What do your users actually need AI to do?

Not what can AI do in your product. Not what are competitors doing. Not what would make the most impressive demo. What does the person using your product at nine in the morning, trying to do a specific thing, need the product to do differently than it does today?

Because the answer to that question determines which bet is right. But it's a different answer for different products, and most teams skip it because it requires sitting with users in a way that slows down the decision.

If the answer is: users need the product to get out of their way, anticipate their next step, and work with information they haven't manually entered, then the retrofit is going to keep producing seams. The foundation wasn't built for a product that anticipates. Rebuilding might be the honest answer.

But if the answer is: users need the product to do specific things faster, surface specific information more easily, and reduce friction in specific workflows, then the retrofit can deliver that. And delivering it in months rather than years is not a compromise. It's a different, valid bet.

The strategic error isn't choosing wrong between native and augmented. It's choosing without asking what the user actually needs the AI to do, and then building toward that with honesty about what the current architecture can and cannot support.

Both teams will probably be fine. They're smart, they're paying attention, and the pressure that forced the decision is real and worth responding to.

But the teams I've seen make this decision well didn't start with the architecture. They started with the job.

What is the product supposed to do for the person using it. What is AI uniquely able to contribute to that job. And what would have to be true about the product's structure for that contribution to feel like part of the product rather than a feature sitting on top of it.

Answer those questions honestly, and the rebuild-or-retrofit decision tends to make itself.

Skip them, and you'll be having this conversation again in eighteen months. With a more complicated codebase and the same fundamental question still open.