Building AI in-house vs buying a tool

There is a product for your problem. There are probably nine. One of them demos well, costs less than a developer, and does roughly eighty per cent of what you need.

That eighty per cent is the entire decision. Whether the missing part is a nice-to-have or the reason your customers choose you decides this question more reliably than any comparison of features, and it is a question about your business rather than about software.

What you are actually paying a vendor for

People underrate this list, so it is worth writing out. When you buy, you get a product someone maintains on a Tuesday when you are on holiday. You get security patches, uptime that is somebody else's job, and a support number. You get compliance documents already written, which matters more than it sounds when a customer's procurement team asks for them.

You also get other customers' feature requests. A product used by two thousand businesses receives improvements you never asked for and sometimes did not know you needed. That is real value, and no internal build produces it.

What you do not get is fit. A product is the average of its market, and your process is not the average of anything.

Where the eighty per cent rule breaks

Apply one test. Describe the missing twenty per cent out loud. If it sounds like a preference (we would lay the screen out differently, we would prefer a different report format), buy the tool and adapt. If it sounds like the reason customers choose you (we quote in four hours when the industry takes three days, we handle a document type nobody else accepts), then the tool does not solve your problem, it solves the generic version of your problem.

The trap is that both sound similar in a meeting. The difference shows when you ask what happens if you simply drop the requirement. If the answer is "we would work the way everyone else does", you have found your differentiator and buying it off a shelf makes you average on purpose.

Five questions before you commission anything

1. Is this process your differentiator, or is it plumbing? Buy plumbing without sentiment. Nobody has ever won a market by building their own helpdesk, accounting package or calendar.
2. How deep does the integration go? A tool that syncs with your systems is one you can leave. A tool that becomes the system of record for something important is one you will still be using in eight years, whether or not it is still good.
3. What does the exit look like? Ask for a sample export before you sign, not after. Ask what format it comes in, whether it includes history and attachments, and how long a migration typically takes. A vendor who answers cleanly is telling you something about the relationship.
4. What does this cost when you are twice the size? Seats, volume tiers and the modules that turn out to be add-ons. The full version of that exercise is the three-year cost picture, and it is worth doing on both options rather than only on the build.
5. Does the vendor still want your segment? A product whose roadmap has moved upmarket will keep taking your money while quietly freezing the features you depend on. Ask what shipped for customers your size in the last year.

The hybrid that usually wins

Most businesses should buy the platforms and build the thin layer. Keep the bought CRM, the bought accounting package and the bought helpdesk, then build the one small system that does the thing nobody sells: the quote logic that matches how you actually price, the intake that handles your customers' peculiar document formats, the assistant that answers from your own material.

This also fails least badly. If the custom layer is small, replacing it is a project rather than a crisis, and the platforms underneath keep working while you do it. A build that spans your whole operation has the opposite property.

Where that layer is a workflow rather than a product, the next question is how to implement it, and that is no-code against a custom build.

When building it yourself is the wrong answer

If nobody will own it, do not build it. This is the same rule that governs whether a process should be automated at all, and it is not softened by the build being interesting.

If the problem is a commodity, do not build it. If the subscription costs less per year than two weeks of engineering, do not build it, and notice when the argument for building is really an argument about disliking subscriptions.

And if you are building because your team wants to build, say so out loud. That is sometimes a legitimate reason, for skills or for strategic control, but it should be argued on those terms rather than smuggled in as a cost saving that will not materialise.

We build custom systems, so take this accordingly: for perhaps half the enquiries we get, the honest recommendation is a product that already exists plus a week of configuration. The half where a build is right tends to look the same each time, which is a process the business is measurably better at than its competitors, running on tools that were built for someone else.

The failure mode to picture

Someone builds an internal tool. It is good. Three teams start using it, then it becomes the way a process runs, and at that point you own a product without owning a product team. There is no documentation, no onboarding, no roadmap and no second person who understands the data model. The person who built it is now, permanently, the support desk.

It does not fail loudly. It fails when that person leaves, or when a dependency needs upgrading and nobody knows what will break. The cost is not the original build, it is the year you spend either rebuilding it or paying someone to understand it.

Deciding which of your processes deserve a build, and which should stay bought, is the point of the audit work we do before anything is commissioned. The rest of the comparison guides take the same decision apart from other angles.

Frequently asked questions

Is a custom build always more expensive than a subscription?

Over three years, often not, especially as seat counts grow. But the comparison has to include maintenance, hosting and the internal time to own it, and those are the lines that make a build look cheap when they are missing from the sheet.

Can we buy a tool now and build later?

Yes, and it is usually the right order, provided you check the exit before you sign. A bought tool that runs your process for two years also documents it precisely, which makes the later build cheaper and more accurate.

What if the vendor's AI features are just an API call?

Many are, and that is not automatically bad: you are paying for the surrounding product rather than the model. It becomes a problem when the price is set as though the AI is proprietary and your alternative is a thin layer you could build in a fortnight.

How do we avoid building something nobody maintains?

Name the owner before the first line of code, write down what happens when they leave, and keep the custom part small enough that a second person can learn it in a week. If those three things cannot be arranged, buy instead.