The instinct to build is often wrong, and a vendor who always recommends building should make you suspicious. Here is the actual decision.
Buy when your process is normal#
If your process looks like most businesses in your sector, someone has already built software for it, tested it against thousands of users, and priced it lower than you could build it.
You should almost certainly buy when:
- The workflow is standard: accounting, payroll, email, CRM basics, helpdesk
- The compliance burden is high and changes often — someone else maintaining that is worth paying for
- You need it working next week
- The problem is not a competitive advantage for you
Build when the product would force you to change how you work#
Off-the-shelf software makes you change your process to fit the product. Sometimes that is fine — your process was arbitrary anyway. Sometimes the process is the business.
Build when:
- Your senior staff do something from memory that no SaaS tool has a field for
- The exceptions are the norm, not the edge case
- You are paying for five tools and still copying data between them by hand
- The workflow is how you compete, not just how you administrate
- Per-seat pricing has become more expensive than owning the thing
The middle path most people miss#
You do not have to choose one. The most common sensible answer is: buy the commodity, build the part that is actually yours, and connect them.
Keep your accounting package. Keep your email. Build the operational system that is specific to your business, and integrate it with the rest through APIs.
This is usually cheaper than either extreme, because you are not rebuilding solved problems and not contorting your core operation to fit a template.
Questions that settle it quickly#
"How many spreadsheets sit alongside the software we already pay for?" Each one is a gap between the product and your process. A few is normal. Many means the fit is poor.
"How much of our staff time goes into moving data between systems?" If it is hours per week, that is an automation problem, and it may not need a new system at all.
"If we changed our process to match the product, what would break?" If the answer is "nothing much", buy. If it is "the reason customers use us", build.
"What does this cost in three years?" Compare SaaS subscriptions over 36 months against a build plus its monthly running cost. Sometimes buying wins clearly. Sometimes it is closer than expected.
Our bias, stated plainly#
We build custom software, so we have an obvious incentive to recommend building. We try to correct for it by saying so directly: if a product fits your process, buy the product. We would rather tell you that on the first call than deliver something you did not need.
If you want that assessment for your situation, describe what the business does today.