Custom-built software beats a subscription in a set of precise cases — but not in all of them, and I spend part of my diagnostics saying exactly that. Keeping a SaaS stays the right call when the tool benefits from a real network effect, when the compliance burden usefully sits with the vendor, when the functional depth exceeds what a small team can carry, or when the need is still too fluid to be cast in code. Knowing when to change nothing is part of advice, not the absence of it.
Why an article about changing nothing?
Because the prevailing discourse pushes in a single direction. Since augmented development brought down the cost of custom software, the temptation is to want to own everything, as if the subscription had become a bad calculation by nature. That shortcut is expensive. Rebuilding a tool the market already delivers better, cheaper and without maintenance debt shifts a visible expense — the subscription — toward an invisible and lasting one: maintenance time, fixes, regulatory monitoring, the rebuild once the need shifts.
My job is to identify what deserves to be built. It just as much consists of protecting a client from a build they would regret. An advisory that never recommends the subscription isn't advice: it sells its catalogue. That is why this piece matters as much to me as the one explaining when to build.
The situations where the subscription stays the right call
Applied honestly, the decision leans toward SaaS more often than it is sold. Five situations recur in my diagnostics:
- A real, confirmed network effect. The tool matters first because your clients, your partners or your ecosystem already use it: a shared invoicing standard, a professional platform where your market sits, an exchange format imposed by your counterparts. Building your own tool would mean asking a whole network to follow you — that almost never happens.
- Compliance whose monitoring usefully sits with the vendor. Payroll software that tracks every compensation fund, every collective agreement and every cantonal revision absorbs a permanent load of regulatory monitoring. Outsourcing that monitoring to a vendor who does nothing else is often more prudent than carrying it in-house.
- Functional depth beyond a small team's reach. The speed at which code is written has changed; the volume of edge cases to cover has not. A mature domain, accumulated over fifteen years by a specialised vendor, stays out of reach for a small team, even a well-equipped one.
- A need still in motion. As long as what the tool must do is discovered while walking, casting it in a custom architecture means paying twice: the build, then the rebuild. The subscription keeps its option value here — you commit little, you learn, you decide later.
- A commodity use, with no sensitive data and no differentiation. An internal brainstorming tool, a shared calendar, a collaborative spreadsheet: no competitive advantage in owning it, no serious risk in renting it. Building on principle would be an expense without purpose.
None of these situations is marginal. Taken together, they cover a majority of a SME's tools. Custom-built software is justified on the few tools that touch sensitive data, structure a central process or carry a differentiation specific to the company — not on the rest.
The false argument I hear most
The network effect is the most cited criterion, and the most often wrongly. A team that keeps a tool "because everyone uses it" mistakes the reason when that "everyone" is limited to itself. Five people used to a piece of software do not form a network effect: it is a habit, and the cost of changing it is real but finite. A network effect, by contrast, is external — it hangs on players the company neither controls nor can move. Confusing the two leads to keeping expensive subscriptions in the name of an advantage that does not exist.
The distinction looks academic; it changes the decision nonetheless. An internal habit is overcome through one-time change support, at the moment of the switch. An external network effect cannot be overcome — you have to live with it. Asking the question plainly, "who exactly, outside of us, makes this tool indispensable?", is often enough to decide.
How do you know which case you are in?
The answer reads not tool by intuition, but tool by criterion. For that I use a five-criteria grid, the same in both directions: it says when to build, and just as much when to refrain. I laid it out in Buy or subscribe: the 5-criteria decision grid. It assumes a prerequisite almost no one poses: knowing what you already pay, tool by tool — the inventory I describe in How much does your SME really pay for software subscriptions?
When the grid leans toward custom-built anyway, the decision becomes that of a custom-built project the company owns; and if the website itself is at stake, the logic meets that of a site built to last and stay citable. Yet in one case out of two, the honest conclusion of a diagnostic is: change nothing here, your subscription is the right call. To place this decision within the whole of a Swiss SME's digital work, the full roadmap is set out in What should a Swiss SME do about AI in 2026?
What to remember
— Keeping a SaaS is not a renunciation: it is an allocation decision. You build only what differentiates or exposes sensitive data; you rent what is common to all. — Five situations make the subscription win: real network effect, compliance carried by the vendor, complexity beyond a small team's reach, a need still in motion, a commodity use with no sensitive data. — The network effect is the most misused criterion: an internal habit is not one, and the difference changes the decision.
FAQ
You sell custom-built software: isn't recommending SaaS contradictory? On the contrary. Advice that never recommends the subscription isn't advice, it is a sales pitch. My value rests on charging for the action, not the recommendation — so I have no interest in pushing a build you would regret. Saying "keep this tool" is part of the work.
How do you tell a real network effect from a mere internal habit? By asking a precise question: who, outside your company, makes this tool indispensable? If the answer is limited to your own teams, it is a habit — overcome once, at the moment of the switch. If it involves your clients, your partners or a standard of your market, it is a network effect, and it leans toward the subscription.
Does a subscription's cost always end up exceeding that of an owned tool? No, and that is precisely the trap of the reverse reasoning. Custom-built software has a build cost, then a maintenance and monitoring cost. On a commodity need, well covered by the market, the subscription often stays cheaper over time than the build plus its maintenance. The calculation is done tool by tool, never as a whole.
Should this decision be reviewed over time? Yes. A tool rightly rented today may deserve to be built tomorrow if the need stabilises, the data becomes more sensitive or the vendor changes its pricing trajectory. The decision replays at renewal, not once and for all.
Torn between keeping a SaaS and replacing it with a tool of your own? The Diagnostic d'Usage IA: sixty minutes to lay out your actual workflows, tell apart what deserves custom-built treatment from what should stay rented, and leave with quantified priorities. Book a diagnostic
Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais, Switzerland. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.