Build or buy AI software? A practical guide for mid-sized businesses

Start with the job, not the product demo

Write down one task from the first request to the final result. Who starts it? Where does the information live? Who checks the output? What happens when something is missing? A polished demo can hide the steps your team still has to perform by hand.

Suppose your team prepares customer quotes. Reading the request might suit a general AI tool. Applying your pricing rules, checking availability and sending the quote through the right approval process might need a custom connection. Those are separate decisions, even though they happen inside one task.

Buy when the standard workflow is a good fit

I would try an existing product first when it handles the actual task with little adjustment, works with the systems you already use, and lets your team check the output comfortably. The advantage is getting to a useful test without owning all the development work.

Do not evaluate it only on the quality of one answer. Walk through representative cases, including messy ones. Check permissions, data export, supported integrations and the steps left outside the product. If people still move everything between tabs, the subscription may have improved a fragment rather than the workflow.

• Can the tool use the business information required for this task, with appropriate access?
• Can an employee review and correct its output in the normal working process?
• Can you retrieve your records and move to another solution if the product stops fitting?

Build when your rules and handoffs are the missing piece

Custom software becomes worth considering when a valuable process has rules, exceptions or connections that a ready-made product does not handle well. Maybe your quotes depend on customer agreements. Maybe each request passes through a specific sequence of approvals. Write down the gap before writing code.

The useful custom system might be small: an internal screen that assembles the relevant records, asks AI for a structured draft and gives an employee an approval button. You can keep your CRM and accounting tools. Building the missing workflow does not require replacing every system around it.

Ask who will maintain the integration, update the business rules and investigate incorrect results. Software you own still needs an owner. A development quote without an ongoing maintenance plan does not describe the full commitment.

Often, the sensible choice is a combination

Here is a hypothetical example. A service company already has a CRM and a scheduling system. Its team wants help preparing replies to new inquiries. It could use an existing language model through an API, keep customer records in the CRM, and build a small layer that retrieves approved information and prepares a reply for review.

In that arrangement, the company owns its workflow and approval rules while using existing infrastructure. An ordinary rule may be enough for routing; AI can handle the part that involves interpreting varied customer messages. Do not make every step autonomous just because the project involves AI.

Anthropic’s engineering guidance on building effective agents recommends starting with the simplest solution and adding complexity when it improves outcomes. That principle applies here too. Decide what the process needs before deciding how impressive the architecture should sound.

Compare the full ongoing cost

For a purchased tool, include seats, usage, setup, training and the human work that remains. For a custom solution, include development, hosting, model usage, monitoring, maintenance and review. Also ask what happens when an integration changes or the person responsible is unavailable.

I would compare both options using the same task and the same quality standard. Count preparation, review, corrections and exceptions. My ambition of removing half of suitable repetitive office work is a target to test, not a promise that either buying or building will automatically achieve it.

Make the next decision small enough to reverse

Choose a short, limited trial around one workflow. Define the output, the approval point and the evidence you need before expanding. Avoid a large rebuild until you have shown that the missing connection is genuinely useful to the people doing the work.

If you are weighing a tool against custom development, bring a real example of the task, the systems involved and the rules that make it difficult. That is enough to start a useful conversation. The best choice is the one your team can operate reliably after the demo ends.