Brain Matrix Labs — Decision tool
The most expensive question in software, answered with a structure rather than a sales pitch. Seven questions, a recommendation, the reasoning behind it, and the strongest argument against it.
Seven questions
0 of 7 answered
0%
Question 01
Question 02
Question 03
Question 04
Question 05
Question 06
Question 07
Recommendation
Awaiting input
Answer all 7 questions to see a recommendation, the reasoning behind it, and the strongest argument against it.
The underlying logic
The other four matter, but these three decide most cases.
If a process is genuinely where you beat competitors, encoding it in software every competitor can also buy is a strange decision. If it is back-office administration, building it is an expensive way to arrive somewhere you can already reach.
Packaged products are excellent at their own domain and poor at the seams between domains. Once six or more systems have to agree, the work is systems engineering regardless of what sits in the middle — and that is the point where building often becomes the cheaper option.
Building is not a project, it is a commitment. Without funded maintenance, a custom system degrades into a liability in about two years. This single question flips more recommendations than any other.
Questions
Roughly half the possible outcomes of this tool recommend buying rather than building, and the recommendation always states the strongest argument against itself. We would rather lose a project than take one that should not exist — mostly because the ones that should not exist go badly, and badly is what people remember.
Because licence cost versus build cost depends entirely on your scale, your vendor terms and your integration surface. A number generated from seven multiple-choice answers would be invented, and invented numbers are how build decisions go wrong. What we do include is whether you can fund ongoing ownership, which is the cost most build decisions ignore.
Keeping your systems of record where they are and building only the orchestration, workflow and interface on top. You do not migrate data you do not have to. It works well when the layer stays genuinely thin, and it degrades badly when it slowly becomes the system — which is why we suggest reviewing that decision after a year.
As a planning figure, budget 15 to 25 per cent of the original build cost per year for maintenance, hosting, dependency updates, support and small changes. Systems that are not funded at roughly that level tend to become the legacy problem someone is hired to fix a few years later.
Yes, and that is a good use of it. If a vendor is proposing a custom build, the seven questions here are a reasonable structure for asking why — particularly the ones about differentiation and integration surface.
Related
Next step
Bring the recommendation and the case against it. Forty-five minutes with someone who has built both, and who has no incentive to talk you into the more expensive one.