Addressing the Vibe-Coding Objection

A prospect on your demo asks the new question: "Why don't I just ask Claude Code to clone your functionality?" A renewal opens with "we vibe-coded a v0 over a weekend — can we get a discount?" A pricing email comes back: "at this price, I think we're better off vibe coding our own tools."

The popular view of AI is eroding your moat. What's the playbook here?

Even if you're right, your obvious responses aren't helpful. The defensive one — "you can't replicate what we've built here" — sounds threatened and triggers the buyer's contrarian instinct to prove you wrong. Legal threats make you look petty. The capitulating one — "here's thirty percent off" — confirms they were right to ask. Both teach the buyer that next quarter's renewal should start with the same opening line.

A third path has two benefits. First, it shows the customer that you have their best interest at heart — even if it hurts you. Second, it surfaces the practical tradeoffs of ownership. Buying a home might (or might not) save you money. But, compared to renting, it certainly won't save time or attention. When you buy a SaaS solution, you'll never find yourself awake at 3 AM fixing a burst water pipe.

Show the Work

Explain what went into your product, and what daily work your team faces. Ask the questions a thoughtful builder would ask themselves before starting. Take care, however. Use empathy, and behave like a trusted advisor who honestly lays out the pros and cons. If you're never recommending alternatives to your product, you're not behaving like a trusted advisor.

Adopting the trusted advisor persona is critical because the person you're talking to won't appreciate feeling dumb, backed into a corner, or beaten over the head. You want your prospect knowing exactly what your product costs to operate, the expertise behind the scenes, the maintenance, the compliance, the support work. They know you don't operate your business at a loss, so don't pretend otherwise.

"Yes, assuming you have the right skill and expertise on your team, you can clone most of our product and the server costs will be a fraction of what we charge. We don't hide that fact, and yet our customers still pay full price. They value our expertise, our service, and the ability to completely delegate this work to us. They know that their $X,000 a month gives them license to pay full attention to their own business instead of Y. The ROI from investing in their business is boundless, but the best they can do replacing us is $X,000 a month."

Have you ever toured a nice restaurant's kitchen? At the end of the tour, you're left thinking not "I'm never going to another restaurant," but with a greater appreciation for the skill behind the food. You savor it even more.

Give them the kitchen tour. Look at Pat scrubbing potatoes. See Alex plating 300 amuse-bouches. Let them choose with their eyes open. Yes, some will still vibe code. Most will renew with a clearer sense of why they should delegate work to your business.

Draft a Build Guide

What follows are forty-nine questions in six categories. Think of these not as a script, but as a set of components to build your story. You will not use all of them.

Instead, start a document. Read through the list below and pick items that tell a valuable story about your business. Do you have a unique partnership giving you access to proprietary data? Did it take 15 months to negotiate access? That's a good story. Have you trained your model on 13 million transactions? Again, something your customers won't have access to.

Build your document with categories like below. Into each category, list the question, and then below it add the story behind that question.

You can use this document in two ways. First, your can use it in conversations. Lead with the categories most relevant to the deal in front of you — security for a regulated buyer, time and opportunity cost for a fast-moving startup, integrations for a customer with a complex stack.

Second, you can use it, if you're bold, to create a "How to Vibe Code a Competitor to YOUR_COMPANY" web page. The point: illustrate the things that Claude can't replicate — the proprietary knowledge, the quality, the authority, the accountability, the speed, the accuracy, or the customer support.

Hosting & Infrastructure

• Where will it run — your own cloud account, a managed platform, or your laptop until someone notices?
• Which team owns the cloud bill, and have they been told to expect it?
• What's your target uptime, and who gets paged when it's not met?
• Will it run behind your firewall, in a VPC, or on the public internet — and who decides?
• How will you handle a regional outage at your cloud provider — failover, or just wait?
• What's your backup cadence, and when did you last test a restore?
• If traffic doubles next quarter, what changes — autoscaling, a bigger box, or a rewrite?
• Who renews the TLS certificate, the domain, and the third-party API keys before they expire?

Security & Compliance

• Does this tool touch customer data, employee PII, or anything regulated (HIPAA, GDPR, CCPA, FERPA)?
• Will your customers' procurement teams ask for a SOC 2 report on it? What will you send them?
• Who runs the annual penetration test, and what's the budget for remediation when it finds things?
• How will you handle a CVE disclosed against one of your dependencies on a Friday night?
• What's your vulnerability disclosure process if a researcher finds a hole — is there an email address that gets read?
• Where does the data live geographically, and does that satisfy your EU or Canadian customers' data-residency clauses?
• How do you prevent your engineers from committing secrets, API keys, or customer data to git?
• How will you handle a customer data-leak incident — who's the point of contact, what's the disclosure timeline, who calls the lawyer?

Maintenance & Support

• When the engineer who built this leaves the company, who picks it up — and how long will the handoff take?
• What's your patch cadence for the framework, the runtime, and the rest of the dependency tree?
• Who's on call for it at 2 a.m. when the sales team can't generate quotes?
• How will end users file bugs — Slack message to the builder, a ticket queue, or hope?
• What's your SLA to your own internal users, and what happens when you miss it?
• How will you handle a breaking change in your CRM, billing, or identity-provider API on a Friday night?
• Who writes the documentation, and who updates it when the tool changes?
• What's your annual maintenance budget — engineer-hours plus infrastructure plus third-party APIs?

Domain Knowledge & Edge Cases

