How do you handle the “we’ll build it in-house” objection?
To handle the “we’ll build it in-house” objection, do not argue that the team cannot build it. Agree that they probably can, then compare the two options on the same criteria: time to a working version, the cost of running it for three years, who maintains it, and what those engineers would otherwise be doing.
Buyers rarely use the textbook wording. You will hear it as:
- “We’ll build it in-house.”
- “Our engineering team could put this together.”
- “We already have the data, we just need a layer on top.”
- “Why would we buy this when we can build it?”
What does the buyer usually mean?
The same words can hide different concerns. Work out which one you are facing before you answer:
- Someone has already agreed the problem is real. This is the better version of the status quo objection. The buyer accepts that the current process costs something, which means the discovery work is done and the argument is now about method.
- The build looks cheaper because the estimate is incomplete. Internal projects are costed as a build and not as a product: no maintenance, no support rota, no migration, no onboarding for next year’s hires, no second release.
- An engineering leader is defending a roadmap. Buying a tool can read as a vote of no confidence in a team that has been promising this feature. The objection is sometimes a position rather than an estimate.
- They have built something already. A shared drive with a naming convention, a dashboard, a few scripts. It works, it has one owner, and nobody has asked what happens when that person changes team.
- They are picturing a fraction of the scope. The first release usually is a fraction. The gap appears at permissions, version history, audit trails, integrations, buyer-facing links and everything a small internal tool is never asked to do on day one.
A response framework for the “we’ll build it in-house” objection
Use these steps in order. Most of the work is in the questions, before you make any case of your own.
Step 1: Concede the capability, then narrow the scope
Say plainly that the team could build it. Then ask which parts they would ship in the first release and which they would leave out, because the honest answer is usually a third of what you do.
Step 2: Ask who maintains it in year two
Every build has an author; fewer have an owner. Ask who supports it, who updates it when the CRM fields change, and what happens when that engineer moves on. The answer is the real cost of the option.
Step 3: Cost it the way they cost a product
Engineer days to a working version, then an annual share for maintenance, support and change requests. Ask for their blended day rate rather than supplying one of your own, so the number stays theirs.
Step 4: Name the opportunity cost
Ask what those engineers are committed to this quarter and what would be dropped to free them. An internal build is rarely compared with doing nothing. It competes with the roadmap.
Step 5: Compare on one real task, not on features
Pick a job the team does every week and ask both options to do it end to end, for a real buyer, with the permissions they would really need. A feature list flatters a build; a real task shows the gaps.
Step 6: Offer a smaller first step than the build
A scoped pilot with one team and a success measure you both agree is a shorter path to evidence than a first release. Put it in a shared plan with an owner and a date, and let the comparison settle it.
Example talk tracks
Adapt the wording to your product and the buyer’s numbers. The companies and figures are illustrative.
Discovery: “We’ll build it in-house.”
“You probably could, and it would work. Can I ask what goes in the first version? If it is a library and a share link, that is a few weeks. If it is permissions, version history and buyer analytics, that is a different project, and it is worth knowing which one you are costing.”
Engineering in the room: “We already have the data, we just need a layer on top.”
“Agreed, and the data is the hard part, which you have done. Who owns the layer in year two, when the CRM fields change and the person who wrote it has moved to another team? That is usually the line that decides build or buy, not the first release.”
Late: “The build came out cheaper.”
“That’s worth taking seriously, so let’s check it covers the same scope. Does the estimate include maintenance, support and migration, and which roadmap item gets dropped to free those engineer days? If it is still cheaper after that, you should build it.”
What do reps score on the “we’ll build it in-house” objection in practice?
Revspire’s practice data does not score an in-house build as an objection type of its own. Its nearest measured parent is the competitor objection, at 3.5 out of 5 across more than 2,000 scored AI role-plays, because the rep is comparing against a named alternative rather than against inertia, and here the alternative is the buyer’s own engineering team. That is a better score than the status quo objection, the hardest of the five types at 2.9 out of 5, and the reason is instructive: a build has a scope, a cost and an owner, so there is something concrete to compare, which is easier than arguing with “our current process works fine”. The way reps lose this one in role-play is by disputing the capability instead of the estimate, which turns a comparison the buyer invited into an argument they did not.
- Status quo objection“Our current process works fine.”2.9
- Price objection“It’s too expensive.”3.2
- “We already have a vendor”“We’re already using another solution.”3.5
- Timing objection“We’re not ready yet.”3.8
- Security objection“We have concerns about data security.”4.1
Average score on a 1–5 rubric by objection type, more than 2,000 scored AI role-play sessions across 20 B2B companies, October 2025 to September 2026. Source: Revspire sales skills gap benchmark. Scores measure practice conversations, not live deals.
Practice prompt: rehearse the “we’ll build it in-house” objection
Run this scenario before a live call. Swap in your own buyer, product and numbers once the structure feels natural.
- The buyer
- VP of Revenue Operations at a 1,200-person fintech (invented). He has two engineers assigned to internal tooling and a half-built content library on a shared drive. His CTO has said the team can extend it in a quarter, and he does not want a vendor conversation that disputes that.
- Their opening line
- “Honestly, we think we can build this ourselves. We have the data and two engineers who know it well.”
- The rep’s goal
- Concede the capability, establish what the first release would cover, cost the option over three years including maintenance, name the opportunity cost, and agree a comparison on one real task with a date.
- Score the rep on
- Accepts that the team could build it instead of disputing the capability
- Establishes what the first release would and would not include
- Asks who maintains and supports the build in year two
- Costs the build with the buyer’s own day rate, over more than one year
- Asks what engineering work would be dropped to free the time
- Agrees a comparison on one real task, with an owner and a date
Frequently asked questions
What is the “we’ll build it in-house” objection?
It is a buyer saying they will solve the problem with their own engineers rather than buy a product, for example “we’ll build it in-house” or “our team could put this together”. It accepts the problem and rejects the purchase, which makes it a comparison rather than a concern.
How do you answer a build-versus-buy objection in sales?
Agree that the team could build it, then compare both options on the same criteria: the scope of the first release, time to a working version, three-year cost including maintenance and support, who owns it in year two, and the engineering work that gets dropped to free the time.
Is “we’ll build it in-house” the same as a status quo objection?
No, and the difference changes the response. A status quo objection says the current process is fine, so the work is to put a cost on it. An in-house build accepts that cost and proposes another solution, so the work is to compare two options honestly.
What questions expose a build estimate that is too low?
Ask what the first release excludes, who maintains it in year two, what happens when the CRM or the data model changes, how permissions and version history are handled, who answers a buyer-facing question at the weekend, and which roadmap item is dropped to free the engineer days.
Should you ever agree that a buyer should build it?
Yes, when the scope is genuinely narrow, the data already sits in one place and the team has an owner who will still be there next year. Saying so costs you a bad deal and keeps the relationship for the part they will not build.
What evidence helps most in a build-versus-buy conversation?
Their own figures rather than yours. Ask what the problem costs today in seller hours and rework, then set it against a three-year build cost. Product fit was the most common closed-won reason sellers recorded in their CRMs in the Revspire win/loss benchmark, ahead of ROI and the business case, so fit demonstrated on a real task is worth more than a feature list.
Sources
Third-party figures are quoted as published and also appear, with their samples, on our sales objection statistics page. Practice scores are Revspire data.
- CSO Insights (Miller Heiman Group, now part of Korn Ferry). 2019 Sales Enablement Report: Fifth Annual Sales Enablement Study. 2019; 900+ participants worldwide.
- Revspire. Sales skills gap benchmark: what 2,000+ scored AI role-plays show. October 2025 to September 2026 data.
- Revspire. B2B sales objections benchmark: win rate, discount and cycle time by objection. October 2025 to September 2026 data.
- Revspire. B2B win/loss benchmark: why deals are won, and what price losses hide. October 2025 to September 2026 data.
- Revspire. Mutual action plan benchmark: do MAPs shorten B2B sales cycles?. October 2025 to September 2026 data.