Build or buy? A guide to internal software
Compare workflow fit, three-year cost and ownership before choosing a SaaS product, a custom tool or a hybrid approach.
The wrong internal tool can make a simple process depend on exports, duplicate entry and a person who knows which spreadsheet is current. But replacing every awkward subscription with custom software is not a strategy either. A build creates an operating responsibility, not just a better interface.
Choose between buying, configuring, building and combining tools around the work your team needs to complete. Compare the same scope, service expectations and time horizon. This guide uses illustrative examples and assumptions, not company results or quoted market prices.
Start with the workflow, not the feature list
Write down a few real journeys: who starts the work, what information is required, who approves it, and where the result must go. Separate non-negotiable requirements from preferences. Role-based access, a required approval sequence or a reliable accounting integration may be essential; a particular dashboard arrangement probably is not.
Ask vendors to demonstrate your scenarios with representative, non-sensitive data. Test exceptions as well as the happy path. For an illustrative purchase-request process, a form is easy to demonstrate. The harder questions are what happens when an approver is absent, a request changes after approval, or an integration fails halfway through posting it.
Calculate the cost of adapting the process too. Sometimes adopting a standard workflow is beneficial. Sometimes it removes a necessary control or forces staff into recurring manual workarounds. A hybrid can be sensible: buy the commodity system of record and build a narrow workflow layer around its supported APIs.
Compare three-year total cost
Use a common horizon rather than comparing a monthly subscription with an entire build quote. Include implementation, migration, configuration, training and integration for both options. For custom software, include design, engineering and testing; for a purchase, include any required service tier or paid add-ons. Do not assume the first implementation is the last change.
Three-year TCO = upfront delivery and transition + sum of annual licences, infrastructure, support, maintenance, administration and change costs for years 1-3 + expected exit or replacement cost + risk allowance. Keep the risk allowance separate from costs already counted so it is not double-counted.
- Model expected users, usage, storage and renewal assumptions, not only today's smallest plan.
- Price staff time for administration, upgrades, manual workarounds and incident response.
- Include data export, migration and decommissioning in the exit scenario.
Make the assumptions visible
Suppose, purely illustratively, a SaaS option needs 10,000 currency units upfront, 18,000 per year for subscriptions and administration, and 6,000 to exit. Its undiscounted three-year estimate is 70,000 before a separate risk allowance. A build at 40,000 upfront, 8,000 per year to operate and maintain, and 6,000 to exit also totals 70,000. Equal totals do not mean equal risk, capability or delivery time.
Run low, expected and high scenarios for user growth, integration effort and maintenance. Document who supplied each estimate and what it excludes. If delayed delivery carries a cost, include it for both options. Keep projected business benefits separate from TCO, then compare them using the same quality and adoption assumptions. For material spending, finance may also require discounted cash-flow analysis.
Decide who will own the system
Buying transfers some implementation work, not your responsibility for access, data quality and continuity. Check authentication, role permissions, audit logs, backup and restore arrangements, data location, retention, contractual terms and export formats. Verify API limits and whether critical capabilities require a different plan. Ask how incidents, outages and product changes are communicated.
A build needs named product and technical owners, a maintenance budget, monitoring, tested recovery and dependency updates. Agree on source-code ownership, deployment access, documentation and handover before delivery. A tool only one developer can safely change is a continuity risk, even if your organisation legally owns the code.
For a hybrid, make the boundary explicit: which system is authoritative, how changes synchronise, and how failed or duplicate operations are reconciled. Evaluate security against the sensitivity of the data and the consequences of failure. Neither 'custom' nor 'established vendor' is proof that those requirements are met.
Use a small decision matrix
First apply hard gates: an option that cannot meet mandatory security, regulatory or workflow requirements should not win through a high average score. Then agree weights for fit, cost, delivery time and operating burden. Score against demonstrated evidence, record uncertainties, and test whether changing the weights changes the decision. The directional matrix below is a starting point, not a verdict.
| Decision factor | Buy / configure | Build | Hybrid |
|---|---|---|---|
| Standard workflow | Test built-in fit | Justify extra ownership | Check if a layer is needed |
| Distinctive workflow | Prove configuration limits | Validate custom scope | Test API boundaries |
| Operating capacity | Own vendor and access admin | Own delivery and maintenance | Own both and integration |
| Exit flexibility | Verify usable exports | Verify handover and portability | Verify both sides |
Roll out in stages, with a way back
Start with a limited team and a complete but narrow workflow. Define acceptance checks for permissions, migrated data, exception handling and recovery. Train the owner and users before expanding. If you run systems in parallel, name the authoritative record and reconcile differences; otherwise the pilot itself creates conflicting data.
Review adoption, completion time, correction effort and support demand against the baseline. Set a rollback trigger and preserve the data needed to resume the old process. Expand only after the workflow and ownership model work in practice. Retire old tools deliberately once records are reconciled, retention duties are met and the team no longer depends on hidden workarounds.