Build vs Buy for AI in a Small Company

"Build or buy" hides the options most small companies actually use. HatchWorks describes a middle path that many organizations land on: buy the core platform, then build the customization and intelligence layer on top, such as automation, reporting and integrations (HatchWorks AI). For a small company, that splits into four practical paths.

KPMG's decision framework gives five questions that sort a use case into these paths: what share of your needs off-the-shelf products meet, how configurable they are, whether essential capabilities are available through APIs, whether low-code platforms or APIs can cover the bespoke part, and whether your team has the skills to use the tools effectively (KPMG).

Most small companies should live mainly in the first two paths, with occasional assembly. Ready-made building blocks, such as the skills, playbooks and agents in the Quanta Intelligence library, sit between configure and assemble: you adapt work someone else has already tested instead of starting from a blank page.

Buy when the work is standard. The AI, Data and Analytics Network frames the core trade-off as control versus speed, and notes that operational or standardized use cases, such as invoice processing, can get value quickly from a vendor without deep internal development (AI, Data and Analytics Network). It adds that vendor platforms can deliver value in weeks or even days, while building from scratch can take months.

Buy when compliance and edge cases are the hard part. HatchWorks advises buying where you are paying for years of accumulated edge cases, audits, workflows, uptime and support (HatchWorks AI). Bookkeeping, payroll and payments are good examples: the AI is a small part of the value, and the vendor's handling of rules and exceptions is most of it.

Buy when you lack the people to run it. Building and operating AI takes more than a developer; the AI, Data and Analytics Network lists operations engineering, software engineering, cloud and domain expertise among the skills needed, and warns that building without them is risky and slow (AI, Data and Analytics Network). ELEKS notes that software-as-a-service products require minimal upfront investment, which makes them accessible to small businesses, and that the provider handles security and maintenance (ELEKS).

Buying has costs of its own. ELEKS lists the main ones: limited control, dependence on the provider for uptime and fixes, updates pushed to everyone at once that can break your processes, and lock-in once your data is stored in the vendor's formats (ELEKS). HP's framework adds dependence on the vendor's roadmap and priorities (HP).

Build when the capability is your advantage. HatchWorks advises building when the capability drives revenue, margin, speed or differentiation, and asks two pointed questions: would competitors be fine buying the same thing, and do you have unique data or a feedback loop that improves results over time (HatchWorks AI). If a competitor could buy the same tool tomorrow and get the same result, building it yourself creates no advantage.

KPMG's interviewees make the same point from the vendor side. One partner advises that if something differentiates you, you probably want to own that intellectual property; another notes that a feature a vendor builds for you may be exclusive for a while, but after that everyone in the industry has it (KPMG).

Good candidates for a small company to build or assemble usually involve its own records: years of job estimates, a library of past proposals, a particular way of scheduling crews, or customer data no vendor has. The AI model itself is almost always bought or rented; what you build is the logic, data and workflow around it.

Be ready for what building demands. KPMG notes that building requires a culture prepared for trial and error, because success may not be immediate, and an investment in people, processes, data and infrastructure (KPMG). If nobody in the company will own the system after it is built, do not build it.

Both paths cost more than their headline price. Pertama Partners' guide to AI total cost of ownership argues that license fees are only a minority of the true cost of most AI implementations, with hidden costs clustering in five areas: integration, training, change management, ongoing operations, and eventual exit (Pertama Partners). It also warns that vendors price in different ways, per seat, per transaction or by consumption, so comparisons only make sense when normalized to your actual usage.

Building has its own hidden costs. ELEKS points out that the owner of custom software is responsible for updates, bug fixes, security patches and optimization, which require dedicated technical resources (ELEKS). For AI specifically, HatchWorks adds model updates, evaluation and governance to that list (HatchWorks AI).

Usage costs need special care. Cohere notes that one answer on screen may represent a chain of model calls, document searches, tool uses and checks, so costs can grow faster than usage appears to (Cohere). Estimate costs at your expected volume, then at double it.

Every AI decision should include a way out. Pertama describes the switching cost trap: organizations locked into vendors with proprietary data formats or custom integrations face substantial migration costs, and understanding exit costs before entry prevents future constraints (Pertama Partners).

Dependence also has a strategic side. Cohere argues that a capability you neither own nor govern is effectively rented, and that a rented capability can be repriced, rate-limited, deprecated or restricted by another company (Cohere). That is true whether you buy a finished tool or build on someone else's model.

Practical protections for a small company:

• Keep your knowledge in your own files. Write help articles, policies and instructions in documents you own, then load them into tools, rather than authoring them only inside a vendor's editor.
• Check data export before you sign. Confirm you can export conversations, records and settings in a standard format.
• Avoid single-model dependence where it is cheap to do so. Tools that can switch between models, or that reach several models through one gateway, reduce the impact of a price change or a retired model.
• Read the change terms. Find out how much notice the vendor gives before changing prices, features or data terms.
• Document what you build. A custom tool that only its builder understands becomes a liability the day that person leaves.

HatchWorks offers eight questions, asked in order, to route the decision (HatchWorks AI):

1. Is this tied to revenue, retention, margin or strategic speed?
2. Would competitors be fine buying the same thing?
3. Do you have unique data or a feedback loop that improves outcomes over time?
4. Is the domain compliance-heavy and full of edge cases?
5. Are the integrations standard, or specific to your setup?
6. Can you define "good" clearly enough to test and monitor it?
7. Do you have the capacity to run AI safely, with checks, monitoring and a plan for incidents?
8. Can you prove the trade-offs in two weeks with a real slice of work?

For a small company, a rough rule follows. If questions 2 and 3 point to "nothing special about us", buy or configure. If questions 4 and 7 raise doubts, buy. Build or assemble only when the answers to 1, 2 and 3 show a real advantage and you can answer 6 and 7 with confidence.

Then test before committing. HatchWorks recommends a time-boxed proof covering one real workflow slice, one hard integration and one measurable outcome (HatchWorks AI). For a bought tool, that means a trial on your own data with your own staff. For a build, it means a working slice on real records, with an honest estimate of what it would take to run for a year. Whichever path wins, write down why, so the decision can be revisited when the tools or the business change.