Do not argue they cannot build it. Walk them through their own test: does a product fit, does it touch customer data, payments or certification, who maintains it, is it what makes them different. The library's own move.
"Our engineers can build this with AI in a few weeks." The deal was at the final stage, and now it is a build-or-buy question inside their company, with you outside it.
Do not argue that they cannot build it. For some tools they can. Walk them through their own build-or-buy test instead. Is there a product that already fits? Does the tool touch customer data or payments, or need a security certification such as SOC 2? Who will maintain it after launch, and what will that cost over three years, including the day its builder leaves? Is this the part of their business that makes them different, or plumbing? Offer to help them scope the build honestly, including the parts they would still buy.
No seller publishes this move. It is the library's own, using the test that one of the loudest advocates of building publishes for buyers.
Jason Lemkin's rule for when to build, from SaaStr in March 2026. Lemkin, who has replaced paid tools with apps he built with AI coding tools, still follows a rule of buying 90% of what you need and building only the 10% no product covers. Build, he says, when no product does the job, when the tool you pay for has fallen so far behind that it hurts the business, or when speed matters more than polish. Buy when well-funded companies do it full time: "You are not going to out-build HubSpot's CRM in a weekend." And buy when the tool touches customer data, handles payments or needs SOC 2. His warning to himself: "Every app you build is an app you now have to maintain."
What it looks like from the vendor's side. Lemkin describes building his own marketing and customer success tools, which cost two vendors about $20,000 a year each in business they never got. "Those vendors will never know we existed," he writes, because a deal that never closes never shows up in anyone's churn data.
Nobody has tested the move. No study compares sellers who walked a buyer through their own build test with sellers who argued against building.
The stall is common and growing. McKinsey's survey of 1,719 people in 97 countries, published in August 2026, found that 32% said their organisation had decided against buying at least one software product or feature because it could build it with AI coding tools. Gong's trend data, from 33.5 million deals since February 2024, shows deals where a buyer mentions building internal AI systems to replace third-party software up by 45%. McKinsey sells AI consulting, and Gong sells the software that tracks the mentions.
When enterprises actually decide, most buy. Menlo Ventures surveyed 495 US enterprise AI decision makers in November 2025. They bought 76% of their AI use cases rather than building them, up from 53% a year earlier. Menlo's explanation is that ready-made products reached production faster. Menlo also reports that 47% of AI deals reached production, against 25% for traditional software. Menlo invests in AI companies that sell to these buyers.
People overvalue what they build themselves. Michael Norton, Daniel Mochon and Dan Ariely found in four studies that people who assembled a storage box, folded origami or built Lego valued their own work far above what others would pay, and saw their amateur results as close to an expert's. The effect disappeared when they failed to finish. It was measured on finished things, so it speaks to how a team will value its tool once built, not to the plan.
People underestimate how long it will take. Roger Buehler, Dale Griffin and Michael Ross asked 37 students, published in 1994, how long their final-year thesis would take. They predicted about 34 days on average and took about 56, longer even than their own worst-case guess of about 49. Only about 30% finished by the date they had predicted.
The survey figures describe what companies did or said, not what a seller's questions change. The overvaluation and planning studies used students and consumers building small things, not engineering teams building software. And Lemkin's own experience cuts both ways: he did replace two vendors.
Do not argue that they cannot build it. Walk them through their own test: does a product fit, does it touch customer data, payments or certification, who maintains it for three years, and is it the part that makes them different. Where the answer really is build, let that part go and sell the rest. When enterprises decided in 2025, most bought, and the research says people overvalue what they have built and underestimate how long building takes.