Most businesses ask this question too late — after they have spent two years bending a product to fit a process it was never designed for, and the workarounds have become the job.
There is a reasonable way to decide, and it has little to do with cost.
Off-the-shelf is right more often than founders think
If a product exists that does what you need, buying it is nearly always correct. You get years of accumulated edge cases, a support team, security patches, and a roadmap — none of which appear on the price tag but all of which you would otherwise fund yourself, permanently.
Building something you could have bought is one of the most expensive mistakes available to a business, and it rarely feels like a mistake while you are doing it.
Custom earns its cost in three situations
1. Your process is the product
If the way you do the work is your advantage, software that forces you into someone else's workflow removes the thing you compete on. Generic tooling makes you generic.
2. The integration burden exceeds the tool
When five systems must talk to each other and none were designed to, the connective work becomes the real project. At that point the "cheap" tools are not cheap — you are paying people to be middleware.
3. Per-seat pricing has outgrown the value
SaaS pricing scales with headcount; your need often does not. There is a crossover point where a fixed build costs less than a growing subscription. It arrives later than vendors imply and sooner than most businesses notice.
Four questions that usually settle it
- How many people work around the current tool daily? Re-keying data between systems is a cost with a real number attached. Calculate it.
- Would you change how you work to fit a product? If yes, buy. If the process is genuinely your edge, that answer is no.
- What happens if the vendor changes pricing or shuts down? If that is existential, you have a dependency problem regardless of which way you go.
- Can you describe the workflow precisely? If not, you are not ready to build. Custom software makes a well-understood process faster; it does not discover the process for you.
The middle path most people miss
It is rarely all or nothing. The strongest setups we see buy the commodity parts — accounting, email, payments, storage — and build only the piece that is genuinely theirs, connected to the rest by an API.
You end up owning the thing that makes you different and renting everything that does not. That is usually the correct shape.
If you do build
Build the smallest thing that removes the most painful manual step, put it in front of real users, and let what they actually do decide what comes next. The failure mode of custom software is not bad code. It is building twelve months of features nobody needed because nobody was using it yet.
