Rebuild vs Retrofit: Putting AI Into Old Software

If you have working software and you want to add AI, you face one real decision: retrofit the model into what exists, or rebuild the product around it. Most teams retrofit because it is cheaper this quarter. Most of them regret it within a year. The honest answer is that retrofitting buys you a demo and rebuilding buys you a product. Which one you need depends on whether AI is a feature of your software or the reason the software exists. Here is how I decide.

What retrofitting actually gets you

Retrofitting means you keep your data model, your workflows, and your UI, and you wire a model into a few spots. A generate button here, a summarize action there. It is fast. You can ship it in weeks. For a genuine side feature, it is the correct call. Not every product needs to be rebuilt around a model, and pretending otherwise is how people waste a year.

But retrofitting has a ceiling. The model can only reach the parts of your system you expose to it, and it can only act inside the constraints your old schema allows. You get intelligence bolted to the surface of a product that still thinks like it did before AI existed. That is fine for autocomplete. It is not fine when the AI is supposed to do the actual job.

What rebuilding means and costs

Rebuilding means you start from the question: if a capable model is always present, what should this product be? You redesign the workflow, the data model, and the interface around that assumption. It is slower and it is riskier. You are throwing away things that work today for a bet on what works better.

The payoff is leverage. When the model is load-bearing, one improvement to the model improves the whole product. When it is bolted on, model improvements barely move the needle because the model was never doing much. I explain the mechanics in how to design a product around a model. The short version: rebuilding is expensive once and cheap forever, retrofitting is cheap once and expensive forever.

How to tell which one your product needs

Ask one question. Is AI the value, or a convenience on top of the value? A project management tool that adds AI summaries is retrofitting territory. The value is coordination and the AI is a nicety. A personal injury intake system where the AI reads the records, qualifies the lead, and drafts the demand letter is rebuild territory. The AI is the value. Strip it and there is no product.

Be honest here, because the pressure is always to call your case a convenience so you can avoid the hard build. If a competitor rebuilds while you retrofit, they will out-execute you on the exact thing customers are paying for. I watched this happen across categories, which is why I built CaseSolo native from day one rather than adding AI to a generic case tool. The same logic drove why enterprise AI features fail: they were bolted onto products that could not support them.

The trap of the incremental retrofit

The dangerous path is the one that feels safe. You retrofit, it demos well, leadership is happy, and then customers ask for the AI to do more. So you retrofit again, and again, until you have a Frankenstein of prompts wired into a schema that fights you at every turn. Now a rebuild costs ten times what it would have at the start, and you have paying customers on the old thing. You have talked yourself into the worst version of both options.

If you can see that road coming, take the rebuild pain up front. The gap between a demo and a shippable product is where retrofits die, and it is much cheaper to cross that gap once than to cross it four times.

My rule

I retrofit when AI genuinely sits on the edge of the product and rebuild when AI is the product. For anything in my portfolio where the model does the core work, Ficary for bookkeeping being the clearest example, I rebuild. It costs more now. It compounds later. Retrofitting is a fine tactic and a terrible strategy. Know which one you are running before you start writing code, because the decision is much harder to reverse than to make.