Every enterprise AI programme reaches the same meeting. A business unit has a problem, a vendor has a demo, an internal team has a proposal, and someone has to decide whether to build the capability, buy it or find some arrangement in between. The build vs buy AI enterprise decision is usually argued on instinct: engineers want to build, finance wants to buy, and the chief information officer wants whichever carries less blame if it fails.
The evidence favours buying, at least for speed. EY India's survey of over 200 Indian enterprise leaders, published in November 2025, found that 91 per cent rank speed of deployment as the top factor in buy-versus-build decisions. Menlo Ventures' State of Generative AI in the Enterprise 2025 found that 76 per cent of enterprise AI deals are buy rather than build. The MIT NANDA interview sample reported that customised tools built through external partnerships reached deployment about 67 per cent of the time against about 33 per cent for internal builds, a correlation its authors were careful not to call causal. McKinsey's CIO and CTO guide to generative AI, published in July 2023, describes the "maker" path of building foundation models as costing "tens or even hundreds of millions of dollars", which removes it from the menu for nearly every Indian enterprise.
But "buy" and "build" are not the only two options, and treating them as such produces bad decisions in exactly the cases that matter most: workflows that are core to the business, specific to it, and not served by any vendor's product. For those, a third path exists, in which the enterprise co-builds a capability with an external builder who takes ownership of the product, carries it to other customers and leaves the enterprise with a licence and, sometimes, a stake. This article sets out an economic framework for the three options, states the cost, control, time and ownership variables on which they differ, and gives the conditions under which each wins.
Why the build vs buy AI enterprise binary fails
McKinsey's 2023 guide offered a useful three-way classification of enterprise posture towards generative AI: takers use public models through a chat interface or API with little or no customisation; shapers integrate models with internal data and systems to generate more customised results; makers build foundation models for a discrete business case. The classification is about model customisation rather than sourcing, but it maps onto the sourcing question. Takers buy. Makers build, at a cost McKinsey put in the tens to hundreds of millions of dollars. Almost every enterprise decision of consequence sits in the shaper zone, and it is in the shaper zone that the binary breaks down.
A shaper needs a model (bought, as an API or an open-weight download), integration with internal systems (built, because no vendor knows the enterprise's systems), a workflow around the model (designed, by someone who knows the business), an exception path (staffed), and ongoing maintenance as data and regulations change (owned by someone with a budget). "Buy" in this zone means buying a vendor's opinion about the workflow and accepting the integration work anyway. "Build" means hiring and retaining a team to do all five, then keeping it funded after the initial excitement, which is where internal builds fail. The MIT NANDA 33 per cent is not a statement about engineering ability. It is a statement about what happens to an internal project when its champion moves on.
The missing option is the one in which the enterprise contributes the problem, the data and the first contract, an external builder contributes the team, the method and the commitment to turn the result into a product, and the two share the outcome. This is the co-build. It is familiar in corporate venture building, which McKinsey's fifth annual survey on the subject, with 1,176 senior respondents in mid-2024, found to be a top-three priority for about half of CEOs, with about two-thirds expecting to build new ventures in the coming year. The survey found that experienced builders are about twice as likely as novices to meet or exceed expectations, more than three times likelier to use an established framework and process, and twice as likely to give new ventures a high degree of decision-making independence from the core business. A separate PanScience Research piece in the venture-studio cluster covers the co-build model and the terms that keep the resulting venture independent; this article treats co-build as one of three sourcing options and asks when its economics win.
The Build-Buy-Co-build decision matrix
The matrix below compares the three options on the four variables that determine the economic outcome: cost (its shape over time, not only its size), control (over roadmap, data and workflow), time (to first production value and to a mature product), and ownership (of the intellectual property and the upside). The characterisations are the author's framework, informed by the sources cited; the time ranges are indicative judgements, not survey results.
The cost shapes, stated
The most common error in build-versus-buy analysis is to compare a build's total cost with a buy's annual cost. The right comparison is between cost curves over a planning horizon, and the three options have characteristically different shapes.
A build has a step up at the start and a flat line thereafter. The step is the team: in India, a credible applied-AI team of a lead, two or three engineers and a product owner costs on the order of ₹1 crore to ₹2.5 crore a year in fully loaded salaries, before infrastructure, and that cost is incurred whether the system serves a thousand transactions a day or a million. The flat line is the problem: the team must be retained through years two and three, when the system is in maintenance and the organisation's attention has moved, or the system decays. A separate PanScience Research piece in this cluster models the on-premise inference cost component of this curve in detail.
A buy has no step and a slope. The slope is the per-seat or per-token price, and it rises with use. At low volumes a buy is cheaper than any build; at high volumes the embedded vendor margin becomes visible, and the enterprise finds itself paying for the vendor's other customers' development. McKinsey's State of AI 2025 finding that nearly half of respondents from companies over $5 billion in revenue have reached the scaling phase, against 29 per cent of those under $100 million, is consistent with the observation that larger enterprises hit the volume at which building, or at least owning, becomes rational.
A co-build has a smaller step and a gentler slope, because the fixed cost is shared with a party who expects to recover its share from later customers. Its distinctive feature is that the fixed cost of generalisation, documentation, support and security hardening, which the enterprise never budgets in a build and the vendor has already paid in a buy, is carried by the builder as the price of owning a product. The enterprise pays more than it would for a pilot and less than for a build, and receives in exchange a product that will be maintained because someone else's revenue depends on it.
Control and ownership: the trade the enterprise must make consciously
The variable on which enterprises most often deceive themselves is control. A build offers full control of roadmap and data, and this is the usual argument for it. The argument is correct and incomplete. Full control is worth having only if the enterprise will exercise it, which requires a product owner with authority and a team with capacity, in year three as well as year one. Few enterprises outside technology and financial services sustain this. The McKinsey venture-building survey's finding that experienced builders give ventures independence twice as often as novices is the mirror image: the organisations best at building new things are the ones that most willingly give up control over them.
A buy offers the least control, and the loss is often underestimated. The roadmap belongs to the vendor's largest customers, who are not in India, and the data posture depends on whether the vendor offers a deployment that meets the enterprise's regulatory obligations. For a bank under RBI's localisation requirements or a significant data fiduciary under the DPDP Rules, an API-only vendor may be unusable regardless of price.
A co-build sits between, and its ownership structure is the part that must be negotiated carefully. The builder owns the product IP, because without that it cannot sell to a second customer and therefore cannot fund the generalisation the enterprise wants. The enterprise receives a perpetual licence, retains ownership of its data, and may receive a minority stake in the venture. What the enterprise gives up is the right to prevent the builder selling to a competitor after an exclusivity window. What it gains is a product that improves on other people's money. The terms that make this work, licence-back, time-limited exclusivity, data rights and minority equity rather than control, are covered in the separate venture-studio piece. The economic point here is that the trade is favourable whenever the enterprise would not, in practice, have exercised the control it is giving up.
When each option wins
The matrix compresses to four questions.
Is the problem common across the industry? If yes, a vendor has probably already paid the generalisation cost, and buying is the right answer; EY's 91 per cent speed preference is rational here. Customer-service deflection, document summarisation, code assistance and standard compliance checks are largely in this category.
Is the capability a durable competitive advantage that the enterprise will fund indefinitely? If yes, build, and treat the team as a permanent cost centre rather than a project. Proprietary trading models, recommendation engines at consumer scale and core underwriting models are examples. The test is not whether the enterprise can build it but whether it will still be paying for the team in year four.
Is the problem specific, core and unserved, and does the enterprise not want to run a software company? If yes, co- build. Indian examples are often sector-specific workflows where the regulatory or operational detail is local: compliance mapping against Indian regulators, plant-floor integration with equipment of mixed vintage, clinical records on India's ABDM rails, court registry workflows. PanScience's practice reflects this: its ventures in BFSI compliance (OnFinance AI), industrial AI (PredCo) and judicial workflow (Nyaay AI) are, by the company's own description, built around enterprise and institutional problems in regulated or operationally specific domains, where a global vendor's product would need to be rebuilt locally in any case. These are company-reported descriptions of the venture model, not claims about specific engagements.
Is the volume high enough that the vendor margin matters, but the capability is not strategic? This is the hardest case. The answer is usually to buy the model as an API or open-weight download and build only the thin integration layer, which is McKinsey's shaper posture with a minimal internal team. The separate on-premise economics piece in this cluster gives the volume thresholds.
Common errors, and the signals that precede them
Three errors recur in Indian enterprise decisions on this question.
The first is building because the engineers can. Technical capacity is necessary and not sufficient; the sufficient condition is a funded owner in year three. The signal is a proposal with a build budget and no maintenance budget.
The second is buying a product and then rebuilding it. The enterprise selects a vendor for speed, discovers the workflow fit is approximate, commissions a services firm to customise it, and ends up with a build's cost and a buy's control. The signal is a customisation budget exceeding the licence budget in the first year.
The third is treating a co-build as a discounted services engagement. The enterprise negotiates to own the IP, insists on open-ended exclusivity and pays by the deliverable, and the builder, unable to sell to anyone else, becomes a captive supplier and loses interest when the enterprise's budget cycle turns. The signal is a co-build contract that reads like a statement of work.
Conclusion
The build vs buy AI enterprise question is a false binary for the decisions that matter. Buying wins for common problems with mature products, and the speed preference Indian leaders express is sound there. Building wins for durable advantages the enterprise will fund as a permanent cost centre, and the honest test is the year-four budget. Between them sits a large class of problems that are specific, core and unserved, where the economics favour a co- build: the enterprise pays more than a pilot and less than a build, gives up control it would not have exercised, and receives a product that someone else is paid to keep improving. The decision should be made on cost shape, control actually exercised, time to maintained product and ownership of upside, and it should be made before the vendor demo, not after it.
Methodology and sources
This article presents an analytical framework. The Build-Buy-Co-build decision matrix, the four decision questions and the three common errors are the author's own; the time ranges in the matrix and the Indian team-cost range are indicative judgements, labelled as such, not survey findings. PanScience venture descriptions are company-reported from panscience.xyz and no client of any venture is named.
Observed figures come from: EY India, The AIdea of India: Outlook 2026, survey findings, 16 November 2025 (https://www.ey.com/en_in/insights/ai/agentic-ai-india/aidea-survey-findings), 91 per cent ranking speed of deployment first among buy-versus-build factors. McKinsey, Technology's generational moment with generative AI: a CIO and CTO guide, 11 July 2023 (https://www.mckinsey.com/capabilities/mckinsey-digital/our- insights/technologys-generational-moment-with-generative-ai-a-cio-and-cto-guide), taker, shaper and maker definitions and the cost of building foundation models. McKinsey, How CEOs are turning corporate venture building into outsize growth, 22 October 2024 (https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/how- ceos-are-turning-corporate-venture-building-into-outsize-growth), 1,176 respondents fielded 21 May to 2 July 2024. McKinsey, The state of AI in 2025 (https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-state-of-ai- 2025), scaling by company size. MIT NANDA, The GenAI Divide, external-partnership and internal-build deployment rates as reported by Let's Data Science (https://letsdatascience.com/news/mit-report-documents-genai- pilot-roi-gap-e0924d7d), with the authors' caution that the correlation is not causal. Menlo Ventures, State of Generative AI in the Enterprise 2025, 9 December 2025, 76 per cent buy versus build; DPDP Rules notified 14 November 2025; RBI payment-data localisation circular of 6 April 2018: as held in the PanScience Research editorial register.