The build it in-house objection shows up most often when the prospect has engineers, a data team, or a RevOps person who is handy with scripts, and the demo made your product look simple. 'We'll build it in-house' is usually said with some pride, and the rep who responds by explaining how hard the product really is has just insulted the people who would build it. The honest version of the argument is about total cost and opportunity cost, and it only lands if you know what the build actually involves: the first version, the edge cases, the maintenance when the CRM schema changes, and the engineer who gets pulled onto it instead of the roadmap. Sometimes the build is the right call and you should say so. The script below gets you to the numbers that decide it. The openers cover the tones you will need, and the smokescreen test tells you when 'build' means 'no.'
What "We'll build it in-house" is really telling you
Two things usually sit under 'we'll build it in-house.' The first is a real technical opinion: someone on the team looked at the demo, saw an API and some logic, and estimated a sprint, without pricing the edge cases or the years of maintenance. The second is a budget move: build is free on this quarter's P&L because engineers are already paid, so it is the way to say no without saying the money is not there. The mistake reps make is to argue about difficulty. Telling engineers the thing is harder than it looks is a bet you lose even when you are right, because they will build a rough version to prove you wrong. The work is to shift from 'can you' to 'should you,' and to get the maintenance cost and the roadmap trade-off on the table in their numbers.
Build it in-house objection script: five beats, spoken
Know your own product's maintenance load before you run this, because the CLARIFY beat invites a real estimate and you need to be able to react to it honestly.
ACKNOWLEDGE: You probably can, and I mean that. The core of what you saw is a few integrations and some logic, and a good engineer gets a first version running in a couple of weeks.
CLARIFY: When you picture the build, who owns it after it ships? And what is that person supposed to be working on this quarter instead?
REFRAME: The first version is the cheap part. What our customers ran into when they built it themselves is the second year: the CRM adds a field and the sync breaks, the data source changes its API, the engineer who built it moves teams, and the rep who depends on it finds out on a Monday morning. The question is whether that is a thing your engineering team should own, or whether you would rather they ship product.
PROOF: Acme Observe built their own version in about three weeks and ran it for a year. When we talked, they told us it had cost roughly one engineer-day a week in maintenance since the second month. That is fifty days a year on a tool that is not their product.
ASK: Could we put the build estimate and the maintenance estimate next to our pricing, with your engineering lead in the room, and let the numbers decide?Direct: 'You could. Can I ask what the engineer who builds it would otherwise ship this quarter?'
Curious: 'What would the first version cover, and what would you leave out? I ask because the leave-out list is where our customers who built it got surprised.'
Dry: 'Most of our best customers built it first. We usually meet them in year two, when the person who built it has moved teams.'The test: ask 'Has engineering scoped it, and is it on a roadmap?' A real build has a name attached and a sprint or quarter it is planned for. A smokescreen has neither, and the prospect will say something like 'we have talked about it.'
If it is not real, name what is: 'It sounds like the build is the fallback if the budget is not there. Is that closer to it?' Then handle the budget conversation instead, because arguing against a build that does not exist wastes both your afternoons.Never tell engineers a thing is hard; ask who maintains it in month fourteen, and let them do the math out loud.
Rewrite the script for your product and this account
The script argues in generalities about maintenance. It is far stronger when it names the specific integrations, schema changes, and edge cases that would bite this prospect's stack. Paste what you know about their tools with the prompt below and let Claude write the build-versus-buy comparison you promise in the ASK.
I am handling the objection 'we'll build it in-house' from {{prospect title}} at {{company}} ({{company URL}}). My product: {{one-line description}}. What it actually does under the hood: {{integrations, data sources, logic, and the parts that break most often in maintenance}}.
Their stack as far as I know: {{CRM, data warehouse, enrichment tools, engineering team size}}.
Rewrite the five-beat script below so REFRAME names two or three concrete maintenance events that would hit their specific stack, and PROOF uses this story: {{customer who built first, how long it took, the maintenance cost they reported}}. Keep it spoken and under 200 words. Then draft a one-page build-versus-buy table with rows for first version, year-one maintenance, year-two maintenance, and roadmap opportunity cost, with {{placeholder}} cells for their engineering lead to fill in. Mark inferred details.
SCRIPT:
{{paste the script above}}Handle any objection with Claude
- Objection handling script prompt →The copy-paste prompt that drafts a response to any objection in your voice, with the proof point pulled from your own wins.
- Competitive battlecard skill →For the competitor-shaped objections: a rep-ready battlecard built from live competitor intel.
- Discovery call prep skill →Most objections are discovery you skipped. The skill preps the questions that surface them before the pitch.
Frequently asked questions
How do you respond to the build it in-house objection?
Concede that they can, because they probably can build a first version, and arguing otherwise insults the people who would do it. Then move the conversation from difficulty to ownership. Ask who maintains it after it ships and what that engineer would otherwise be working on. Name the maintenance events that hit home-built tools, such as CRM schema changes and API deprecations, and offer to put the build estimate, the maintenance estimate, and your pricing side by side with their engineering lead present. If the numbers favor building, say so; that honesty is what gets you the next deal.
When is building in-house actually the right answer?
When the workflow is core to how the company makes money, when they already have an engineer whose job is internal tooling, and when the requirements are unusual enough that no vendor covers them without heavy configuration. In those cases say it plainly and leave on good terms. You lose one deal and gain a contact who tells peers you were straight with them. Most of the time none of those three conditions hold, and the build is a sprint of enthusiasm followed by a year of quiet maintenance nobody budgeted for.
How do you talk to the engineer who wants to build it?
Treat them as the expert on the build and ask for their estimate, then ask what they assumed about maintenance, edge cases, and ownership. Engineers respect a vendor who understands the architecture and will happily tell you where the hard parts are, which is useful because it usually surfaces the parts they had not priced. Ask what they would rather ship this quarter. Most engineers do not want to own a sales tool for three years, and saying that out loud in front of their manager tends to settle the question.