There is a recognisable moment in the growth of an SME: the one where the CEO opens a new tab, searches "best tool for X", compares three SaaS solutions, and subscribes to the middle one.
Multiplied by twelve decisions of this kind over two years, the result is a stack that costs too much, does not integrate, and differentiates from nobody, because competitors ran exactly the same search. The build vs buy decision for an SME is not a budget question. It is a strategic diagnosis that has been framed incorrectly from the start.
The question nobody asks
"Buy before you build." The advice is widespread, defensible, and partially correct. SaaS tools allow you to move fast, avoid maintaining infrastructure, and benefit from continuous updates. For standard functions like accounting, HR, or email management, it is the right answer in almost every case.
The problem is not the advice. It is that it gets applied indiscriminately to every decision. A standard CRM, a support tool, a payment platform: buy. A routing algorithm that optimises your logistics chain better than any competitor, an interface that creates a user experience nobody else offers, a recommendation system trained on your own data: build.
The distinction seems obvious when stated this way. It is not obvious for a CEO making ten technical decisions per quarter under time and budget pressure. Without an explicit framework to separate what differentiates from what commoditises, the default decision is always the SaaS. Fast, low-risk, defensible in a board meeting. And progressively fatal for competitive advantage.
What the SaaS stack conceals
Why do so many SMEs end up with unmanageable stacks after two years of growth? Because each individual decision was reasonable. The problem is not in the choices taken one by one. It is in what they produce collectively: a fragmented architecture, data dispersed across twelve tools that do not communicate, and a dependency on vendors whose updates can break entire processes overnight.
Vendor lock-in is not a theoretical risk. It is the concrete situation of a company that stored its data in a proprietary format and discovers, when it wants to switch tools, that migration is as costly as building a custom solution would have been from the start. The initial cost was not low. It was deferred.
The global SaaS market will reach $408 billion in 2025 according to Precedence Research, growing at 13% annually through 2034. That growth reflects massive adoption, not necessarily buyer satisfaction. An explosively growing market can coexist perfectly well with executives who regret half their subscriptions.
The right question, finally
What is it, in your business, that justifies being better than your competitors in two years? That question changes the analysis entirely. It forces a distinction between commodity functions, those everyone must have to operate, and differentiating functions, those on which real competitive advantage is built.
Everything in the first category deserves to be bought. Accounting, payroll, absence management, first-level customer support: no SME builds its competitive advantage on these functions. Buy them well, buy them fast, and move on.
Everything in the second category deserves to be built. A logistics company that develops its own route optimisation algorithms does not entrust that advantage to a generic SaaS that its competitors also use. It builds, maintains, and improves that system because that is precisely where the difference between it and the market lies.
The hybrid approach is not a compromise. It is the only strategically coherent position. It simply requires asking the right question before opening the first SaaS comparison tab.
What this means in practice
Most build vs buy discussions start with cost. How much does the SaaS cost per month? How much does custom development cost? How long does it take to build? These questions are legitimate but secondary. The primary question is strategic: does this decision build something my competitors cannot replicate by subscribing to the same tool?
At Nightborn, the first conversation is not about what we are going to build. It is about what deserves to be built. Our first deliverable is often a recommendation, not a sprint: build this, buy that, and here is why the distinction matters for your position in eighteen months. That is not an altruistic stance. It is the only way to build something that lasts.
If you regularly make build vs buy decisions without a clear answer to the competitive advantage question, that is probably the conversation to have before the next one. Let's take thirty minutes to work through it together.
.webp)