The we built it in-house objection is one of the most final-sounding replies in B2B outreach, and most sellers treat it as a closed door. They thank the prospect and leave. That is a mistake. "We built it in-house" is rarely the end of the conversation. It is the start of a different one, because internal builds carry hidden costs the buyer is often quietly aware of.

This guide breaks down what the we built it in-house objection actually signals, how to tell a proud, finished build from a fragile one held together with tape, four responses that open a real conversation without insulting their work, and the mistakes that get you dismissed for good. Done right, this objection becomes one of your best qualification tools.

Key takeaways

• "We built it in-house" is a fact, not always a happy one. Many internal builds are maintenance burdens nobody loves.

• Never criticize their build. Validate the decision, then ask about the cost of maintaining it.

• The opening is total cost of ownership: engineering time spent maintaining instead of building core product.

• Position yourself as the team that frees their engineers, not the team that replaces their work.

• If the build is genuinely solid and well-loved, accept it and stay in touch for when it stops scaling.

What does we built it in-house actually tell you?

The we built it in-house objection tells you the buyer recognized the problem and committed real resources to it. That is good news, not bad. It means the pain is validated and budget-worthy. Companies do not build internal tools for problems they consider trivial. The question is not whether they have a need, it is whether their solution still serves them well.

Internal builds follow a predictable arc. They are exciting at version one, adequate at version two, and a quiet drag by the time the original builder has left, the requirements have grown, and the tool needs constant patching. The engineer who maintains it would rather be shipping core product. That tension is your opening. So when you hear "we built it in-house," do not hear "no need." Hear "validated need, possibly aging solution," and your next job is to find out which.

How do you tell a strong build from a fragile one?

You find out with curiosity, not challenge. Ask questions about the build as if you genuinely admire the decision, because you should. The answers tell you whether the tool is a source of pride or a source of pain.

Ask: "Smart move to build it. How is it holding up as the team and the use cases grow?" A strong build gets a confident answer: "honestly great, it does exactly what we need." A fragile one leaks: "it works, but it is one person's project and they are slammed," or "it does the core stuff but we keep meaning to extend it." Hesitation, a named single owner, a list of things they "keep meaning to" fix, those are all signals the build is straining. A confident, specific answer with no caveats means the build is solid, and you should respect that. Diagnose before you decide how to respond.

Four scripts to handle we built it in-house

Each script validates their decision first, then opens a conversation about cost or limits. Never lead with why your product is better.

Script 1: the total cost of ownership angle

Use as your default. "That makes sense, and a lot of strong teams build this themselves first. The thing most of them tell me later is the build was the easy part, the maintenance is the tax. Roughly how much engineering time goes into keeping it running each month? If it is meaningful, that is time not going into your actual product."

Script 2: the bus-factor angle

Use when one person clearly owns the tool. "Got it. Quick question, is that mostly one engineer's project? The risk teams flag to me is the day that person is on leave or moves on. If that resonates, it might be worth a 15-minute look at what de-risking it would involve, no pressure either way."

Script 3: the roadmap-gap angle

Use when the build covers basics but the buyer hints at gaps. "Totally fair. The pattern I see is the internal version nails the first 80% and then the last 20%, [edge cases / scale / new requirements], becomes a forever backlog item. Is there anything on that list your build does not cover yet that actually matters?"

Script 4: accept and stay close

Use when the build is genuinely solid. "Honestly, that sounds like it is working well, and I am not going to try to talk you out of something that does the job. Builds like that usually hit a wall at a certain scale though. If that day ever comes, I would be glad to be a quick call. Mind if I check in once down the line?"

What should you never do with this objection?

The fastest way to get permanently dismissed is to disrespect the buyer's build. Avoid these four mistakes.

• Do not criticize their build. Calling their internal tool inferior insults the engineers who made it and the manager who approved it. You are now arguing against the people you need on your side.

• Do not pitch features immediately. Listing what your product does better assumes their build is bad. Ask about cost and limits first; let them surface the gaps.

• Do not say "but can it scale?" It is a tired, transparent trap. Ask a specific, honest question about how the tool is holding up instead.

• Do not walk away on the first hearing. Accepting "we built it in-house" without one diagnostic question throws away a validated-need lead that may be straining.

How do you position against an internal build?

When the build is straining, your positioning is not "we are better than your tool." It is "we give your engineers their time back." The decision-maker does not love their internal tool; they love their core product. Every hour an engineer spends maintaining a side tool is an hour not spent on the thing the business actually competes on. That is the frame.

Quantify it where you can. According to widely cited engineering research, maintenance and operations consume a large share of total software lifecycle cost, often the majority. The internal build looked free because it was a one-time effort; the ongoing cost is hidden in salaries and opportunity cost. Make that visible without being preachy, and the conversation shifts from "build vs buy" to "where should our engineers spend their time." This is the same reframing logic used in how to handle the no budget objection and the broader outbound objection cheat sheet.

How do you reach companies whose internal build is breaking?

The best time to talk to a company about replacing an internal tool is the moment that tool starts visibly failing. You cannot guess that timing from a static list. But buyers signal it in public. An engineer posts "anyone know a good tool for X, our homegrown one is becoming a nightmare to maintain." A founder asks for recommendations because the internal version cannot keep up.

Those posts are perfect-timing intent signals. An AI sales rep like repco.ai monitors Reddit and LinkedIn for exactly that language, scores the buying intent 1 to 10, and drafts a reply tied to the specific post, so you reach the buyer while their build is actively painful rather than when it is still working fine. That is the difference between hearing "we built it in-house" as a wall and catching the moment the wall cracks. For the deeper logic, see the signal-based selling playbook and how to monitor Reddit for buying intent.

Frequently asked questions

Is we built it in-house a polite no?

Sometimes, but less often than other objections, because it states a real fact. The deal is dead only if the build genuinely works well and the team is happy with it. If there is any hesitation, a single owner, or a backlog of unfixed gaps, the objection is an opening, not a wall.

Should I try to convince them their build is bad?

Never. Attacking their build attacks their judgment and their engineers. Instead, ask neutral questions about maintenance cost and limits, and let the buyer voice the problems themselves. Self-discovered pain is far more persuasive than pain you insist on.

What if their internal build genuinely works well?

Respect it and stay in touch. Internal tools commonly hit a scaling or staffing wall later. Accept the answer gracefully, ask permission to check in down the line, and be the easy call when their build starts straining. Forcing the issue now just burns the relationship.

How do I quantify the cost of an internal build?

Focus on ongoing engineering time and opportunity cost, not the original build effort. Ask how many hours per month go into maintenance, then frame that as core-product work lost. Maintenance is the majority of software lifecycle cost in most engineering research, and buyers underweight it.

Bottom line

The we built it in-house objection confirms the buyer has a real, funded need, which is exactly what you want. Do not retreat and do not attack the build. Validate the decision, diagnose whether the tool is thriving or straining, and if it is straining, reframe the conversation around freeing their engineers. Best of all, catch buyers in the moment their internal build starts failing. To find those public signals on Reddit and LinkedIn, see how repco.ai works.