The founder has read something online about a startup that built an internal AI tool over a long weekend. Now “we could just build this ourselves” is a live idea in your leadership meetings, and you have been handed the mandate to work out which path makes sense. This is one of the first substantive decisions in your AI role, and getting it wrong is expensive in ways that take months to surface.
What’s the choice you’re actually being asked to make?
Buy means licensing an existing AI product, configuring it for your workflows, and paying a vendor for the ongoing service. Build means commissioning custom AI development, typically via APIs, models, or proprietary data pipelines, either with hired engineers or an agency. For an owner-managed business without a dedicated engineering team, the practical gap between those two options is wider than it first appears.
Vendor-led AI projects succeed roughly 67% of the time against 33% for internal builds in businesses at this scale, based on MIT-sourced research. That gap does not reflect a difference in ambition. It reflects a difference in what each path actually demands. A bought solution carries vendor infrastructure, compliance handling, support, and pre-built integrations. A built solution requires you to provide all of those yourself, on top of finding, briefing, managing, and retaining engineers who can do the work.
The integration challenge is real on the buy side too. Buying AI is not switching on a service and walking away. Someone still has to connect the tool to your systems, migrate relevant data, and get the team using it properly. But that is a configuration project. A failed build is a failed software project, and those two categories are not comparable in cost, complexity, or recovery time.
When does buying AI off the shelf make sense?
Buying makes sense when a vendor has already solved the problem you are facing, when you need to show progress in weeks rather than months, and when your team does not have the technical depth to specify and manage a build. For the functions where AI pays back fastest in an owner-managed business, the vendor market is well-developed and the tools have been tested in comparable contexts.
The back-office is where AI delivers the strongest returns for businesses at this scale. Document processing, meeting transcription, scheduling automation, finance reconciliation, customer query handling. These are the functions where mature vendor tools exist, where the ROI is well-documented, and where the integration work, while genuine, is a configuration project rather than a software development project. McKinsey’s research on AI in the workplace consistently identifies back-office automation as the area delivering the clearest near-term returns.
Buying also makes sense when exit readiness is the founder’s real objective. A business running proven, documented AI tooling is materially easier to value in due diligence than one sitting on a custom-built system that depends on tribal knowledge to operate. BCG’s 2025 research documented the persistent gap between AI usage and measurable business impact; the organisations narrowing that gap most effectively are those deploying vendor tools in defined operational workflows rather than building general-purpose capability.
The IP ownership conversation is worth having directly. Founders often resist buying because they want to own what they build, but a vendor contract does not prevent you from owning the data the tool processes, the workflows you design around it, or the institutional knowledge your team develops using it. Licensing a capability is not the same as surrendering a strategic asset.
When does building AI in-house actually work?
Building works when the AI requirement is genuinely novel, your data is proprietary and competitively sensitive, and you have the engineering capability to see it through. That combination exists in some businesses but it is not the default. The minimum viable build requires, at minimum, an engineer who understands machine learning, a data engineer, and someone who can translate business requirements into a buildable technical specification.
The honest test is simple. Can you name the engineers who will build it, describe what they will build, and explain how you will maintain it once it is live? If any of those answers are vague, the build path is not actually on the table yet, whatever the founder’s enthusiasm level.
Build is defensible when the problem is core IP. A law firm with a proprietary case database, a manufacturer with granular production data, a logistics operator with unique routing intelligence built over decades. In those cases, handing that data to a vendor carries genuine strategic risk, and a custom system is worth the added complexity and cost.
A data quality warning applies to both paths but hits harder on the build side. Poor data quality is cited by 77% of firms as the biggest barrier to responsible AI use, based on Gartner research. A build project that runs into data problems mid-delivery is far more expensive to recover from than a vendor contract that requires you to clean your data before onboarding begins.
What does getting this wrong cost you?
A failed build in an owner-managed business without a permanent engineering team typically runs for 12 to 18 months before anyone agrees it has not worked. A failed vendor contract is faster to diagnose and cheaper to exit. The difference matters when you have been given an AI mandate and the board is watching how you spend it.
The harder cost is to your credibility with the people who granted you the mandate. Korn Ferry’s research on AI leadership identifies a consistent pattern. Businesses assign AI mandates to strong operators who lack the AI-specific competencies the task requires. The gap between expectation and delivery lands on the delegate, regardless of where the original decision went wrong.
The ROI timeline sharpens the exposure. Meaningful financial returns from AI typically take 12 to 24 months to show up in the numbers. A build project that stalls at month six has consumed budget and management attention with nothing auditable to show for it. A vendor contract, even one that under-delivered, can at least be documented and learned from.
EY’s research on board AI governance expectations finds that boards increasingly want structured risk management alongside implementation. A failed build with no documented decision process is a harder conversation than a vendor contract that missed its targets with a paper trail behind it.
What should you ask before you commit either way?
Before you sign a vendor contract or commission a build, five questions are worth resolving. What specific business outcome are you targeting? Who owns the data this system depends on, and is it clean? Do you have the internal skills to configure, adopt, and maintain whatever you choose? What does success look like in 90 days? And what is the exit path if you need to change course?
For vendor selection, the useful question is not “which tool is best?” It is “which vendor has already solved this specific problem for a business like ours?” Ask for references from businesses of comparable scale and sector. Ask what the data requirements are before the tool goes live, not after contract signature. Ask who owns the integration work and what the exit looks like if you need to leave in 12 months.
If you are leaning towards build, one additional question is worth asking first. Who specifies this? Translating a founder’s vision into a buildable technical specification is a discipline in its own right. Without someone who can bridge that gap credibly, a build project starts on uncertain ground regardless of the engineering resource behind it.
The research points clearly towards buying for the majority of owner-managed businesses at this scale. Custom development is justified when the data is genuinely proprietary and competitively sensitive, and you have the engineering capacity to build well. If you cannot tick all three conditions, the more effective path is choosing the right vendor, managing the integration with discipline, and measuring against clear KPIs from day one. That is the AI leadership work. The build conversation can wait until the business has earned the capability to do it properly.
