The Buy vs. Build conversation is the perfect opportunity to stand out, build trust, and start proving you offer real value. Don't let it slip from your grasp.
The simplicity (and advertising) of Lovable, Cursor, Claude Code, and a thousand other AI-native tools has skewed the traditional Build vs. Buy discussion. It's no longer confined to hardcore Not-Invented-Here engineering teams — nearly everyone is having a rational conversation about cutting vendors and automating processes. "Build" is a far more viable option than it's ever been before.
Sharing insights with prospects about how to skip the need for a vendor might seem counterintuitive, but a true value-seller doesn't shy from hard conversations. Before anyone gives you money, people inside your buyer's org are going to have this discussion. It's more realistic than it used to be, and they're going to have it with or without you.
The numbers bear this out: 97% of B2B buyers build a business case to justify a purchase (Forrester, 2019), and 79% of those purchases require CFO approval (TrustRadius, 2024). The DIY option will be on the table when that case gets built internally. The question is whether you shaped the conversation or got blindsided by it.
Here's the uncomfortable truth sellers face: it actually is easy to stand up a Proof of Concept software project with AI in a fraction of the time it used to take. The devil is in the details, but that nuance can get lost in the jubilant elation of standing up an app that looks production-ready in a single afternoon.
The good news: this conversation is a gold mine for value sellers. In one swoop, you establish yourself as an industry expert and trusted advisor, you earn a golden invitation to deep discovery, and you can demonstrate beyond any doubt the true value of what your organization brings to the table.
1. Start the Conversation to Shape the Conversation
By addressing the DIY elephant in the room, you immediately differentiate yourself from every other rep who pretends the option doesn't exist. The buyer has likely already started thinking about DIY, so acknowledging it as worthy of consideration makes you behave like a trusted advisor, not a sales rep.
But there's more than goodwill at stake. If you start the conversation, you get to shape it.
This conversation should wait until you've established that the buyer has a real problem. But once that's clear, you're ready to talk about solutions. Acknowledge that DIY is worth discussing, and lead off with questions:
- Have you tried to fix this problem yourself in the past?
- If yes: what went wrong? File those costs and pains away for later, then ask what will be different if they try DIY again.
- If no: offer to work through DIY with them.
Walking through DIY helps both of you understand how their organization works: the core strengths, any weak areas, who makes low-level systems decisions, which bits of tech are non-negotiable, who in IT is willing to experiment versus the Dr. Nos who kill projects for no good reason.
While you walk through how they would do it on their own, take note of who's involved and get your champion to acknowledge how much time and effort will be required of specific people. You'll use this later in a head-to-head comparison of DIY vs. Vendor.
As you lead the conversation, dig into the uncomfortable parts of fixing the problem — the parts that require unsung work after the weekend project's flashy demo.
Here's the important bit: you have to be honest about DIY. If there's a viable path, share it. If a weekend project with Claude Code can genuinely replace what you're selling, you might need to go find a new job. Have faith that your team knows more, has done more, and is worth more.
Remember this: the customer will be having the Build vs. Buy conversation whether you're there or not. So grab the conversation by the horns and swing that elephant around the room.
The alternative — 40–60% of pipeline lost to no-decision (Corporate Visions / SBI) — is what happens when buyers get confused and stuck without anyone to guide them.
2. When the Competition Is a Weekend and a Claude License
DIY has always been an option, but AI brings it to every team at every company. It seems like anyone with an AI coding tool and a weekend can reproduce the solution you're currently charging real money for.
As a vendor defending against an in-house AI solution (or an AI-native startup offering similar service at a fraction of the price), you need to price three risks inside the buyer's brain: vibe-coding risk, time-to-value, and post-POC effort. Let's take each one.
Vibe-Coding Risk
The gap between "it works on my laptop" and "it works in production" has not been compressed by AI.
-
Garbage in, garbage out. AI will code whatever you ask for. Real software has a team working on requirements and design before a developer ever touches a keyboard. Successful vibe coding still needs detailed requirements with edge cases and assumptions specified. Weekend projects skip the design thinking that makes good software, and trying to fix it one conversation at a time produces a messy app with a messy UI.
-
Tech debt. Agentic code can be well-written in isolation, but it forgets across sessions and codebases become tangled fast. This is fine if you regularly run refactors and track technical debt — but that's the boring stuff that always gets skipped in DIY.
-
Security. Unless you specify otherwise, AI takes the fast route. You might ask for row-level security in your app, and the agent will confirm it's enabled — only for you to discover later that every route is treated as admin and skips authentication entirely. Excessive third-party dependencies are another security vector that agentic coding will expose you to.
-
The "built in-house" illusion. Most DIY AI solutions aren't truly built in-house in any meaningful sense — they're orchestration layers on top of third-party inference APIs. The DIY team is just providing the glue; the actual intelligence runs on someone else's infrastructure. That means the buyer inherits the provider's pricing changes, model deprecations, and compliance posture without any of the contractual leverage a proper vendor relationship provides.
Time-to-Value
57% of B2B buyers expect ROI within three months of a software purchase (G2, 2024). A six-month DIY build doesn't survive that expectation.
-
Development time. In-house will almost always be slower to production than buying a solution. So the buyer is paying for the pain — the unsolved problem — while the DIY build goes from flashy POC to production grade. Can they afford that?
-
Catastrophic failure. Worst case: the buyer spends months developing in-house, rolls it out, finds problems, tries to fix them, finds more — and gives up. Now they're back to square one with compounded pain and burned political capital. 86% of B2B purchases stall during the buying process (Forrester, 2024). A DIY option that adds months of development time makes the stall permanent.
Post-POC Effort
The initial build of a non-trivial system represents 10–20% of total lifecycle effort. The remaining 80–90% goes to maintenance, security patching, compliance, and integration upkeep. AI has compressed the first 10%. It has not had anywhere near the same impact on the other 90%.
-
Ongoing code maintenance. Feature enhancements, bug fixes, library updates, devops, security patches — all require an ongoing technical owner. When the person who built the weekend project moves on (and they will), who inherits the codebase?
-
Compliance and certification. PCI-DSS, HIPAA, GDPR, SOC 2 Type II, ISO 27001 — each is a multi-quarter certification project with annual recertification. The buyer might not need these for a truly internal product, but if they're touching their customers data they do. The DIY business case almost never budgets for this. A vendor amortizes certification across their customer base.
-
User support. Vendors have entire teams dedicated to implementation, customer success, and customer support because they recognize that software is only useful when it's being used. Who takes on that responsibility for a DIY build long-term?
-
Innovation velocity. A vendor sees emerging requirements across hundreds of deployments — new compliance regimes, new integration patterns, new failure modes. The in-house team sees one deployment. The gap between the two widens every month after launch, not at launch.
After all three risks are accounted for, there's a good chance the opportunity cost and risk exposure end up exceeding the cost of just bringing in a vendor. Which brings us to making that case with numbers.
3. Doing the Buy vs. Build Math
After all of the above, does DIY really create a net savings vs. vendor?
Only 16% of sellers are rated "very effective" at making the ROI case by buyers (RAIN Group, 2024) — but 66% of those same buyers say a clear ROI case has high influence on their decision to purchase. The math matters. Do it well and you're already in rare company.
The critical component: calculate these over an 18–24 month horizon. This forces the buyer to consider the ongoing impact and costs beyond the first flashy POC demo.
Costs
What is it going to cost to make this change? Think beyond the demo — rollout, training, maintenance, new features, support at 2 AM when things break.
Hard costs. A vendor will nearly always require more hard-budget than DIY, but DIY has expenses that are easy to miss: AI compute costs, infrastructure, monitoring, and security tooling that a vendor bakes into their price.
Opportunity cost. Internal opportunity cost is real but hard to calculate. Don't use hourly wage. Instead, ask your buyer what the economic output is of the people who'd be doing this DIY project. Present it as a total dollar cost or as hours. Ideally, break the costs down across milestones so the buyer can track your logic.
Impact
Cost is only one part of the equation. DIY and Vendor will deliver different impacts. Most people will acknowledge that a vendor solution will be faster — it's your job to prove that your solution will be more effective than home-grown.
Time to value. Discount implementation time from the relief of pain. If the DIY fix takes 6 months vs. 1 month for a vendor, that's a delta of pain accrued to the DIY column. Factor in adoption too: a vendor has a full implementation and CS team, where DIY will probably have an email announcement and a slide deck on a shared drive.
Efficacy. Will the proposed solution fix 100% of the problem? If not, discount the benefit. DIY has never solved this problem before — it's unlikely to be as effective as a team that's done it hundreds of times. That efficacy discount drags down impact every month, every quarter, forever.
Catastrophic failure risk. What are the chances of total failure? What is the cost if the AI agent corrupts an adjacent codebase or database or opens up a security hole? Can you afford even a small probability of that outcome? How much time, effort, and political capital are at risk on each approach?
Make the Switch
There's nothing to fear from a Build vs. Buy conversation.
So initiate it. Lead with honest questions. Walk through the DIY path together. Do the math over 18–24 months.
You'll build credibility, you'll take the wind out of the sails of the DIY faction, and you'll conduct the deepest discovery of the entire sales cycle.
The worst outcome isn't losing the BvB argument — it's never having the conversation at all and watching the deal stall into no-decision.
Grab it.
