A practical framework for deciding when to buy SaaS, when to build custom, and when to stitch them together — written for non-technical buyers.

Every other new-client conversation we have starts with the same question, phrased slightly differently each time:

> "Should we just use an existing tool, or should we build something of our own?"

It is a better question than most of the internet gives it credit for. The answer is almost never a clean yes or no. In practice, the right answer for an SME is usually a specific hybrid of the two, shaped by a few very concrete factors.

This post is the framework we walk clients through before we quote a single hour. You can use it yourself, with or without us.

The three real options

Most people think of this as a binary choice — buy vs build. In reality there are three:

• SaaS-only: you adopt an existing product (HubSpot, Shopify, QuickBooks, Intercom, etc.) and live inside its rules.
• Custom-only: you build your own system from scratch, tailored to exactly how you work today.
• Hybrid: you use SaaS for the commodity parts and write custom software only for the parts that are genuinely yours, stitching them together with integrations and a thin layer of your own code.

Most successful SME deployments we have seen over the last decade are hybrid. Very few are custom-only. A fair number start as SaaS-only and grow into hybrid as the business matures.

The five factors that actually decide

When a client asks us to help them choose, we walk through five questions — in this exact order, because the earlier ones often make the later ones irrelevant.

1. How standard is the process you are trying to support?

Some business processes are so common that somebody has already spent a hundred million dollars solving them — payroll, email marketing, e-commerce checkout, helpdesk ticketing, accounting.

If your process looks like 90% of other businesses' processes, buying SaaS is almost always correct. Your competitive edge is not in that workflow; it is in what you do around it.

If your process is genuinely unusual — a booking model nobody else has, a manufacturing flow shaped by a specific regulation, a service catalogue that no off-the-shelf tool can represent without contortion — custom is suddenly on the table.

The test we give clients: *"If I described your process on a whiteboard to five other businesses in your industry, how many would recognise it?"* Five-of-five means SaaS. Zero-of-five means custom is worth considering. Anything in between is hybrid territory.

2. How often will the process change?

SaaS is fantastic for processes you want to keep stable. The vendor does the upgrades, the security patches, the compliance work. You focus on running the business.

Custom software is superior when the process itself is a moving target — because you are actively experimenting, because the regulatory environment is evolving, because you are trying to find product-market fit.

• If your process changes monthly or faster, custom is usually justified. SaaS will constantly feel like wrestling with someone else's defaults.
• If your process changes yearly or slower, SaaS is usually correct. You do not need to own it. You need it to work.

3. How tightly must it integrate with everything else you run?

A standalone tool that is 95% great is still a standalone tool. If your billing, inventory, shipping, and customer support have to talk to each other in real time, integration quality is everything.

Modern SaaS products are much better at integrating than they were five years ago. But they integrate on the vendor's terms, through the vendor's API, in the vendor's release schedule. When those terms match what you need, you get a beautiful hybrid. When they do not, you get a thin adapter layer that becomes the most fragile part of the system.

We ask clients to draw, on a single sheet of paper, the systems they already run and the three or four data flows between them that matter most. If those flows are covered by existing integrations in the SaaS we are considering, excellent. If they are not, we either pick a different SaaS or we price a custom integration layer.

4. How sensitive is the data and who owns it?

Some data is easy: marketing emails, session analytics, blog comments. Losing the vendor's integration here is annoying but not dangerous.

Some data is not: patient records, financial transactions, regulated manufacturing data, trade secrets. Here, "where does this data live" and "who has legal access" are existential questions.

Our rule of thumb:

• Public or non-sensitive data — SaaS is fine, pick the best tool.
• Private but non-regulated data — SaaS is fine if the vendor has solid security practices, signed DPAs, and sane export tooling.
• Regulated data (health, finance, certain government contracts) — SaaS is possible, but your choice of vendor is now a compliance decision, not just a product decision. Custom is a serious option when no SaaS meets your regulator.

5. What is the total cost over five years, not five months?

SaaS looks cheap at the start because the monthly fee is small. Custom looks expensive because the first cheque is big. The curves cross, and the crossing point matters.

A rough five-year framing we use with clients:

• SaaS: subscription × users × 60 months. Easy to underestimate because growth is nonlinear.
• Custom: build cost + 15–25% annual maintenance × 5. Easy to underestimate because change is not included.
• Hybrid: the smaller of the two for each category, plus integration cost.

Run all three. The answer is often that a well-chosen hybrid is 30–50% cheaper over five years than either pure path, because you stop paying SaaS seat fees where the tool does not actually fit, and you stop custom-building what is already a solved problem.

A worked mini-example

Imagine an SME running a small logistics business with 40 drivers, 2,000 deliveries per week, and a few key corporate clients who expect branded tracking.

• Accounting: SaaS. 95% standard, rarely changes, low integration needs.
• Helpdesk for corporate clients: SaaS. Mature market, solid integrations.
• Driver dispatch, route optimisation, and live tracking: custom, because this is the process they compete on.
• Branded tracking page for clients: custom front-end, pulling from the dispatch system.
• Email + chat for internal comms: SaaS, always.

The hybrid looks like a custom app that owns dispatch and tracking, integrated tightly with SaaS accounting and helpdesk. The competitive software is custom. The commodity software is bought. The lines between them are explicit and maintained.

We have shipped roughly this shape for logistics, clinics, hotels, and niche e-commerce operators. The specifics change; the framework does not.

The honest bottom line

If someone tells you "custom is always better" or "SaaS is always cheaper," they are selling you something.

Custom is better when your process is unusual, fast-changing, tightly integrated, or data-sensitive. SaaS is better when your process is standard, stable, loosely integrated, or when the cost of reinventing it is obviously silly. Most real SME businesses have both kinds of process, and the winning shape is a hybrid — you just have to be honest about which is which.

If you want a second pair of eyes on where the line should fall for your business, we are happy to run the framework above against your specific situation, free of charge. We are not shy about telling a client that SaaS is the right answer and we are the wrong vendor.

Original Source: SaaS vs custom vs hybrid: the decision framework we actually use