What does rebuilding software mean in practice?
Rebuilding does not mean copying the existing system in a new language. It means starting over from the work processes as they actually are today, and building AI into the core rather than layering it on top afterwards. With a Digital Twin, we rebuild the ERP, TMS, WMS, or MES entirely. The data models, the logic, the interfaces, everything. The client becomes the owner of the code, the data, and the system. No licence dependency, no vendor lock-in. That is what sets it apart from implementing a standard package or purchasing an AI module on top of an existing foundation.
When is rebuilding software the right choice?
There are three recognisable situations. First: the system has been extended with so much custom development and workarounds that no one dares to touch it anymore. Every change breaks something else. Second: the operation is growing but the system is not keeping up, causing people to work in Excel alongside the system rather than inside it. Third: 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 these cases, rebuilding delivers less technical debt over the long term, more control, and a system that reflects the operation as it truly is.
Where do teams get stuck when rebuilding software?
The biggest stumbling block is scope. Organisations start with the idea that they will rebuild the existing system one-to-one, only to discover halfway through that twenty percent of the functionality accounts for ninety percent of the complexity. That complexity often exists not because it is operationally necessary, but because over the years the system adapted to shape what the operation needed to be. Rebuilding forces you to make those choices again. That is uncomfortable, but also valuable: it removes dead logic. A second pitfall is underestimating migration time. Moving data from an old system to a new one always takes longer than expected, especially when data quality is low.
When does a Digital Twin not fit?
Rebuilding is not the solution when the existing system works well enough but the processes around it are struggling. In that case, AI Workers, standalone automations running on top of the existing system, are a better choice. If the organisation is in the middle of another major change, such as a merger or acquisition, this is also not the right moment for an entirely new core system. And if the time horizon is too short: Bonsai builds a Digital Twin in months, not years, but it does require commitment from the operational side. If the people who need to validate the system do not have time for it, the project will stall. That is not a technical problem, it is an organisational one.
What does the process look like?
We work with fixed milestones and go/no-go decisions. After each phase, the client decides whether to continue. This protects both sides: the client does not invest blindly in a project heading in the wrong direction, and we do not build further on a foundation that does not hold. The first phase is always mapping operational reality, not the system documentation, but how the work is actually done. That produces the specification. We then build iteratively, with operational users in the loop. The client owns what we build, including the source code and the data. That is fixed in how we work.