Build vs Buy in 2026: Why Presales Teams Keep Building Their Own Tools

In the last month, four presales leaders told me they built their own version of the software I sell. Not evaluated. Built.

One wrote it in Salesforce. One used Claude. One has an engineer maintaining it. One is still deciding whether to keep going.

I am not offended, because I did exactly the same thing. When I ran presales at a SaaS company, I could not get budget to buy anything, so I built my own engagement tracker. My team logged roughly 2,000 hours in it over six months. That tool is the reason PresalesIQ exists.

So this is not an argument that building is wrong. It is an account of where every one of those builds stopped, including mine.

The numbers say this is not anecdotal

McKinsey’s 2026 State of AI survey covered 1,719 business leaders across 97 nations. Thirty-two percent said their organization decided against buying at least one software product or feature because agentic coding tools made an internal version viable. Among technology companies specifically, it is 41%.

Retool’s 2026 Build vs. Buy report found 35% of teams have already replaced at least one SaaS tool with a custom build, and 78% expect to build more this year. Sixty percent said they had built software outside IT oversight in the past year.

The build versus buy question, settled for most of the past decade in favor of buying, is open again.

Why presales builds more than most functions

Presales leaders have a specific combination of conditions that makes building almost inevitable.

They rarely control budget. A Director or VP of Solutions typically has to request tooling spend rather than approve it, and that request competes against headcount.

They are technical enough to build. This is a function staffed by people who demo software for a living. Asking one of them to wire up an API is not a stretch.

And they cannot get changes made to the systems they already have. One leader told me he asked his RevOps team for a couple of Salesforce fields two years ago and still does not have them. When the official path takes two years and the unofficial path takes a weekend, people take the weekend.

Where every build stops

Across those four conversations and my own, the same boundary shows up.

Activity capture works. Pulling calendar events and opportunity data into a dashboard is genuinely achievable now. Every person I spoke to got this far.

Retrospective reporting works. You can build something that tells you what happened last month. Several of them did.

Discovery consistency does not. One leader described it as still aspirational after building everything else. Structuring discovery so that eight people document a deal the same way requires a data model, not a query. That is where the weekend project becomes a product.

Capacity forecasting does not. One leader built capacity planning and found it only worked at the opportunity level, because that is all Salesforce exposes. The hundred things that happen outside the CRM, the demo prep, the POC standups, the RFP response, never make it in. Which means the capacity picture is wrong in exactly the way that matters.

Nobody owns it at month six. An internal tool built in a sprint by a coding agent often has no one assigned to it six months later. Most internal tools hit re-architecture pressure within five to seven years, and AI has not changed that. It has only compressed how fast you get to version one.

The honest case for building

If your process is genuinely unusual, building may be correct. Vendors optimize for the common case, and if your motion is not the common case, you will fight the tool.

If you are small, building can work as scaffolding. Under roughly 150 people, governance burden is lower and a leader can hold most of the picture in their head anyway.

And if you cannot get budget, a build is better than nothing. I know this firsthand.

The distinction that matters is whether you are building scaffolding or foundation. Scaffolding is fine. Foundation requires an owner, a roadmap, and someone to answer the phone when it breaks during a quarter-end deal.

The honest case for buying

MIT NANDA research suggests internally built systems succeed about a third of the time, compared with roughly two thirds for vendor-purchased tools. Gartner predicts more than 40% of agentic AI projects will be canceled before the end of 2027, driven by escalating costs, unclear business value, and inadequate risk controls.

The gap between shipping and sustaining is where internal builds die. Only 17% of organizations have actually deployed AI agents, and Deloitte puts production-ready agentic systems at 11%. Plenty of things get built. Far fewer get run.

There is also a cost visibility problem that cuts against building. A SaaS bill shows up in the expense feed and the renewal calendar where someone can question it. An internal tool’s cost shows up as an engineer’s time, which nobody tracks and everybody absorbs.

How to actually decide

Three questions get you most of the way.

Who owns this in twelve months, by name? If you cannot answer, you are building scaffolding. Build it anyway if you need it, but do not plan around it.

Does this need a data model or a dashboard? Dashboards are weekend projects. Data models are products. Discovery structure, capacity forecasting, and product gap quantification all need data models.

What happens when the person who built it leaves? This is the question that ends most of these conversations, and it is the one nobody asks up front.

Frequently asked questions

Is it cheaper to build internal tools with AI? Version one is dramatically cheaper. Total cost of ownership often is not, because maintenance, integration work, and the eventual re-architecture do not get counted in the initial business case.

Why do so many presales teams build their own tools? Three reasons together: the buyer rarely controls budget, the team is technical enough to build, and changes to existing systems like the CRM are slow to get approved.

What should presales teams build versus buy? Build reporting and lightweight capture where your process is genuinely unusual. Buy where you need a durable data model, multi-person consistency, or something that has to survive turnover.

Does AI change the build versus buy calculation? It changes how fast you reach version one. It does not change what it costs to own software over five years.

If you built it yourself, I would like to hear about it

Specifically: what worked, where you stopped, and whether you would do it again. I have four data points and my own. I would like more.