Building software is no longer the hard part. Deciding what is worth building, what should be bought, what should be automated and what should be left exactly as it is — that is where projects are won or lost. These are the positions we actually hold, written down.
When not to build custom software
Most software a business runs on should be bought, not built. Four situations where our answer is “don’t” — an unsettled process, an off-the-shelf tool that already covers most of it, no internal owner, and a problem that turns out to be the workflow rather than the software.
Automating a bad workflow makes it worse
Automation is a multiplier, not a fix. Errors scale before anyone notices, exceptions get forced down the happy path, and the workaround somebody invented years ago becomes permanent infrastructure. The three questions worth answering before you automate anything.
Replacing a legacy system without stopping the business
The rewrite that fails is the one that ships all at once. How to find the undocumented behaviour a long-lived system depends on, strangle it capability by capability instead of replacing it, and treat the data migration as the project rather than the last task.
Where this leads
Every one of these ends in the same place: a written, costed answer about what to do, produced before anyone commits to a build. That is the readiness audit — fixed fee, two weeks, credited in full against a build if you proceed.