Total Cost of Ownership (TCO).

A complete TCO calculation carries four blocks. Implementation: selection, licences or development, data migration, training, parallel operation. Operation: subscriptions, hosting, backup, monitoring, support. Further development: adaptations to new requirements, interfaces, legal changes, updating dependencies. Exit: data export, migration, dual running during the changeover, and a tail for archiving and retention obligations. The fourth block is missing from almost every comparison, although it often decides whether a solution is still changeable years later. Carrying it from the start changes how you negotiate contracts and how early you test exports.

The biggest source of error is internal hours. Comparing only third-party invoices makes in-house development systematically too cheap and buying too expensive — or the reverse, depending on where the internal effort falls. What has to be captured is time for selection, testing, data maintenance, training, internal contacts and troubleshooting. Outage risks and dependence on individual knowledge holders belong there too. These items can be estimated but not ignored; a written estimate is better than a silent zero.

An example of how such a calculation is structured: a business compares an off-the-shelf solution with in-house development over five years. On the buy side it enters licences for the actual number of users, implementation, training and a later migration. On the build side, the development — with us a prototype or MVP for validation starts at CHF 10,000, and a production system sits above that — plus hosting, maintenance, security updates and further development for each year. Only this comparison, with the same term and the same user count, allows a statement.

For the calculation to convince, it needs three properties. First, identical boundary conditions on both sides: same term, same user numbers, same functional scope. Second, visible assumptions, so that they can be discussed instead of the result. Third, a sensitivity view: what happens at twice the user count, at a vendor price increase, at a service provider failing? A decision frequently tips not on the average case but on one of these scenarios — and that is where the real value of the calculation lies.