Business automation versus a custom SaaS: which one do you need?

The most expensive mistake in a software project is building an application when the business needed an integration. It is common, it is understandable, and it is almost always more expensive than the alternative.

Here is the difference, stated as plainly as I can.

A custom SaaS is for a capability you sell

You build an application when the thing you are building is a product in its own right. People log in, they do something, and the value is in doing that thing.

The test: does this become something you could put a price on? If yes, it is probably a product, and it needs the full treatment — auth, billing, an admin, onboarding, observability, a support story. Underestimate any of those and you have a project that is 40% finished after spending all the money.

An integration is for data that must move

You build an integration when the problem is that information exists in one system and needs to exist in another, and a person is in the middle moving it.

The test: strip away the interface, the branding and the user accounts. Is there still a problem? If what remains is “these two systems do not talk to each other and somebody is copying rows between them”, then you do not need a SaaS product. You need a service that moves data, logs what it did, and tells someone when it failed.

This is a much smaller piece of software. It is also, frequently, worth far more to the business, because it removes a cost that recurs every day forever while the application is a bet on a new revenue stream.

Why people get this wrong

Both options get described as “automating” in a way that blurs the distinction, and both start with the same sentence: we need a system.

The pull toward building an application is understandable. A product is exciting, it can be sold, it is visible, it feels like progress. An integration is plumbing. Nobody puts an integration on a slide.

But a business that has chosen between them correctly usually wanted the integration. They already have the system they sell. They wanted to stop paying someone to do a task, and what they got was a bill for a minimum viable product that now needs a support team.

The reverse mistake is equally expensive: automating something that should have been deleted or redesigned. If a process exists because of a decision made in 2019, no amount of automation makes it a good process — it just makes the bad process run faster and cheaper to run, which is not the goal.

What to ask before building anything

Who is the user? If the answer is two people inside your company, you do not need a user interface. You need a script and a log.

Is this a new capability or an existing capability that is slow? New capability is product work. Existing-but-slow is usually integration work.

What happens if this fails at 3am? If the answer involves a person noticing, the design is wrong. A silent failure in a billing path is worse than no automation at all.

What will this need in six months? Not the features — the operational things. Retries, alerts, an audit trail, a way to correct a mistake. If you cannot answer, the project is not scoped yet, and scoping is not optional.

Who operates it after you finish? An integration that nobody on the ground can see and correct will be abandoned quietly within a quarter. Build the view for the person who does the work.

How I usually scope this

Building a custom SaaS from scratch for your company is rarely the right first move.

Unless the process is highly specific to your business and the economics justify owning the software, you are usually better off integrating an existing SaaS or using a good open-source alternative.

The gaps between those systems are where things get interesting.

That is where automation usually delivers the highest ROI: connecting the tools you already use, removing repetitive work, and eliminating the manual steps that fall between them.

Start with the biggest bottleneck in the process. Fix it. Measure the result. Then move to the next one.

You do not need to automate the entire business.

You need to systematically remove the parts that are costing you the most time and money.

If you are deciding between these, tell me what the process does today and what it costs you. You will get a straight answer, and the first conversation is free. If it turns out you need an integration and not an application, that is the useful thing to learn in the first call rather than the third invoice.