AI made writing code cheap. It did not make running software cheap — and that gap is where SEs win or lose the build-or-buy conversation.
TL;DR
- Build-or-buy objections are back. One SE hears them in roughly half of her opportunities.
- The first version was never the expensive part. Maintaining, securing, integrating and operating software for years is — the iceberg under every weekend prototype.
- Discover, don't defend. Acknowledge, Explore, Reframe, Commit lets buyers find the hidden costs themselves.
- Core vs. context decides most cases. Building makes sense close to a company's core value creation. For commodity tools it rarely does.
- Sometimes build wins. Let it go.
"We've licensed Claude Code. We'll build this ourselves in two quarters."
That's the sentence a CTO drops on the table, and SEs are hearing it more often. At Demo Fest in London, an SE told Tim Brömme she gets a build-or-buy objection in about 50% of her opportunities. When we asked the leaders in our PreSales Leader Community, the picture looked similar.
Most SEs react the way they were trained to: features, enterprise readiness, maybe a slide listing everything the customer forgot. Understandable. Almost always wrong. Below: what has actually changed, the hidden-cost iceberg behind every vibe-coded prototype, and a four-step dialogue for handling the objection without turning your buyer into an opponent — plus how to tell when building really is the better answer.
Why is build vs. buy suddenly back on the table?
Because AI has flipped the economics that settled the question forty years ago. In the 1950s and 60s, IBM sold hardware and software as one bundle, a machine cost around two million dollars, and customers wrote their own software for a fraction of that.
Then Informatics' Mark IV became the first software product to pass one million dollars in annual revenue, and the first that had to talk customers out of building. On June 23, 1969, under antitrust pressure, IBM started billing hardware and software separately.
From there the pendulum swung toward buy. Hardware got cheaper, so a quarter-million-dollar custom build no longer made sense next to a $50,000 office machine. By the mid-80s, Fred Brooks argued that the most radical way to construct software is not to construct it at all. Y2K pushed the stragglers into standard ERP, and from 2000 Salesforce's "No Software" pitch moved applications, maintenance and buying decisions out of IT and into the cloud and the business.
Now writing code has become extremely cheap again, so the calculus swings back. Or seems to. In McKinsey's State of AI 2026 survey, roughly a third of respondents say they skipped buying at least one software product or feature because they could build it with AI coding tools. Meanwhile, Tim points out, SaaS spending still grows at about 8% a year. Both are true at once. We feel it ourselves: Tim and Jan-Erik regularly ask whether they really need a tool like Notion, of which they use a fraction, or whether a small app in their own Google Cloud would do.
Does AI coding really make building software cheap?
It makes the first version cheap. That was never the expensive part.
Even the speed story is messier than the hype. In an early-2025 randomized trial by METR, a Berkeley research nonprofit, experienced open-source developers felt about 20% faster with AI tools — and were actually 19% slower. Small sample, older models — take it with a pinch of salt. Jan-Erik's read: developers using AI ship more (documentation, small bug fixes), which raises quality but eats the time saved.
The bigger problem starts after go-live. Tim's example: Anthropic released Claude 3.7 Sonnet in February 2025 and switched it off in February 2026. If your weekend app called that model through the API, someone had to open the code again within a year. That's one dependency. Now multiply it by every system the app touches.
Someone at a large software vendor recently framed the new value proposition to Jan-Erik like this: customers will buy functions less and the promise more — that the vendor runs the thing with consistent performance, security and quality, and keeps adding innovation. Same argument as the cloud debates a decade ago. It still holds.
What's hidden under the iceberg of a vibe-coded prototype?
Everything it takes to run software in an enterprise for years. Above the waterline sits the prototype somebody built over a weekend. Below it:
- Maintenance, security and compliance — model deprecations, legal changes, new use cases two, three and four.
- Interfaces — the source system changes its API, tokens expire, integrations break.
- Operations — who picks up at 2 a.m. when the truck your software routes is stuck on the highway? A five-second first click is fine for us; for enterprise software it isn't, and always-on costs consumption.
- Knowledge risk — the builder leaves. Where's the source code?
- Opportunity cost — the weeks or months someone in IT or the business spends building instead of doing their actual job.
The prototype is the tip. Total cost of ownership lives below the waterline.
The list is right. Showing it to your customer is wrong.
How should an SE respond when a customer says "we'll just build it"?
Discover, don't defend. Two moves reliably backfire: arguing with your own features, and putting the iceberg on a slide that says "look what you didn't think of." Both put you on the defensive and tell the buyer they missed the obvious. Conflict, barriers, done.
Instead, use the objection framework we built with a customer: Acknowledge, Explore, Reframe, Commit. Back to our CTO:
- Acknowledge. "That's a real option. Your team can certainly build something useful. I'd like to understand it better." Recognize where the other person stands and signal curiosity.
- Explore. What triggered the idea? Missed SLAs? A contractual penalty? Somebody had a reason. Then ask: under what conditions would building really be the better choice? Now the CTO starts checking — is there a board mandate, a budget, a team, a deadline?
- Reframe. They can build it. Whether they should is a numbers question. What does it take to run this in production for the next three to five years? Write the bottom half of the iceberg down together.
- Commit. Agree on the decision criteria — five-year cost, time to a productive solution, who operates it — and have engineering and finance check the math by a fixed date.
"Ideally we ask such good questions that the customer starts realizing on their own that there's more attached to it. That's far more effective than arguing from a defensive position." — Tim Brömme
The first two steps are pure listening; your position only enters at the reframe. The Commit step is really a five-year total cost of ownership calculation, and you can offer to help build it. Often the honest result is a hybrid: some pieces vibe-coded, some from standard software.
Who raises the build-or-buy objection, and what do they actually want?
It depends on who's talking, and the motive is rarely just cost. The CTO weighs feasibility, the CFO wants numbers, and the business unit is in love with the dashboard it built last weekend. Procurement may simply be bluffing for a better price — "come on, we'll vibe-code this internally, I already found someone." For that one, Tim's question cuts through: if the price were the same, would you still build?
The deeper split is why they want to build. Cheaper? Or something else entirely — a more personalized experience for employees or customers, a shorter time to market, faster innovation. Jan-Erik admits that last one is hard to put a number on, yet it can have massive impact. Go into the Explore phase with hypotheses about which motive you're facing, and your questions get sharper. Your counter, where it fits: standard software means buying proven best practice, like the goods flow an SAP system prescribes.
When is building actually the better choice?
When the software sits close to the company's core value creation. Call it core vs. context.
We run this test on ourselves. SE Rockstars' core is developing Solution Engineers' skills. Our learning operations run on a bought platform, and we have so many ideas for doing it differently that replacing it with something self-built is a serious option. Miro is the opposite. Vibe-code our own whiteboard? No chance. It's cheap, it works, and customers would never notice.
Price pressure is moving the line, though. Vertice, which helps companies run B2B SaaS procurement, measures SaaS inflation at roughly four times general inflation: 12.3% in September 2025, 12.2% in early 2026, peaks of 14% in May 2025 and 14.5% at the end of Q1 2026 — likely US figures, against general US inflation of around 3–4%. Every renewal like that tilts a TCO model toward build.
So expect these conversations more often, and be ready to lose some of them honestly.
"Sometimes the answer can be: in your use case, build is simply the better idea. And then let it go." — Jan-Erik Jank
If a lightweight dashboard or a simple workflow is all the customer needs, building may win. When your value comes from something that light, the question to take back to your product team is whether your software is valuable enough — not how to talk the customer out of it.
Frequently asked questions
How do you handle a "we'll build it ourselves" objection in B2B sales? Don't counter with features. Acknowledge the option, explore what triggered it, reframe from "can we build it" to "should we, over five years", and commit to shared decision criteria such as cost, time to production and ownership.
Do AI coding tools make custom software cheaper than SaaS? They make the first version much cheaper. Maintenance, security, integrations, operations, compliance and opportunity cost remain, and those were always the bigger share of total cost.
What belongs in a build vs. buy TCO calculation? Subscription cost versus development, maintenance, security, interface changes, on-call operations, compliance, knowledge risk and opportunity cost. Look at five years, not the first quarter.
When should a company build software instead of buying it? When the capability is core to how the company creates value and standard software would constrain it, or when the need is lightweight — a simple dashboard or workflow. For commodity tools far from the core, buying usually wins.
Facing build-or-buy objections in your deals? Tim has turned this topic into a complete course with the full playbook — book a discovery call and we'll walk your team through it.
Tim Brömme & Jan-Erik Jank, co-founders of SE Rockstars, 30+ years enterprise PreSales, 350+ SEs coached.
Listen to the full episode
Tim and Jan-Erik discuss the history, the iceberg and the objection framework in German on PreSales Unleashed: PreSales Unleashed: Build vs. Buy im KI-Zeitalter (283)