Five criteria are enough to decide, tool by tool: is the need well-defined or still evolving, how sensitive is the data, is there a real network effect, does the functional complexity exceed what a small team can handle, and does the decision remain reversible? This is the framework I run through in the Diagnostic d'Usage IA, before making any recommendation. No single criterion decides on its own — it's their combination that tells you whether to rent or build, and in a significant number of cases, the right answer is still to subscribe.
Where does this framework come from?
This framework wasn't born from theory. It's the backbone of the Diagnostic d'Usage IA, the sixty-minute session in which we review, tool by tool, what should stay rented and what deserves to be built and owned. It deliberately sticks to five criteria: any more, and the exercise stops being actionable within an hour; any fewer, and it oversimplifies a decision that commits the company for several years. Each criterion answers a precise question, and none substitutes for the other four.
The five criteria, one by one
Is the need well-defined, or still evolving? A well-defined need can be described in a few stable sentences: what the tool has to do won't change fundamentally over the next two or three years. An evolving need, by contrast, is discovered along the way — the first version won't resemble what will be needed in eighteen months. Building a custom solution for a need that's still evolving means locking in an architecture before you even know the question; it's the surest way to pay twice, once to build and once to rebuild. This was the criterion that weighed most heavily in my decision to build FiscalDoc, my local tax-filing application, rather than subscribe to a tool on the market: the need was completely well-defined — sorting Swiss tax documents into categories I already knew, for scopes I understood in detail. Nothing to guess, nothing that would need to shift with the market — a stable need, to be built once and owned afterward. The case is documented from start to finish.
How sensitive is the data involved? Financial data, HR files, information covered by trade secrecy, personal data under Switzerland's revised data protection act (nLPD/nDSG): the more sensitive the data, the more the question of where it travels and who can legally access it weighs on the decision. A custom tool, hosted where the company decides and whose code and encryption keys it controls, sharply reduces this category of risk. Conversely, a tool for team scheduling or internal brainstorming that handles no sensitive data doesn't need this guarantee: subscribing exposes the company to nothing serious there, and building on principle would be spending without purpose.
Is there a real network effect? Some tools are valuable above all because of how many people already use them outside the company: a billing tool your clients also use, a file standard shared with partners, a professional platform where your ecosystem already lives. Building your own tool in that case means asking an entire network to follow you — that almost never happens. A real network effect makes subscribing win, hands down. The trap is invoking it by reflex: a five-person team that uses a tool because "everyone uses it" benefits from no network effect if that "everyone" is limited to itself. That's a habit, not a network effect — and the difference deserves to be named honestly before deciding.
Does the functional complexity exceed what a small team can handle? Payroll software that covers every compensation fund, every collective bargaining agreement, and every cantonal exception represents years of adjustments accumulated by a vendor whose sole job is exactly that. Rebuilding that depth in-house, even with the best coding assistants, remains out of reach for a small team: the speed of writing code has changed, not the volume of edge cases to cover or the time it takes to verify them one by one. Conversely, a functionally narrow need — an internal approval workflow, document classification, a focused dashboard — remains perfectly within reach of a custom-built tool, without requiring the depth of a specialized vendor.
Does the decision remain reversible? A subscription looks reversible in the short term — you can cancel next month — but it becomes less and less so as data accumulates in it: history, attachments, automations built into the tool. Leaving has a cost that almost no one budgets for at signing. An owned tool, built to order, by contrast demands a clearer commitment at the outset; but once built, reversibility belongs to it alone: the company is never held hostage to a third party's roadmap or pricing policy.
When does subscribing still win?
The framework isn't an argument for custom-built software. Applied honestly, it makes subscribing win in a number of situations that I consider underestimated by the discourse that sells transformation for its own sake: a confirmed real network effect, collaboration that extends well beyond the organization, compliance whose monitoring burden falls on the vendor, complexity that exceeds what a small team can reasonably sustain. I've gathered these situations, with their own logic, in In which cases is keeping your SaaS the right choice? — an article I consider just as important as this one, because knowing when not to change anything is part of good advice, not the absence of it.
This framework assumes a prerequisite: knowing what you're already paying for, tool by tool. Without that inventory, it applies to a void — I've detailed it in How much is your SME really paying in software subscriptions?, the first step before any decision. Once the framework tips toward custom-built, the next question is the real cost of building, which I address head-on in What does custom software cost in the age of augmented development? This is exactly the framework I run through when scoping every custom project, before writing a single line of code. To place this decision within the full set of digital initiatives facing a Swiss SME, the complete roadmap is laid out in What should a Swiss SME do about AI in 2026?
Key takeaways
— Five criteria decide, tool by tool: a well-defined or evolving need, data sensitivity, a real network effect, functional complexity, reversibility. — No single criterion decides alone; it's their combination — not intuition or habit — that should guide the choice. — Subscribing often remains the right answer: a confirmed network effect, complexity beyond what a small team can handle, compliance carried by the vendor.
FAQ
Does this framework apply to all tools, or only to new projects? Both. It frames a purchasing decision, but it works just as well to re-examine an existing subscription at renewal time. Nothing stops you from applying it, tool by tool, to the list that comes out of an inventory of current subscriptions.
What if two criteria point in opposite directions? That happens often, and it's precisely the value of the framework: it makes the conflict visible instead of letting it be decided by default. Generally, data sensitivity and reversibility carry more weight than functional complexity alone — but the weighting remains specific to each company and each tool.
Do you need to redo this analysis for every small tool in the company? No. The framework has a cost to apply; it's justified for tools that weigh on the budget, touch sensitive data, or structure a central process. A minor, low-cost tool with no sensitive data doesn't warrant a five-criteria analysis.
FiscalDoc is a one-person case. Does the framework hold up at the scale of a twenty-employee SME? Yes, the reasoning doesn't change with scale: only the way each criterion is answered evolves. An SME has more users, so a network effect and a collaboration complexity that need to be assessed more finely — criteria three and four often carry more weight there than in individual use.
Torn between renting and building for one of your tools? The Diagnostic d'Usage IA: sixty minutes to lay out your actual workflows, identify what deserves custom-built treatment, what stays as SaaS, and what doesn't need AI at all. 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.