Custom software or SaaS: how to decide

The decision usually gets framed as a price problem, and it is not one. A subscription and a custom build do not buy the same thing: one buys access, the other buys ownership. Comparing their numbers without saying that first is comparing a lease with a deed.

Both are correct decisions in different contexts, and most companies need both at the same time for different things. What almost nobody gets right is the criterion for knowing which goes where.

This piece is about that criterion: what each model solves well, how the multi-year calculation is structured without inventing figures, what happens to your data when the vendor changes, and the case in which you should subscribe rather than build.

What each model solves well

Neither column is better. They are different risk profiles, and the question is which of the two risks suits you.

The five-year calculation, without invented figures

Almost every cost comparison you will read uses somebody else's numbers. Yours are the only ones that matter, so what is useful is the structure of the calculation rather than another company's answer.

For the subscription, add: the monthly fee times seats, times sixty months. Then add what almost nobody adds: initial implementation, migrating your data into the product, training, the modules billed separately, and an allowance for price increases. A mid single-digit annual rise is a conservative assumption, and over five years it compounds more than intuition suggests.

For the custom build, add: the project investment, hosting, annual maintenance and a budget for evolution. That total does not grow with your headcount, and that is the most important structural difference between the two models.

The result turns on one variable more than any other: how many people will be using it in five years. With a team that does not grow, the subscription usually wins comfortably. With a team that doubles, the crossover arrives sooner than expected, because one side scales with people and the other does not.

Run the calculation with your own numbers before asking for quotes. How the up-front investment in the second column is composed is in what custom software costs, and without that figure the exercise is only half done.

The cost that appears on no spreadsheet

There is a cost nobody invoices and it is often the largest of all: the friction between your process and the software.

It looks like this. Your team performs a step outside the system because the system does not account for it. Somebody keeps a parallel spreadsheet for what the product does not store. There is a field that says one thing and gets used for another, and everyone knows except the report. Every month, hours go into reconciling two versions of the truth.

None of that appears in the subscription. It appears in the salary of the people absorbing it, every month, forever.

The right question is not whether the product has the feature. It is how many steps of your operation fall outside it, and how much human time it costs to close that gap. If the answer is "none" or "almost none", the subscription is a bargain. If it is four steps and two people, you are already paying for custom software: just in salaries, and without owning anything at the end.

What happens to your data if the vendor changes

This is the risk that materialises rarely and hurts a great deal when it does. Three shapes:

The price goes up. The most common and the most manageable, unless migrating out is expensive, which is precisely what makes the increase work.

The roadmap changes. They discontinue the module you use, redesign the interface your team had mastered, or refocus on a segment that is not yours. There is nothing to appeal: their roadmap serves their majority, and if you are the exception, you are the exception.

They shut down, or get acquired. Infrequent, and there is no appeal when it happens.

In all three the practical question is the same: can you get your data out, in a usable format, without depending on the vendor's goodwill? Find out before signing, not after. A serious product documents its export; if you have to request it through support, you already have your answer.

With a custom build that risk does not vanish, it moves: it becomes the risk that your software vendor disappears. The difference is that there you can actually protect yourself, and the protection has a concrete name: the code and the infrastructure in your name, and documentation good enough for another team to pick it up. It is one of the questions worth asking before you hire anyone, and the most expensive one to discover late.

What the generic product does not cover here

There is a category of requirement where the decision simplifies itself, because the international product simply does not have it.

Electronic invoicing is the clearest example. A system operating in El Salvador has to issue Documentos Tributarios Electrónicos, and that is not a configuration checkbox: it shapes how a sale is modelled. We cover it in what integrating DTE actually takes.

WhatsApp as an operational channel is the second. Not as a contact button, but as the place where appointments actually get confirmed and orders actually get coordinated, wired into the system that holds the data.

The third is sector hardware: scales, scanners, fiscal printers, measuring equipment. Anything speaking a protocol a generic product has no reason to know.

If your operation depends on any of the three, the comparison is no longer between two models. It is between building and not building.

When the subscription is the right call

Better said here than on the call, and it is the part most people need to read.

If your team is small and will not grow much, your process is standard, and you have no local integrations, subscribe. You will have something working this week, for a fraction of the cost, maintained by people whose full-time job is maintaining it.

The same applies if your process is not settled yet. Building custom on a process you are still inventing freezes a decision you have not made into code. Use a generic product for a year, learn what genuinely does not fit, and only then build, knowing what for.

And the same applies if what you want to replace works. A system your team has mastered and that solves the problem is not technical debt: it is boring infrastructure, which is the best kind there is.

If you are somewhere in the middle and cannot tell which side you fall on, that distinction is exactly what a thirty minute call is good for.

How we decide it

We ask three questions before recommending a build. How many steps of your operation currently fall outside the software? How many people will be using it in five years? Is there a local requirement an international product will never cover?

Two high answers and one yes, and building pays for itself. All three low, and we say no and save you the project. What we build when the answer is yes is on custom systems.

The discovery call runs thirty minutes, it is free and carries no obligation, and it exists to run that exercise against your numbers. You can book it here.