The default answer is SaaS
Let's start with the honest version: for most business functions, buying SaaS is the right decision. Accounting, HR, email, project management — the generic versions of these problems are well-solved by generic software. You don't need custom accounting software. QuickBooks exists. It's fine.
This post is about the cases where generic software isn't fine — and how to identify them before you've spent six months adapting your process to fit a product that was never designed for it.
The three signals that custom is the right call
1. The process is a competitive differentiator. If how you do something is why customers choose you, wrapping it in a generic SaaS product erodes that advantage over time. The SaaS vendor shapes the product for the average customer. You are not average. We built a custom dispatch platform for a logistics client because their routing intelligence was their competitive edge — the way they matched drivers to jobs was genuinely better than competitors. A generic logistics SaaS would have commoditised that.
2. Compliance requires something the SaaS doesn't do. Our ZATCA e-invoicing work is a clean example. Saudi Arabia's Phase 2 e-invoicing requirements (cryptographic signing, real-time clearance via the Fatoora portal, UBL 2.1 XML) are specific enough that most off-the-shelf accounting platforms either don't support them or support them through a bolt-on integration that becomes the most fragile part of the stack. We built a custom layer that sits between the client's existing ERP and the ZATCA portal. The result: 100% compliance from day one, 60% lower cost than the SaaS alternative, no dependency on a vendor that might pivot.
3. The per-unit economics of SaaS don't work at your volume. This is more common than it looks. A UK retail client was paying Shopify and its apps $3,200/month. We built a custom e-commerce platform for £22,000. At their volume, it paid for itself in eight months. After that, the economics are completely different. Custom software doesn't have per-transaction fees.
The honest cost of building custom
Custom software costs more upfront. It requires ongoing maintenance. If your team or your developer relationship changes, you own a codebase that needs support. These are real costs.
The framework we use with clients:
- Year 1: Custom almost always costs more than SaaS. If you're comparing year-one costs, SaaS wins.
- Year 3: Depending on volume and what the SaaS costs per seat/transaction, custom often pays for itself.
- Year 5+: If the software is doing its job, the custom version is cheaper and better-suited to how you work. The SaaS version has had three rebrandings, two pricing restructures, and removed the feature you depended on.
The questions to ask before you build
1. Will this process look meaningfully different in three years? If yes, you probably want the flexibility of custom. If no, SaaS is fine.
2. Is the per-seat or per-transaction cost of the SaaS predictable at your scale? Run the three-year number.
3. Do you have the in-house technical capability to own a codebase, or will you always be dependent on the original developer? If the latter, the ongoing support arrangement needs to be clear before you start.
4. Is the process you're building for genuinely bespoke, or do you just think it is? Be honest here — most processes are less unique than they feel from the inside.
If the answers point to custom, we're happy to scope it. If they don't, we'll tell you that too.