The dilemma, honestly framed
Sooner or later, as an entrepreneur, you face the question: do we solve this ourselves with custom work, or do we buy a ready-made tool? It feels like an innocent technical choice, but in practice the wrong turn costs you money you can't afford to lose — in both directions.
Build too early, and you pour scarce budget and attention into something a cheap package has long been doing. You pay for maintenance, hosting and knowledge you don't need to own, while a subscription of a few tenners a month would have done the same. Cling to off-the-shelf software for too long, on the other hand, and you run a different risk: a competitor automates exactly the one process that set you apart, and you only notice when it's too late.
Experience teaches that most mistakes don't arise from a lack of technology, but from a lack of a repeatable way to decide. This article gives you that: a weighted scoring model and an honest cost lens, so the choice rests on evidence and not on vendor enthusiasm or the pride of being able to build something yourself.
The thesis up front, without ceremony: for most SME processes, the honest default is to buy. Building is the exception you have to be able to defend. It's no coincidence that large IT projects — measured by McKinsey & Company together with the University of Oxford — show that they go on average some 45% over budget. Building big is a cliff. You should not come anywhere near it.
Why 'build vs buy' is the wrong question
The problem with the question "build or buy?" is that it forces you into a company-level choice, while reality plays out at the process level. Your bookkeeping, your quote follow-up and your scheduling each deserve their own answer. One decision for the whole business is almost always too coarse.
Gartner therefore reframed the classic dichotomy years ago into "buy and compose": not buy or build, but compose. You buy packaged, ready-made capabilities and assemble from them a whole that fits your business. The question is therefore no longer "do we make it ourselves?", but "where on the spectrum does this specific process belong?".
That spectrum runs from buying, through configuring, to automating, to building. On the left side you take a package exactly as it is. A little further along you set it up and tailor it to your way of working. One step further still, you connect tools and lay an automation or AI layer over them. Only on the right side do you really build something unique from the ground up.
With that lens, the whole "build vs buy" battle falls away. You no longer ask who is right, but where each process sits. The rest of this article therefore scores per process — not per company. That is the only way to do justice to reality: most things belong on the left, and the odd process deserves a place further to the right.
The 4 decision criteria that make the difference
To place a process on the spectrum, you don't have to be an IT architect. Four questions, in plain language, get you surprisingly far. Answer them honestly for every process you're considering.
One: differentiation. Does this win or retain customers, or is it the same plumbing everyone has? Payroll administration wins no customers — your competitor does it just as well. But the speed with which you get a quote out the door can indeed be the difference for why a customer chooses you. Differentiation is the most important question; more on that later.
Two: process fit. How far do your steps deviate from what standard tools assume? Most packages are built around a common way of working. If you work largely like the rest, a tool fits like a glove. If your process has quirks that fit nowhere, the friction begins — and that friction costs money.
Three: integration effort. How many systems does this have to talk to, and how clean are their connections? A tool that talks neatly to your bookkeeping and CRM via an open API is something quite different from a tool that only releases data via export and manual labor. The more systems and the messier the APIs, the more expensive every direction becomes.
Four: rate of change. How often do the requirements shift? Here lies the counter-intuitive criterion. You'd think that rapidly changing processes call for custom work, but the opposite is usually true: a high rate of change argues for buying. A vendor carries the burden of keeping up — think of changing tax rules. You only build yourself if that changing thing is precisely your differentiation and you want to keep control in your own hands.
A scoring model you can run in an afternoon
Turn those four criteria into a weighted scoring model. Give each process a score from 1 to 5 per criterion, multiply by a weight, and add it up. Going through the whole business this way costs you no more than an afternoon.
The weights are what it comes down to. Weigh differentiation the heaviest — times three. Process fit and rate of change get a medium weight, times two. Integration weighs the lightest, times one. Why does differentiation dominate? Because that is the only reason building yourself is ever worth the trouble. Something everyone has, you're better off buying, however poorly it fits; something that truly sets you apart deserves investment, even if everything else works against it. The other criteria add nuance, but may never drown out differentiation.
Read the outcome in three bands. A low total score means: buy as is. A score in the middle means: buy and configure, or buy plus a light automation layer as glue in between. A high score means: build the distinguishing section — and only that.
A small example makes it concrete. Payroll administration: differentiation 1 (×3 = 3), process fit 5 (×2 = 10), rate of change 1 because rules change often and you don't want to keep up with that yourself (×2 = 2), integration 4 (×1 = 4). Total low — buy. A custom quote follow-up: differentiation 5 (×3 = 15), process fit 3 (×2 = 6), rate of change 4 (×2 = 8), integration 3 (×1 = 3). Total high — build that layer. The model forces you to put differentiation at the center and guards you against building out of habit.
Three worked-out scenarios
Let's run three recognizable SME situations through the model, so you can see how the outcome tips.
Scenario A: bookkeeping and payroll administration. This is commodity par excellence. It doesn't set you apart — no customer chooses you because your pay slip is prettier. The rate of change is high, but in the wrong way: tax rules and collective labor agreements change constantly, and you absolutely do not want to be the one who has to build that yourself. The process fit with standard packages is excellent, because virtually everyone works according to the same fiscal logic. The outcome is crystal clear: buy, never build. A vendor takes the burden of compliance off your hands, and you'll gladly pay for that.
Scenario B: quote follow-up at a service provider. Here it gets interesting. There's a moderate quirk in it — your way of following up is just a bit different from standard — and there's real differentiation in it: speed to quote wins deals. Whoever puts a well-considered quote on the table first wins more often. The honest solution is a hybrid. Buy a common CRM for the standard registration, but build the automation and AI layer on top of it: automatic reminders, a light AI that suggests draft follow-ups, with a human who checks them before sending. This is exactly the terrain where Automatiza LATAM makes the difference — light AI, human in the loop, built on top of standard software rather than under it.
Scenario C: a genuinely unusual core operation that no vendor models. Think of a niche business with a way of working so distinctive that no package comes close. High differentiation, poor process fit. Here building is the right answer — but deliberately, with eyes open. You accept the maintenance bill that comes with it, because this is precisely your reason for existing. No invented return promises; just a clear trade-off.
The hidden costs of building
Whoever builds themselves often looks only at the builder's quote. But that price is the down payment, not the bill. The real costs only begin after it has been delivered.
There is maintenance. Software that lives must be maintained: bugs surface, users want adjustments, and what works today falters tomorrow. There is security — patches, updating dependencies, plugging holes that are continuously discovered in the libraries your construction leans on. There is hosting, day in, day out, regardless of whether you use the software intensively that month. Count on maintenance costing a meaningful portion of the original build sum each year; it is not a marginal phenomenon but a fixed item.
But the hardest cost item for an SME is human. Who still understands the system once the builder leaves? This is the bus-factor risk: if the one person who grasps the code gets hit by a bus tomorrow — or simply finds another job — you're left with a black box. Replacing or holding on to that knowledge is expensive and fragile, and precisely in a small business that dependence on one person is enormous.
Link this to the evidence from McKinsey and the University of Oxford: it is the large, complex custom builds where projects go off the rails — on average some 45% over budget and some 56% less value than predicted, measured across more than 5,400 projects where "large" meant above 15 million dollars. Your build sits miles below that, and that is exactly the point: if you build, build small and narrow. The cliff sits at the very far end of the scale, and that's not where you want to crawl toward.
The hidden costs of buying
Fair is fair: with buying too, the shop-window price is not the real bill. Off-the-shelf software has its own hidden costs, and whoever ignores them ends up disappointed later.
Start with the per-user price. A subscription that looks affordable at five employees adds up considerably at twenty-five employees — license creep that grows with your success, precisely at the moment you least want surprises on the cost item. On top of that come paid tiers and add-ons: the feature you truly need often sits just inside the more expensive package. And count on adjustment and integration work, because even purchased software rarely talks to your other systems by itself.
Then there is vendor lock-in. The longer you use a tool, the deeper your data, your way of working and your people become anchored in it. Should you ever want to leave, you run into painful data export, retraining and switching costs you rarely budget for in advance. Assume the actual total costs come out higher than the advertisement promises.
For the EU SME, an extra dimension comes in: data residency and exit conditions. Where is your data, under which law does it fall, and how easily do you get it back? Lock-in is, for a European entrepreneur, not only a cost question but also a sovereignty question. That buying has by now become the mainstream — Eurostat reports that in 2025 around 53% of EU companies used paid cloud services, and the CBS reports that in 2024 some 71% of Dutch companies with 10 or more employees used the cloud — does not automatically make it wise to sign blindly. Mainstream means normal, not carefree.
Setting up an honest TCO comparison
You can only compare building and buying fairly once you place both side by side over the same time span and with the same completeness. Not with an invented number, but with a reusable template that you fill in with your own figures. Take a realistic horizon of three to five years — short enough to stay manageable, long enough to make the true costs visible.
On the build side, you list: discovery and build (the one-time down payment), hosting across the whole time span, maintenance per year, security and updates, people and knowledge retention — holding on to or replacing whoever understands the system — and the opportunity cost of delay, because while you build, the process isn't running yet.
On the buy side, you list alongside it: licenses, multiplied by the expected growth in the number of users; implementation and configuration; integration with your existing systems; the extra add-on layers you turn out to need along the way; training of your people; and a reserve for switching or exit, because someday you might want or have to leave.
Lay those two columns side by side and you immediately see where the break-even point lies. Buying wins early and wins on speed — you're up and running tomorrow, not in half a year. Custom work only earns itself back after several years, and only if the process is stable enough to spread the build across those years. If the process changes constantly, you'll never reach that break-even point, because you keep rebuilding. The comparison is therefore not an arithmetic trick, but a way of thinking: it forces you to look at the whole picture over years, instead of at the price of year one.
The hybrid: buy the standard stuff, build the edge, keep it modular
Here everything comes together in the recommended default. Buy off-the-shelf for everything that is commodity — bookkeeping, email, scheduling, the common CRM. Build or automate only the distinguishing section, the thin layer where your edge lies. And keep the whole thing modular and connected via APIs, so each part stays replaceable. What you buy today, you can replace tomorrow without the whole construction collapsing.
Be honest about the integration, because that's where the reality sits. There is a rising scale in cost and control. Cheapest and simplest are native integrations — connections the vendors have already built themselves. If that doesn't work, you end up at iPaaS or no-code automation: platforms that tie tools together without you writing code, a bit more expensive but still manageable. Only when that too falls short do you write your own connecting glue — the most expensive option, with the most control and the most maintenance. Climb that ladder deliberately, step by step, not in one leap to the top.
This is where the modern third way lies. Instead of building the underlying software, you increasingly build the workflow: light automation and AI with a human in the loop, on top of standard software you simply buy. You no longer write a bookkeeping package; you build the smart layer that makes your purchased tools work together the way your business works. That dovetails seamlessly with Gartner's idea of "buy and compose": you compose packaged capabilities into something of your own, and the value you add sits in the composition and the automation layer — not in reinventing what already exists.
Pitfalls that quietly ruin the decision
Even with a good model, entrepreneurs slide into predictable pitfalls. Run through this checklist before you sign.
Building for prestige — making something yourself because it's possible or impressive, not because it differentiates. Budgeting maintenance and the bus-factor risk too low, as if delivery is the end of the costs rather than the beginning. Loyalty out of sunk cost to a tool you've long outgrown, because you once invested in it. Treating integration as an afterthought and only discovering that nothing talks to anything once everything has already been bought. Choosing on the price of year one instead of on the total costs over multiple years. Ignoring exit and lock-in until the moment you want to leave and find you're stuck. And finally: scope creep, where a "small build" gradually swells into precisely the kind of large, derailing project that ends up in the statistics. Each of these pitfalls is innocent on its own and dangerous for exactly that reason — they creep in while you're looking at the wrong side of the compass.
How to decide this week (and where a partner fits)
Don't wait for the perfect moment; you can do this this week. Lay out your processes. Take the most important five and score them with the model from this article — differentiation times three, process fit and rate of change times two, integration times one. Add them up and read off the bands.
You'll notice that most processes land on "buy," with at most one or two on "build the thin layer." That is not a disappointment but exactly the intention. The honest default for the SME is to buy; building is the exception you have to be able to defend with the model. Whoever turns that around pays the bill sooner or later.
Sometimes an outsider helps to fill in those scores honestly, because you rarely see your own processes objectively. That's where Automatiza LATAM's role fits: a free automation scan that maps, per process, what is commodity and therefore ought to be bought, and which slim layer deserves a light custom or automation solution. EU-hosted, with a human in the loop, built on top of the standard software you already use. No sales pitch for a large build project — quite the opposite: an honest map of where building yourself is and isn't worth the trouble. Want to know which of your processes truly deserve a layer of their own and which you're better off simply buying? Request a free automation scan and start making the choice on facts.