AI / KMO / SME / operations / AI-waardescan / implementation
Buy or build? How SMEs should decide on AI
Within a week of deciding to automate something, almost every company I work with arrives at the same fork in the road. Someone has found a tool that promises to do exactly this, for €49 per user per month. Someone else says the tool will never fit the way we actually work, so we should have something built. Both people are usually half right, and the meeting ends without a decision.
This is where a lot of SME budget quietly disappears. Not in a failed project, but in a subscription nobody cancels for two years, or in a custom build that solved a problem an off-the-shelf tool already solved for a tenth of the price.
I build things for a living, so it would be convenient for me to say build. I don’t. For most SME processes, buying is the right answer. The trick is knowing which processes those are.
Five questions that settle it
1. Is this process standard across your industry?
Invoice processing, expense approvals, VAT reporting, basic email triage. Thousands of companies do these almost identically, which is exactly why good tools exist for them. If your process looks like everyone else’s, someone has already built a better version of it than you will fund.
Quote drafting is where it gets interesting. Every company thinks its quoting is unique. Usually the pricing logic is unique and the document assembly is not.
2. Does the tool fit without workarounds?
The honest test: can your team use it on day one without keeping a parallel spreadsheet? If the answer involves “we’d export to Excel and then”, the tool does not fit. You are not buying a tool at that point, you are buying a tool plus an unpaid ongoing job for one of your people.
My rule of thumb is 80%. If a tool covers 80% or more of the process out of the box, buy it and adapt the remaining 20% of your process to the tool. Below roughly 60%, configuration cost starts to approach build cost, and you get lock-in for free.
3. Does it need to talk to your other systems?
This is the question that flips the most decisions. A tool that lives on its own island is easy to buy. A tool that needs to read from your ERP, write to your CRM, and pick up documents from a shared drive is a different animal, and vendors are optimistic about integrations in a way that rarely survives contact with a fifteen-year-old ERP.
Ask for a concrete answer, in writing, about your specific systems and versions. “We have an open API” is not an answer.
4. Is this process a differentiator, or is it plumbing?
If the way you do it is part of why customers choose you, be careful about handing it to a vendor who sells the same thing to your competitors. If it is plumbing, and most processes are plumbing, there is no strategic value in owning the code.
Support triage is a good example. How fast and how well you respond is a differentiator. The routing logic underneath it usually is not.
5. Who owns this in year two?
Bought tools come with a vendor who patches, updates, and stays compliant. Built tools come with you. That is fine if you have someone technical, or a partner on a maintenance arrangement, and it is a slow-motion problem if the person who understands it leaves.
The middle path most SMEs actually need
The buy-or-build framing hides the option that fits most companies between 30 and 200 people: a thin custom layer on top of the tools you already pay for.
You have a CRM, an ERP, a mailbox, and a document store. They all have APIs. The expensive part is almost never the AI, it is the plumbing between systems that were never designed to talk. A small piece of custom work that moves data between things you already own is usually a one to four week job, costs a fraction of a full build, and leaves your vendor relationships intact.
Most of the quick wins I deliver are exactly this. Not a new platform, a bridge.
The hidden costs on each side
When you buy: per-seat pricing that looks fine at 8 users and hurts at 40. Annual increases you agreed to in clause 14. Your data in a format you cannot easily get out. And the quiet one, the process reshaping itself around the tool until switching becomes a project of its own.
When you build: maintenance, which is real and ongoing, roughly 15 to 20 percent of the build cost per year. Dependency on whoever built it. And scope creep, because once people see something built for them, they have ideas.
Neither list is a reason to avoid one path. They are line items that belong in the comparison, and they are usually missing from it.
A short checklist
Before the next meeting on this, write down for the process in question:
- Hours per week it currently consumes, and by whom
- Whether a tool covers it at 80% without a parallel spreadsheet
- Which systems it must exchange data with, named specifically
- Whether it is a differentiator or plumbing
- Who maintains it in year two
- Three year total cost of both options, not year one
If the answers point to buy, buy, and spend the saved budget on the process that genuinely needs building.
Where this decision belongs
This is not a decision to make once for the whole company. It gets made per opportunity, and the answer is often buy for three of them and build for one. That is the point of doing the diagnosis before the shopping: you end up with a short list where each item has a clear verdict and a cost attached.
That is what an AI-waardescan produces. Not a recommendation to build everything, but a prioritized list where buy, build, and bridge each show up where they belong.