Agentic rebuild: should you rebuild your software?

In short

• Many established software publishers are asking whether they should rebuild their product as agentic-first or evolve what they already have.
• Across eight criteria, neither approach wins everywhere: the progressive approach keeps the edge on business logic, compliance and the installed base; the rebuild wins on delivery speed and per-user adaptation.
• The deciding factor is often reversibility: the progressive approach lets you switch later, workflow by workflow; a full rebuild closes that door.

Three forces are pushing established software publishers to ask the question. Competition from new entrants who ship faster. The falling cost of development enabled by AI-assisted coding. And investors who expect a credible AI story. Hence the temptation: start over with agentic AI, or evolve an existing product that can sometimes feel heavy to carry?

An agentic rebuild carries a double promise: simpler, cheaper development, and renewed value for the customer. Each deserves to be checked before being taken for granted.

The available figures call for caution. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. This is not specific to agentic AI: RAND estimates that more than 80% of AI projects fail, twice the rate of conventional IT projects, and MIT finds that only 5% of enterprise generative AI pilots deliver a measurable impact on the P&L. The execution risk is real, and it has to be weighed deliberately.

Two approaches face each other in what follows. The progressive approach: the publisher keeps its existing product and adds agentic capabilities to it. The rebuild approach: the publisher dismantles it to start over on an agentic architecture, or a new entrant is born directly on that model. But what each criterion means depends first on a decision neither fully controls: the customer’s, who responds each time by choosing to stay, to switch, or to wait.

1. Proprietary data and customer history: an advantage that is hard to rebuild

Progressive approach. It natively preserves what has built up over time: customer history, specific configurations, exceptions handled over the years. It has nothing to win back and starts from what already exists. It also makes adoption easier for technical, product and customer support teams.

Rebuild approach. Raw data migrates fairly well today: a data lake absorbs the history without major difficulty. What resists is the business logic refined around it: business rules, workflows honed by use, exceptions handled case by case. Rarely documented, it lives in the legacy system’s code, and rebuilding it in an agentic architecture takes far longer, with more uncertainty, than a simple data transfer. A new entrant has neither this data nor this logic to rebuild, but no history to draw on either: it has to compensate by quickly collecting usage data, or through integration partnerships.

This is one of the criteria where the progressive approach’s advantage remains hard to match quickly. It also features among what remains defensible for a publisher in the face of general-purpose agents.

2. Compliance and regulatory liability: an asset, not a universal guarantee

Progressive approach. It inherits an existing product that has already been validated: payroll rules, filing obligations and accounting controls have been tested and corrected over years of real-world use. Compliance does not need to be proven again: it is in the product, and in the practices of the teams who maintain it.

Rebuild approach. Everything has to be revalidated. And an agentic system adds a question that deterministic systems did not raise: when an autonomous decision produces a regulated error (a miscalculated payslip, an incorrect accounting entry, accidental data destruction), liability has yet to be established, whereas it was already settled for a conventional system.

An incident in July 2025 illustrates this, outside any regulated scope. During a test run by the founder of SaaStr, Replit’s coding agent deleted a production database despite an explicit instruction not to make any further changes without approval, then tried to cover up its mistake. Replit’s CEO called the incident “unacceptable” and rolled out new safeguards right away. In an environment subject to legal obligations, the consequences would be of a different order. We covered these risks specific to agentic AI in a previous article.

A new entrant carries the same validation burden, without the experience accumulated on edge cases. On the other hand, it can build compliance in by design, with no legacy to reconcile with new constraints.

This criterion remains favorable to the progressive approach, with an important caveat: it only protects workflows subject to a specific regulatory obligation. A workflow with no compliance stakes does not benefit from it.

3. Delivery speed and development cost: the rebuild’s clearest advantage

Progressive approach. It has to work around the existing product with every new feature: preserving compatibility, testing interactions with the rest of the system, following validation cycles already in place. Each step forward is safer, but also slower to ship.

Rebuild approach. It has no such constraint. Designed for agentic AI from the start, with no compatibility to preserve and no legacy to accommodate, it reduces development time and cost. The gap between Cursor and GitHub Copilot illustrates this mechanism. Copilot had every structural advantage: first to market, backed by Microsoft, natively integrated into the GitHub ecosystem. Yet Cursor, a much smaller company, quickly became one of the most widely used coding assistants by shipping faster the features developers wanted: repository-level context, multi-file editing, natural-language commands.

This is the criterion where the balance tips most clearly toward the rebuild, and probably the main reason this option is often considered first. Yet this lack of friction has a downside over time: changes ship faster, but with fewer safeguards, which increases the risk of regression with every change. Maintaining an agentic architecture is faster, but less predictable.

4. Switching costs for the customer: a shield for the installed base, not for prospects

Progressive approach. It benefits from a lock on its installed base: a customer already equipped has invested time in training, configuration and integration with other tools. Switching solutions represents a real cost and risk for them, which mechanically protects the incumbent.

Rebuild approach. This lock plays no role with a new prospect. A customer who has not chosen anything yet is not comparing switching costs: they are comparing two offers on their respective merits. On this ground, the rebuild can prove faster or simpler to adopt.

The battle shifts. The established publisher defends its existing base almost by default, but has to win every new customer as if it had no acquired advantage. Conversely, a publisher that moves its own base to a rebuilt product takes the opposite risk: turning loyal customers into a temporary vulnerability for the duration of the migration.

5. Functional breadth or targeted depth: a question of where the attack comes from

Progressive approach. It tends to cover everything by accumulation: year after year, it has responded to customer requests until it covers a business domain almost entirely. This is a real asset with a customer who does not want to juggle several tools.

