Build or Buy: How to Decide on Your AI

Build or buy

Most SMB and mid-market company leaders have moved past the question of whether to use artificial intelligence. By late 2025, 55% of French SMBs and mid-market companies were using generative AI, up from 31% a year earlier. The real decision has changed in nature: it is no longer about the principle, but about how to obtain the capability. Two paths are open. Buy a solution the market has already built — a subscription, a tool integrated into existing software, a ready-to-use platform. Or build a custom system, tailored to the company's own data and processes.

This Reference lays out the trade-off as it presents itself to a general management team: what each path actually delivers, what it costs beyond the sticker price, and how to decide without miscalculating. The conclusion, stated upfront, fits in one sentence: most SMBs and mid-market companies should buy and integrate; a custom build is justified only where the company holds its own advantage worth protecting.

Adoption is progressing, but it remains highly uneven by company size. In 2024, 33% of French companies with 250 or more employees reported using at least one AI technology, compared with 15% for those with 50-249 employees and just 9% for those with 10-49. The gap is not a matter of conviction: it comes down to resources, in-house expertise, and the capacity to take on a technical project. This is precisely where the build-or-buy choice becomes decisive.

What buying delivers

Buying means acquiring a capability that others have already proven. The vendor has borne the cost of research, model training, updates, and security; the company pays a subscription and gets a tool that works from the moment it is installed. For a common function — customer service, writing, document research, office productivity — the market offers mature products that cover the need without writing a single line of code.

The first advantage is speed. Where an in-house build is measured in quarters, adopting a market tool is measured in weeks. A writing or proposal-generation capability can go live in six to ten weeks; a contract-analysis tool or research assistant, in eight to fourteen weeks. Value arrives before the annual budget is spent.

The second advantage is shared risk. A vendor serving thousands of customers fixes defects, absorbs model updates, and carries compliance. The company does not need to hire machine learning engineers or maintain infrastructure. The gains observed from market-tool deployments are concrete and repeated across sectors.

The third advantage is shared improvement. An AI-enhanced office tool saves time without a dedicated project. The UK's cross-government Microsoft 365 Copilot trial, involving 20,000 public sector employees, measured 26 minutes saved per user per day — roughly two weeks a year; 82% of users did not want to go back to previous conditions. At BBVA, the rollout of 11,000 licenses for a market assistant saved users nearly three hours per week.

Still, buying has a structural limit: whatever the company gets, its competitors get too. A market tool makes the organization more efficient, but rarely different. This limit does not matter on a support function; it matters a great deal once you touch the core of the business. That is the other side of the trade-off.

What custom development costs

Building means funding an asset of your own: a system trained on the company's data, wired into its processes, carrying know-how that no one else holds. The ambition is legitimate, and sometimes it pays off. But the real price does not show up on an invoice; it unfolds over time, and it is almost always underestimated.

The first cost is time. A shared AI platform foundation, or a forecasting model trained on proprietary data, takes twenty-six to fifty-two weeks to produce value — six months to a year during which the company spends without earning. The second cost is human: custom development requires rare skills. The fully loaded annual cost of a qualified profile exceeds €60,000, and that person needs to stay on to maintain what they built.

The third cost, the most insidious, is upkeep. A custom system is never finished. Models evolve, data drifts, usage patterns change; what worked a year ago requires ongoing maintenance. A market solution's vendor absorbs this work for all its customers at once. Whoever builds it carries it alone, indefinitely. That is the difference between renting a capability and owning one — upkeep included.

This does not rule out building. It requires doing so for the right reason. Custom development is justified when it turns into value an asset the company alone possesses — production data accumulated over years, rare domain expertise, a process that sets it apart in the market. There, and only there, does the expense become an investment rather than a cost.

The real trade-off

Placed side by side, buying and building do not differ on a single dimension but on four: cost, timeline, risk, and control. Each path leans one way. The mistake would be to look at only one — the sticker price — and ignore the other three.

Indicative timelines: going live with a market tool (writing, contract analysis) versus building a platform foundation or a proprietary model. Timeline source: YPrtnrs Institute use-case library, based on observed times to value (proven and emerging).

Buying means renting a proven capability. Building means funding an asset — and its upkeep.

Reading this table points to a default winner. On three dimensions — cost, timeline, risk — buying wins clearly. Custom development only regains the advantage on the fourth, control. In other words: building only makes sense if control alone is worth more than the added cost, timeline, and risk combined. That happens only at the core of the business.

Time to value by path chosen. The further one moves from pure buying toward custom building, the longer the horizon stretches — and the less discounted future value weighs against immediate cost. Source: YPrtnrs Institute use-case library.

How to decide

The trade-off does not play out at the level of the whole company but use case by use case. The same organization might buy for its customer service and, potentially, build for its industrial core. The right question is not "do we build or buy?" but "does this specific need address a generic problem or a distinct advantage?" Five criteria are enough to decide.

1. Is the need generic? If other companies have exactly the same problem — responding to customer requests, writing, summarizing — the market already solves it. Buy.
2. Does it rest on an asset only you hold? Production data, rare expertise, a differentiating process no vendor can supply? Then, and only then, consider building.
3. What horizon is acceptable? If value is expected within a quarter, buying is the only viable path; a six-to-twelve-month timeline only makes sense for a strategic stake.
4. Do you have the skills to maintain it? Building without a team able to maintain the system means funding technical debt. Without dedicated engineers, buy.
5. Does the stake justify taking on the risk alone? On a support function, no: the vendor's shared risk is enough. At the core of the business, where differentiation is at stake, control can be worth the risk.

For the large majority of SMBs and mid-market companies, this framework leads to the same answer: buy and integrate. Not out of excessive caution, but because few needs meet all five conditions for custom development. The potential of generative AI, estimated by McKinsey at $3.5 trillion a year, is concentrated in cross-functional areas — customer service, marketing and sales, software engineering, R&D — where market tools are already mature.

The false calculation

The most common mistake is not choosing the wrong path. It is comparing the two options using the wrong number. The price of a subscription is pitted against the cost of development; once amortized, development "comes out cheaper," and the decision is made to build. The calculation is wrong from the start: it compares a full cost, the vendor's, to a partial cost, that of development alone.

The false calculation has a second part: it assumes the built system will actually work. Yet many custom projects never move past the pilot stage, and those that succeed do not always deliver on their quality promises. Generative AI produces fast but fallible first drafts: law firm Ashurst, across 411 participants in 14 countries, measured up to 80% time saved on certain documents, but average accuracy below that of humans (3 out of 5 versus 3.5). Performance itself is unstable: in an experiment involving 758 consultants, AI improved speed by 25% and quality by 40% on tasks within its reach, but degraded results by 19% on tasks beyond it.

The rule running through this Reference comes down simply. For a generic need, buy: it quickly delivers a proven capability, with shared risk and pooled cost. For a distinct advantage, consider building — provided you pay the full price, upkeep and oversight included, and have the skills to sustain it. Between the two, the safest path remains buying a solid building block and combining it with what makes the company distinctive. The question was never "build or buy"; it has always been "where does the advantage worth protecting lie, for us."