SaaS vs Custom Platform: How to Decide

The default recommendation in most software circles is "use SaaS until you can't." It's sensible advice — building is slower and more expensive than buying, and most problems don't require custom solutions. But "until you can't" does a lot of work in that sentence, and it's rarely examined carefully.

SaaS has real limits. Custom software has real costs. The decision between them isn't a values question about whether you prefer to build or buy — it's a practical question about what your situation actually requires. Getting it wrong in either direction is expensive, just in different ways and on different timelines.

What SaaS Is Actually Good At

SaaS solves solved problems well. Email, accounting, CRM, project management, HR — these are domains where the core requirements are mostly consistent across businesses and where a well-funded vendor has spent years building what you'd spend years building yourself. Using SaaS here isn't a compromise. It's the correct decision.

SaaS is also good at things that change fast. Security patching, compliance updates, feature development — you get the benefit of continuous investment without carrying the cost. A small team trying to maintain a custom payments system in a changing regulatory environment is doing work they probably shouldn't be doing.

And SaaS has near-zero startup time. A new Salesforce instance is live in hours. A custom CRM is live in months. If you need to move quickly, that delta matters.

Where SaaS Breaks Down

SaaS breaks down when your business process is the product. If the way you do something is what differentiates you — if the workflow, the data model, the user experience of an internal tool is what your operations depend on — then you're trying to fit your differentiation into software designed for the average of your industry. That average rarely fits anyone perfectly, and fitting it often means changing how you work to match the tool rather than the other way around.

It also breaks down at scale in ways that aren't visible early. SaaS pricing is usually per seat or per transaction. At low volume those costs look manageable. At high volume, especially if your usage pattern doesn't match the vendor's pricing model, the economics shift. Businesses that chose SaaS when they were small and didn't revisit that decision as they grew sometimes find they're spending more on licences than a custom solution would have cost to build and operate.

Integration is the third failure mode. Most modern businesses run a dozen SaaS tools. Some integrate cleanly; many don't. When your operations depend on data flowing reliably between systems that weren't designed to talk to each other, you eventually end up building the integration layer yourself anyway — which is a kind of custom software development, done reactively, without the architecture thinking it deserves.

The Questions That Actually Determine the Answer

Rather than a checklist, there are three questions that tend to separate "buy" from "build" clearly enough to act on.

Is this process generic or specific? If other businesses in your industry run the same process the same way, SaaS almost certainly exists that handles it well. If your process reflects decisions you've made deliberately about how to compete — your pricing model, your service delivery, your data collection — it may not fit any SaaS well enough to matter.

Who controls the roadmap? With SaaS, the vendor controls what gets built next. If the platform's direction aligns with yours, that's fine. If it diverges — if the vendor's priorities don't match your needs, or the vendor gets acquired, or pricing changes — you're either stuck or migrating. Custom software's roadmap is yours. The trade-off is that you're also responsible for it, which has its own costs.

What's the three-year total cost? Build costs are visible. SaaS costs compound invisibly. A R5,000/month SaaS subscription is R180,000 over three years — and that's before it scales with usage. A custom solution costs more upfront and less per month. The crossover point varies by situation, but it's worth calculating rather than assuming SaaS is cheaper because it feels cheaper at month one.

The Middle Ground That Often Gets Ignored

The SaaS vs custom framing misses a category that's frequently the right answer: SaaS for the generic parts, custom for the specific parts.

Use Xero for accounting. Don't build accounting software. But if your operations require a custom workflow that Xero doesn't support, build that workflow and integrate it with Xero via the API. You get the vendor's investment in the solved problem and control over the part that's actually specific to you.

This requires decent API integration work and someone who understands both your business process and the SaaS platform's data model. It's not trivial. But it's often cheaper and faster than a full custom build, and more fit-for-purpose than trying to make a SaaS tool do something it wasn't designed for through configuration and workarounds.

The question is rarely "SaaS or custom?" The question is "which parts of this problem are solved problems, and which parts are ours to solve?"

When You've Outgrown SaaS

The businesses that come to us after outgrowing SaaS tend to share a pattern. The platform did the job for two or three years. Then it started constraining them — features they needed weren't on the roadmap, the pricing became hard to justify, integrations were held together with Zapier and prayer. They spent a year working around the constraints before deciding to build.

That year of workarounds is worth examining. It usually represents a large amount of engineering time and operational complexity that didn't go into the original SaaS vs custom calculation. If the workarounds had been tracked honestly, the decision to build might have come a year earlier — at a point where the migration would have been cheaper and the technical debt from the workaround period wouldn't have needed to be cleaned up simultaneously.

The lesson isn't "build earlier." It's "revisit the decision regularly." What was the right call at year one may not still be the right call at year three. The businesses that handle this well treat SaaS choices as decisions to be reviewed, not defaults to be maintained indefinitely.

Armin Marxer writes at zeroclue.dev.