SaaS vs custom software: how to decide which one you actually need

For fifteen years the default answer was "buy a SaaS." For a great many things it still is: email, standard accounting, e-signature, a by-the-book CRM. Nobody should be building their own mail client.

But when software touches the core of your operation — how you produce, how you quote, how you deliver — the question changes. And the automatic answer starts getting expensive in a way that appears on no invoice.

What SaaS does well

Worth starting here, because the point isn't that SaaS is bad:

• Fast start. You're operating in days, with no project and no engineering team.
• Low, predictable entry cost. A subscription instead of an investment.
• Somebody else's maintenance. Updates, security and infrastructure are the vendor's problem.
• Cheap to test. If it doesn't fit, you leave next month.

All of that is real and it's a lot. SaaS wins when your process looks like everyone else's, because the product is designed for exactly the average of its thousands of customers.

The invisible cost

The trouble starts when your process doesn't look like everyone else's. An unbilled tab starts running:

The parallel spreadsheets. This is the most reliable symptom. If your team exports data from the system into Excel to do the actual work and then keys the result back in, they aren't using that software — they're routing around it. Count the hours a week that detour costs and multiply by a loaded hourly rate. That number is already a budget.

The features you pay for and never open. Less serious than it looks in dollars, more serious than it looks in adoption: every extra feature is a more confusing screen, a longer training session, and one more reason to go back to the spreadsheet.

The deformed process. The most expensive and the hardest to see. When the tool doesn't account for a step, the step doesn't disappear — it happens outside the system, unrecorded, in somebody's head. A year later nobody knows why the system's number doesn't match reality, and the answer is that reality contains a step the system never knew existed.

Somebody else's roadmap. The thing you need has been "under evaluation" for two years because only you and fourteen other customers asked for it. Nobody is lying to you: you simply aren't the average, and the product is built for the average.

The exit. The day you want to leave, your data is theirs in their format. The question isn't whether you can export — it's what it costs to rebuild fourteen years of history somewhere else.

When custom wins

Building is the right call when more than one of these is true:

1. The way you work is your advantage. If what makes you better than a competitor is how you do something, a generic product flattens it to the market average. A custom one amplifies it.
2. The process is repetitive and expensive. People copying data between systems is the easiest case to justify: the return is measured in hours and shows up in month one.
3. You need what you already own to talk to itself. ERP, spreadsheets, e-commerce, third-party APIs. The value isn't a new screen — it's the data moving without being typed twice.
4. The result has to be yours. Not access that can be repriced or discontinued: an asset on your books, with the code in your hands.

The middle ground, which is what we usually recommend

It isn't all or nothing, and anyone framing it that way is selling something.

The healthy version is a map: SaaS for the commodity, custom only where your edge lives. Accounting, payroll, email, signatures: bought. The process that makes you different: built, and integrated with the bought things so data moves on its own.

We work this way ourselves. Our CRM is custom because no product modelled our funnel — a lead doesn't become a sale, it becomes a diagnosis, and from there a staged project. But our accounting runs on a product we bought like everybody else, because invoicing is not our competitive advantage.

How to decide, in three questions

• Is this process part of what makes me competitive? If yes → custom.
• Am I paying for features I don't use, or filling spreadsheets to patch gaps? If yes → custom, starting with the gap.
• Is this a standard thing half the world does identically? If yes → SaaS, and don't overthink it.

What changed in 2026

Five years ago this decision had a clear economic answer: building was slow and expensive, so you bent yourself around the product even when it hurt.

With AI inside the development process, that arithmetic flipped for a large band of cases. A system that was six months and a team in 2022 ships in six weeks today. That doesn't make "build" the right answer every time — but it does make it a real option for companies that weren't even evaluating it three years ago.

If you'd like, we can look at your specific operation. A short diagnosis usually makes it obvious what to buy, what to build, and what to leave exactly as it is.