The False Binary
Clients often come to us having already decided: "We want custom software." Or: "We want to buy a SaaS solution." Both starting points can be right. Both can be expensive mistakes.
The decision is not really build vs. buy. It's a question of where your organisation's competitive advantage lives — and whether your technology should reflect that advantage or commoditise it.
When SaaS Wins
Buy, don't build, when:
The problem is solved. HR management, accounting, CRM, email — these are solved problems. No amount of custom development will give you a meaningful advantage here. Use Sage, Salesforce, Google Workspace. Spend your engineering budget on problems that aren't solved.
Your requirements are standard. If your institution's procurement process follows the standard workflow that 90% of your peers follow, a procurement SaaS built for that workflow will be cheaper, faster, and better supported than a custom build.
Speed to market matters more than differentiation. If you need a working system in 8 weeks, custom software probably isn't the answer.
When Custom Wins
Build, don't buy, when:
The process is genuinely unique. The Nigerian customs clearance process is not the same as the UK's. A platform built for UK customs will require so much customisation that you'd have been better building from scratch. We've inherited three such projects.
Integration requirements are complex. If your system must integrate with five other systems that don't have APIs, and each integration is bespoke, a SaaS solution will hit its limits quickly.
Data sovereignty matters. For government institutions, financial institutions, and health organisations, where data lives is often legally constrained. Some SaaS solutions cannot accommodate this.
You are the product. If the software is the product your business sells — or a core differentiator in how you serve clients — you cannot afford to be constrained by another company's product roadmap.
The Third Option: Hybrid
Most mature engineering decisions end here. Use SaaS for solved problems (authentication, payments, email, analytics). Build custom for your core differentiators. Integrate them.
This approach requires good engineering judgment about where to draw the boundary — which is exactly what a senior engineering partner can provide.
A Practical Decision Matrix
| Factor | SaaS | Custom | |--------|------|--------| | Time to first value | Weeks | Months | | Ongoing cost | Subscription | Maintenance | | Customisation ceiling | Product roadmap | No ceiling | | Data control | Varies | Full | | Vendor dependency | High | Low | | Initial investment | Lower | Higher |
Conclusion
There is no universally right answer. The right answer is the one that matches your institution's requirements, timeline, budget, and strategic priorities. Any vendor who tells you otherwise — including us — is selling you something.
Our job is to help you make the right decision, even if that decision is not to hire us.
