We build custom software for a living, which should make you appropriately skeptical of our opinion on build-vs-buy. So here is the case for buying first.
If your process looks like everyone else's, a vendor has already spent a hundred engineer-years on the edge cases you haven't hit yet. Buy it. Configure it. Move on to something that differentiates you.
The signals that point the other way
- The workaround spreadsheet has quietly become the real system of record
- You're licensing forty modules and using three
- Every demo ends with the phrase "we could customize that for you"
- Your process is a competitive advantage and the platform flattens it
- Per-seat cost now exceeds what a build would amortize to over three years
The number people get wrong
Build-vs-buy comparisons usually stack a one-time build cost against an annual license, which flatters the build. The honest comparison includes ongoing hosting, model usage, and maintenance — call it 15–20% of the build cost per year for a well-scoped application.
It should also include the cost of the workarounds you're running today. That number is real and almost never on the spreadsheet: the coordinator whose whole job is reconciling two systems, the four hours a week of rekeying, the deals lost to slow turnaround.
Scope is the whole game
The failure mode of custom software isn't that it's custom. It's that it's unbounded. A micro-SaaS application that does one job across six screens will finish. A 'platform to run the business' will not.
We write down what we are deliberately not building before the first commit, and we revisit that list rather than quietly growing past it. Most of the value of a fixed scope is that it forces the conversation about what actually matters.