What does redeveloping software mean in practice?
Redevelopment is not copying the existing system into a newer language. It means starting over from the operational processes as they are today, not as they were shaped to fit a package five years ago. With the Bonsai AI Digital Twin, we rebuild the ERP, TMS, WMS or MES from the ground up: data models, logic, interfaces, all of it. AI is built into the core, not added on top as a module after the fact. The client owns the code, the data, and the system. No licence dependency, no vendor lock-in. That is the fundamental difference from implementing a standard package or purchasing an AI module on top of an outdated foundation.
Three signals that redeveloping software is the right step
The first signal: the system has been extended so far with custom code and workarounds that no one dares to touch it anymore. Every change breaks something else. The second signal: operations are growing but the system is not keeping up. People work in Excel alongside the system, not inside it. The third signal: you want AI structurally embedded in decision-making, not as a chatbot on top of an outdated database, but as part of the daily flow. In all three situations, redevelopment delivers less technical debt over the long term, more control, and a system that reflects operations as they actually are.
Where does software redevelopment get stuck?
The biggest obstacle is scope. Organisations start with the idea of rebuilding the existing system one-to-one, only to discover halfway through that a small portion of the functionality accounts for the lion's share of the complexity. That complexity often exists not because it is operationally necessary, but because the system gradually shaped what operations needed to be. Redevelopment forces you to make those choices again. That is uncomfortable, but also useful: it removes dead logic. A second pitfall is migration. Moving data from old to new always costs more than expected, especially when data quality is low. Factor that in honestly.
When is software redevelopment not the right fit?
Redevelopment is not the solution when the existing system is actually working well but the processes around it are struggling. In that case, standalone AI Workers running on the existing system are a better first step: lower risk, faster results, and you are not laying a new foundation while the old one still holds. Equally, if the organisation is in the middle of a merger, acquisition, or another major change, this is not the right moment. And if the timeline is too short or the people who need to validate the system do not have the capacity: a project does not stall on the technology, it stalls on capacity at the operational side. That is not a weakness, but a reality that needs to be named honestly upfront.
What does a software redevelopment project look like?
We work with fixed milestones and go/no-go decisions. After each phase, the client decides whether to continue. The first phase maps operational reality: not the system documentation, but how the work actually gets done. That produces the specification. After that, we build iteratively, with operational users in the loop. The client owns what we build, including source code and data. That is fixed in our way of working, not as a marketing promise but as a contractual commitment. We build a Digital Twin in months, not years. But it will not go faster than the work requires.