An example of what a decision session delivers.
Rebuild or repair: how we decide.
What you read here is an example, written for the public. No client is involved. The shape — the question, what we read, the criteria, the written opinion — is that of a decision session, 600 CAD, answer within two business days.
The situation
A homegrown application is ten years old. It was written by a team that has since left. The vendor consulted about a rebuild says everything must be reconstructed: the technology is outdated, maintenance impossible. Leadership hesitates: two hundred thousand dollars, eighteen months, and the daily business that keeps running on the tool in the meantime.
It is the most frequent question behind the calls we receive: rebuild, or repair?
What we read
In a session, before the opinion, we read three things, in this order:
- The numbers. What the application costs today: hosting, maintenance hours, incidents, employee hours lost to workarounds. A rebuild is rarely justified on technology; it is justified, or not, on dollars per year.
- The code and the data. Not a line-by-line review: the real size, the dependencies, what is tested, what is documented, and above all what the data knows that the code does not say. An application whose business rules live in two people’s heads does not cost the same as an application that is written down.
- The contracts. Who owns what. Source code, hosting, licenses, exit clauses from the current vendor. A rebuild that starts without the complete sources starts from zero.
The criteria
The opinion answers four questions, in this order:
- Is the problem the software, or around the software? Half the rebuilds we see requested replace an organizational problem with a code problem.
- What does the current setup cost, per year, all in? The honest figure, workarounds included.
- What would the repaired system cost, and for how many years? Eighteen months of rebuild during which you still have to repair is paying twice.
- What happens to the risk? A rebuild moves the risk: from a known, limping system to an unknown system that promises. The risk of the construction site is paid in full before the first benefit.
The opinion, in writing
In the example, here is the opinion as it would come out — summarized here, complete in the document delivered:
Repair, and prepare the exit. The application does its job and its real annual cost, workarounds included, remains under half the projected cost of the rebuild. We recommend: (1) a repair plan prioritized on the three points that cost the most, figures attached; (2) recovery of the complete sources and the data under the company’s direct control within thirty days; (3) a freeze on any rebuild decision for twelve months, at the end of which the question is asked again with current figures, not impressions.
What we do not recommend: the rebuild now. It becomes justified if, within twelve months, the cost of the repaired system exceeds the annualized cost of the reconstruction — the condition is written down; checking it is enough.
One page, the reasons behind it, and a board that knows what it approved.
What we need to deliver yours
A ninety-minute session with the right people at the table, read access to what is true: the numbers, the code, the contracts. Two business days after the session, the opinion arrives in writing. If it cannot be defended in front of your board, it is not delivered.