• Who on your team has run this exact workflow at scale and knows which edge cases will bite you?
• How will you discover the one percent of cases your demo didn't cover — by shipping bugs to customers, or before?
• What happens when a regulator changes a rule that's baked into your prompts or business logic?
• What's your plan for the half-dozen reports your operators will ask for that aren't in the demo — and the admin UI for the support team when something goes wrong in production?
• How will you measure whether v2 of the workflow is actually better than v1 — not just faster to write?
• How will you handle the migration from your current system to the new one, and the rollback if it fails mid-cutover?
• When your integration partner changes their API or pricing, who notices and who fixes it?
• What's your plan for the support tickets you can't predict yet — the ones that reveal unknown unknowns?

Time & Opportunity Cost

• What's your honest estimate to a production-ready v1, and what did you multiply your gut number by?
• What revenue work isn't getting done while your best engineer builds this?
• If this takes three months instead of three weeks, what's the cost to the rest of the roadmap?
• How many of these vibe-coded internal tools is your team already supporting, and how's that going?
• What's the cost to your customers of you being slower to ship your actual product?
• If you build it and it works, who runs it for the next five years — and what is that person not doing?
• Have you priced the deals your AE won't close while she waits for this tool to be ready?
• What's the off-ramp if you're six months in and it's not working — do you buy us then, or keep digging?

Integrations & Ecosystem

• Which other systems does this need to talk to — CRM, billing, identity provider, data warehouse?
• Who owns the OAuth app registration with each vendor, and who renews the secrets?
• Have you read the API rate limits on every upstream service, and modeled what happens at peak?
• Does any vendor require partner-program membership, certification, or revenue commitment to access the APIs you need?
• How will you handle SSO with your customers' identity providers — Okta, Azure AD, Google Workspace, the long tail?
• Who maintains the webhooks when an upstream vendor changes their payload schema?
• What's your plan for usage growth — when does the small instance need to become a fleet, and who decides?
• When a key integration partner deprecates the API version you built on, who does the migration?
• How will you get access to the same proprietary data?

One scope note. If your product is itself LLM-powered — or if the replacement the buyer is building will be — add a separate set of questions about prompt injection, evaluation harnesses, model deprecation, and non-deterministic output monitoring. Those are real questions in 2026, but they're a different conversation. The forty-nine above apply whether the buyer is cloning a CRM, a billing platform, an analytics dashboard, or a project tracker.

Publish Your Build Guide

Most B2B SaaS companies sit on a quiet competitive moat made of work nobody sees. A weekly read on industry trends that shapes the roadmap. A list of regulatory changes the legal team tracks. Integration partnerships negotiated with hard-won concessions. The customer-support patterns that surface the one percent of cases the product was built around. The on-call rotation that runs through holidays. The eval harness the ML team built to catch model drift. The procurement playbook for SOC 2 questionnaires that ships in two business days.

That work is invisible by design. It's the thing you sell. But in an era when buyers think the surface — the UI, the workflow, the visible features — is the product, the invisibility hurts you.

Publish the guide. Title it something like "If You Were Going to Build This Yourself, Here's What You'd Need to Think About." Use the six categories above as the section headers. Fill the sections with what your team actually does, named specifically: the trends you read each Monday, the regulatory feeds your legal team subscribes to, the OAuth scopes you renegotiated with each integration partner, the SOC 2 controls and the auditor who signed them, the on-call rotation and the runbook for the worst-case page.

Publish it as a positioning document. The buyer who reads it and still says "we'll build it" was never your customer. The buyer who reads it and says "we want a partner who already does all of this" will have a different level of respect for your product.

The Customers Who Come Back

Among the CEOs I work with, vibe coders are already returning, hat in hand. Just because AI can write code doesn't mean it's free or fast. When customers realize that, welcome them back. And be sure to ask them if there is something you can share with your other customers about why they came back.

These are the most valuable testimonials you'll ever collect. They're not about features. They're about the hidden gap between your features list and the actual work of building a powerful, reliable product.

The strategic version of this question — which parts of your product AI replaces, where the real moat sits, and what to ship next — is the spine of Run AI on the Graveyard Shift. The closer in Why Bootstrappers Now Need an AI Chief of Staff names the audience-as-moat point that pairs with it.

The Cost of Doing This Well

First, you will lose some deals. The buyer who actually has the engineering talent and the eight months of runway to rebuild your product was going to leave anyway, either due to vibe coding or business failure. Some people simply refuse to pay for food when they can grow and cook it at home.

Second, your team has to know the answers. The questions above are diagnostic, but the buyer will eventually ask them back: "OK, so how DO you handle a Friday-night CVE? Who's on call at 2 a.m.? When AWS goes down, what's your failover?" The AE has to know. The CSM has to know. The founder has to write down what's been quietly in their head. The reps who don't know start sounding evasive — which lands worse than the original "you can't build it" reflex.

That is not a cost. That is the price of admission to selling B2B SaaS in 2026.

Where to Start

Pick three deals in your pipeline where the vibe-coding objection is live or imminent — a stalled renewal, a discovery call where the prospect mentioned "build vs buy," a new-business deal that's gone quiet. Pick three or four questions from each category that fit those deals. Run them in the next call. Listen for what the buyer doesn't know they don't know — those are the places your moat is real.

Then write the guide.

That's what one rep can do tomorrow. For a sales team, the work is shared. Draft the build guide once, name an owner, work the question categories into onboarding, and capture every returning-customer story for the next version. Every rep gets the same answers; every renewal call starts from the same foundation.