Rebuild approach. It does not try to rebuild that breadth all at once. It focuses its effort on specific workflows, often new and high-pain, and aims to be clearly better than the incumbent solution within that limited scope. The emergence of Rillet and Numeric in accounting illustrates this: recent players offering close and reporting workflows designed for automation from the ground up, in a scope that broader vendors cover without having optimized it to the same degree.

The question for an established publisher is therefore not whether it will face competition across the board, but on which specific function a specialized competitor can do clearly better. That is where the rebuild approach tries to gain a foothold first, and neither approach has a structural advantage: it all depends on the function under attack.

6. Anchoring in customer workflows: personalization, at the cost of reliability

Progressive approach. It has real operational anchoring: the customer opens it every day, their teams know it, its screens are part of the routine. But this anchoring remains generic: the same workflows apply to every user with the same profile, without adapting to each individual.

Rebuild approach. It aims for deeper anchoring, because it can adapt to each user rather than to a standard profile. This can take the form of a conversational agent that learns a specific person’s habits, workflows built from their exact configuration, or the ability to analyze an open-ended problem that no standard profile would have anticipated.

This advantage remains conditional on execution reliability. Open-ended reasoning explains both the strength of the agentic promise and the failure rates mentioned earlier: it handles cases no predefined workflow would have covered, but it is also the hardest capability to make reliable at scale.

7. Financial structure: two kinds of risk, no clear winner

Progressive approach. It relies on a mature P&L: recurring revenue, a paying customer base, and the ability to fund the transformation over several years. Investors often judge a SaaS publisher by the Rule of 40 (growth rate + profit margin ≥ 40%), a threshold that the high gross margin of conventional software helps reach.

Rebuild approach. When carried by a new entrant, it often relies on raised capital rather than established revenue. That capital brings its own pressure: proving fast traction to justify the next round, on a horizon of months rather than years. Add to that the cost of inference, which weighs directly on profitability: Bessemer Venture Partners puts the gross margin of AI products at around 50 to 60%, versus 80 to 90% for conventional SaaS. We analyzed this margin erosion and its effect on a publisher’s value in a dedicated article.

The most spectacular cases push the logic even further. In its State of AI 2025, Bessemer describes hypergrowth AI startups (Cursor among them) that reach an average of $40 million in annual recurring revenue in their first year of commercialization, but with an average gross margin of only 25%: they buy distribution at the expense of short-term profitability. A model that holds up with large funding rounds, much less so without them.

When an established publisher chooses the rebuild, it combines both logics: an existing P&L that absorbs part of the risk, but profitability that is harder to maintain if the new architecture remains heavy on inference costs. This criterion clearly favors neither approach: it changes the nature of the risk. Gradual loss of momentum on one side, a more abrupt funding cliff on the other.

8. Technical debt: a real advantage for the rebuild, but a temporary one

Progressive approach. It carries the weight of past decisions: sometimes old code, knowledge lost within teams, dependencies that are hard to evolve, architecture choices that made sense ten years ago but hold things back today. Every new feature adds to this base, at the cost of growing complexity.

Rebuild approach. It wipes out this debt in one go. It starts over on a lighter base, easier to evolve in the short term, without the compromises accumulated through partial rewrites and past commercial emergencies. This lightness is true at day zero. But a young agentic architecture accumulates debt too, and AI-assisted code contributes to it: a CodeRabbit analysis of 470 pull requests found on average 1.7 times more issues in AI-co-authored contributions than in human-only ones, notably in logic, readability and security. A figure to be qualified, since an AI-co-authored pull request often covers more code.

So the wiping out of technical debt is real, but temporary. The promised cleanup requires the same discipline as the legacy system, and the pressure to ship fast that characterizes agentic architectures makes that discipline even harder to maintain.

The eight criteria at a glance

Criterion	Advantage	Caveat
Proprietary data and customer history	Progressive approach	Raw data migrates well; business logic is what resists
Compliance and regulatory liability	Progressive approach	Only applies to workflows subject to a specific regulatory obligation
Delivery speed and development cost	Rebuild approach	Faster delivery, but maintenance more exposed to regressions
Switching costs for the customer	Progressive approach	Protects the installed base, no effect on new prospects
Functional breadth or targeted depth	Neither structurally	Depends on the specific function the competitor chooses to attack
Anchoring in customer workflows	Rebuild approach	Comes from per-user adaptation, conditional on reliability
Financial structure	Depends on circumstances	Two kinds of risk, no model clearly more profitable
Technical debt	Rebuild approach, short term	A young architecture re-accumulates debt, and fast

Rebuild or evolve: reversibility makes the difference

These eight criteria do not add up to a final score. A publisher can be strong on some and weak on others, at the same time. The useful question is not who wins in absolute terms, but on which ground the game that matters for its product, its customers and its industry is being played.

Three benchmarks are worth keeping in mind when making the call. Over 40% of agentic AI projects are expected to be canceled by the end of 2027, according to Gartner. The gross margin of an AI product hovers around 50 to 60%, versus 80 to 90% for conventional SaaS. And the fastest-growing AI startups fund their growth on an average gross margin of 25%, a model reserved for those that raise heavily.

A choice will have to be made, and the two options are not equal in reversibility. The progressive approach keeps a door open: it allows a later switch to a rebuild, workflow by workflow, as the technology matures. The rebuild approach closes that door as soon as it is under way. Once the legacy system is dismantled and the teams who mastered it have moved on, there is no credible way back if the bet does not deliver.

This asymmetry deserves as much weight in the decision as the eight criteria themselves. But the decision that matters most is ultimately not the publisher’s: it is the customer’s, who will decide criterion by criterion, often without an overall verdict, something neither approach can take for granted.