Build, Buy or Connect: Choosing How to Add AI to an SME

Photo: Z22, via Wikimedia Commons · CC BY-SA 4.0
The first real decision in most AI projects is not which model to use. It is whether to buy a product, build something specific, or connect what you already have. People tend to walk in with a preference already formed. Engineers lean towards building. Finance leans towards buying. Almost nobody leans towards connecting, because it sounds like the least interesting option. It is often the right one.
When buying makes sense
Buy when the problem is common and your way of handling it is not special. Transcribing meetings, drafting emails, translating documentation, reading standard invoices. Thousands of companies share that need, and a good product will have been shaped by all of them. You will not beat that with a custom build, and you should not try.
The warning sign is when you start listing exceptions. If the demo covers seventy percent of your cases and the rest need "a bit of configuration", ask to see that configuration working on your own data before you sign. The remaining thirty percent is usually where your business actually lives.
When building makes sense
Build when the workflow is specific to how you operate and it matters to your margins. Quoting logic that carries twenty years of knowledge about which jobs are profitable on which machines. A planning rule that reflects how your shop floor really works, rather than how a textbook says it should. That kind of logic is part of what makes you competitive. Handing it to a generic product, or letting it vanish into a vendor's black box, is a real cost.
Building does not have to mean a large software project. More often it means a small, well-tested piece of logic that sits between systems you already own.
When connecting is the answer
A surprising amount of what companies call an AI problem turns out to be an integration problem. The data already exists in the ERP, the mailbox, the shared drive and the machine controller. What is missing is a way to bring the right pieces together at the moment someone has to make a decision.
In those cases the AI part can be quite small, extracting a handful of fields from an email for example, and the real value comes from connecting that output to the ERP so nobody has to retype it. The AI makes the connection possible. The connection is what saves the time.
A rough rule
Buy the generic. Build the part that is genuinely yours. Connect everything else. Most useful systems end up being a mix of all three.
Questions that usually settle it
- Would a competitor handle this step in exactly the same way? If so, buy.
- Does this step hold knowledge that took years to learn and affects margins? Then consider building.
- Does the information already exist somewhere, just not in the right place at the right time? Connect first, and see what is left.
- Who will maintain it in three years? A bought product has a vendor. A built one needs an owner. A connection needs someone who understands both ends.
That last question changes the decision more often than any other. A clever custom build with no owner becomes a liability on the day the person who wrote it leaves.
Start with one workflow
Whichever route you choose, test it on one bounded workflow before rolling it out across the company. A single flow, measured before and after, tells you more about whether the approach fits than any amount of vendor comparison. If it works, you have a pattern. If it does not, you found out cheaply.