top of page

Build or buy an AI solution when you have no development team

  • 6 days ago
  • 3 min read

Updated: 6 days ago

Introduction


The build-or-buy question feels like a comparison of cost and fit, and in a small business it is almost always settled by a third consideration that gets raised too late: who maintains it. Software that nobody owns degrades, and the person who built it leaves, changes role, or simply stops having time.

This does not mean building is always wrong. There are cases where a bought product cannot do what a business needs, or where the requirement is so specific that configuring a general tool costs more than building a narrow one. But the maintenance question should be asked first rather than last, because it determines whether a successful build is still working in three years.


1. Build or buy an AI solution turns on who maintains it


Ask this before anything else.

Named person, allocated time, and what happens when they leave. If there is no credible answer, the decision is made, regardless of how attractive the build looks.


2. Buy where the problem is common


Most problems are.

Invoice processing, scheduling, document search, transcription, forecasting. Thousands of businesses have the same requirement, products exist, and building your own version of a commodity is an expensive way to get a worse result.


3. Consider building where the process is your advantage


The legitimate case.

If a process is genuinely specific to how your business competes, a bought tool will force you towards how everybody else works. That is occasionally a good thing and occasionally the loss of the thing you are paid for.


4. Count the cost of building honestly


It is not the development time.

Specification, development, testing, documentation, hosting, security, updates, and the support burden forever. The build is a fraction of the total, and the ongoing part is the part small businesses underestimate.


5. Look at configuration as the middle option


Frequently the right answer.

A bought product configured to your process, or a general platform assembled without code. This gets much of the fit of a build with much of the maintenance profile of a purchase.


6. Check what happens to a bought product if the vendor disappears


A real risk with newer tools.

Data export, contract terms on termination, and whether your process could continue. Small vendors are acquired or close, and the question is whether that would be an inconvenience or a crisis.


7. Consider the integration burden either way


Where projects actually stall.

Both options have to connect to your accounting, scheduling or customer systems. This is frequently the largest part of the work and it is routinely omitted from both estimates.


8. Prefer the option you can reverse


Optionality has value.

A monthly subscription you can leave is worth a premium over a build you would have to abandon. In a fast-moving area, being able to change your mind in a year is worth more than a marginally better fit now.


9. Do not build to save money


The reason that fails most often.

Builds justified on avoiding subscription costs almost always cost more once maintenance is counted. Build because the fit matters or the process is your advantage, not because the licence looks expensive.

Whichever route you take, be clear about where your data sits, who can access it, and what happens to it on termination. That question applies equally to a vendor and to a self-hosted build, and the obligations depend on your jurisdiction and the data involved.


Conclusion


Ask who will maintain it before comparing anything else.

Buy where the problem is common because products already exist, consider building only where the process is genuinely part of your advantage, count the ongoing support and update burden rather than the development time, treat configuration of a bought product as a serious middle option, check what happens if a vendor disappears, include the integration work in both estimates, prefer the option you can reverse in a year, and never build primarily to avoid a subscription cost.


Related reading


 
 
 

Comments


bottom of page