Buy software when the process is standard and the product fits it. Build internal software when the gap between the product and the way your business actually works has become a permanent manual job. That is the short answer. The difficult part is distinguishing a useful configuration gap from a structural mismatch.
The wrong comparison is licence cost versus build estimate. The real comparison includes implementation, integration, workarounds, change management, maintenance, switching cost and the operational cost that remains after the software is installed.
The comparison
| Dimension | Off-the-shelf SaaS | Internal software |
|---|---|---|
| Best fit | Common process with accepted industry conventions | Distinct process or a costly gap between existing systems |
| Time to first use | Usually faster if configuration is modest | Longer because discovery and delivery are yours |
| Up-front cost | Licence, setup, migration and integration | Discovery, design, build, launch and support |
| Ongoing cost | Subscription, usage, admin and vendor increases | Hosting, maintenance, support and improvement |
| Process flexibility | Inside the product’s model and roadmap | Designed around your rules and change priorities |
| Ownership | Vendor owns product and release decisions | You own code, data model and roadmap |
| Risk | Vendor fit, lock-in and workaround growth | Delivery quality, maintenance and key-person dependence |
Buy when the process is not your differentiator
Payroll, commodity ticketing, basic CRM and standard accounting are mature categories. Rebuilding them rarely creates operational advantage. A strong product gives you tested workflows, updates, security work and a user community for less than owning the equivalent system yourself.
Buying does not mean avoiding implementation. Data still has to move, roles still have to be designed and the team still has to change how it works. But if the product model matches the process, those costs buy a maintained capability rather than a custom codebase.
Build when the workaround has become the real application
The clearest signal is a spreadsheet or shared inbox that sits beside the purchased system and carries the fields, rules or handoffs the product cannot represent. If people export data, transform it, obtain approval elsewhere and then re-enter the result, the SaaS product is no longer running the process. Your workaround is.
Custom software is also justified when the workflow itself is a competitive capability: pricing a complex product, coordinating a distinctive service, operating a marketplace, or joining several systems in a way competitors cannot buy. The aim is not uniqueness for its own sake. It is removing a recurring operational constraint that standard products leave in place.
Integrate before you replace
Build versus buy is often a false binary. The best answer may be a small internal application on top of existing systems: one exception queue, one operational view, or one approval layer that reads and writes through supported APIs. The systems of record keep doing the commodity work while the custom layer handles the part specific to your operation.
Do not let sunk cost make the decision
A painful implementation does not make a poor fit valuable, and money already spent on custom software does not justify maintaining the wrong system forever. Compare the next three years from today. Include the people still bridging gaps, the changes the business expects, the cost of leaving and the risk of another migration. The decision is about future operating cost and capability, not defending the last project.
A decision process that survives the sales demo
- 1Map the process before evaluating products, including exceptions and rework.
- 2Separate must-have rules from preferences and habits.
- 3Test products against real awkward examples, not the clean demo path.
- 4Price the integrations and manual workarounds over three years.
- 5Estimate custom maintenance and identify who will operate the system.
- 6Choose the smallest owned layer that closes the material gap.
Buy the commodity. Build the gap that is expensive, persistent and specific to how your business works.
See how DevnTech turns business-critical workarounds into owned internal software.