How Do You Sell Against a Team That Wants to Build It?

How do you sell against a team that wants to build it themselves?

Stop arguing that building is hard and start pricing what building costs them. Engineers are right that they could build it. The question you want them answering is whether this is the best use of the most expensive people in the company for the next two years, including maintenance.

This objection has got harder to handle, not easier. A few years ago you could imply the build would fail. Now it probably will not.

So the honest argument has changed shape, and the teams still using the old one are losing deals they should win.

Why is build in house a stronger argument in 2026?

Because AI has genuinely lowered the cost of writing the first version. Stack Overflow's 2025 Developer Survey found that "84% of respondents are using or planning to use AI tools in their development process" and that "51% of professional developers use AI tools daily."

That changes the calculation your buyer is running. A prototype that used to take a quarter now takes a fortnight, and a senior engineer can demonstrate something credible in a single afternoon meeting.

Pretending otherwise damages your credibility. If you tell a room full of engineers that building this is too hard, and one of them built a working version last week, you have lost the deal and the respect in one sentence.

What does building it actually cost?

More than the salary of the person who builds it, and the salary alone is already substantial. The US Bureau of Labor Statistics reports that "The median annual wage for software developers was $135,980 in May 2025," with "The lowest 10 percent earned less than $82,460, and the highest 10 percent earned more than $214,670."

Take the median and add employer costs, and you are near two hundred thousand dollars a year of loaded cost for one developer. Most internal builds of anything non trivial occupy more than one person, and they occupy them for longer than the estimate.

The labour market makes replacement risk real too. The same BLS data projects employment of software developers, quality assurance analysts and testers "to grow 10 percent from 2025 to 2035, much faster than the average for all occupations." A tight market means the person who built your internal tool is the person most likely to be hired away from it.

None of this is an argument you make aggressively. It is arithmetic you hand over and let them do.

Which part of the cost do they always forget?

Every year after version one ships. Building something is a project with a start and an end date, which is easy to estimate and easy to approve. Owning it is a permanent commitment with no end date at all, and that second half is what gets left out of almost every comparison.

Cost	In the estimate	Usually forgotten
Initial build	Yes
Bug fixes and edge cases	Partly
Keeping up with API and platform changes		Yes
Security review and compliance evidence		Yes
Handover when the builder leaves		Yes
Features competitors ship that users then want		Yes
Opportunity cost of the roadmap not built		Yes

Compliance is the sharpest of these in B2B. If the internal tool touches customer data, someone now owns the evidence for every security questionnaire, and that burden lands on the same engineers. Our notes on security review in procurement cover what that involves.

Trust is the quieter one. The same Stack Overflow survey found trust in AI accuracy at 33 percent against 46 percent who actively distrust it. A build accelerated by tools the builders do not fully trust still needs the same review time, which is exactly the part the fortnight estimate leaves out.

When should they build it themselves?

When the thing is genuinely core to how they compete, or when their requirements really are unusual. Say this out loud in the room. A vendor who never concedes the build case is not credible on any of the rest.

The clearest signal is differentiation. If the capability is how they win against their own competitors, they should own it, and you should not try to talk them out of it. If it is infrastructure everyone in their industry needs identically, buying is almost always right.

The second signal is whether they have the people to spare. A team with engineers sitting idle faces a different decision from one with a two year backlog. Ask which they are, and take the answer seriously. We went through the general version in our notes on build versus buy decisions.

What is the wrong way to fight this?

Fear, disparagement and complexity theatre. Telling a team their build will fail, implying their engineers are not good enough, or inflating your product's difficulty to look hard to replicate. All three are transparent and all three cost you the technical audience.

Feature lists are the subtler mistake. Listing two hundred features against their prototype's twelve invites the obvious response, which is that they only need the twelve. You have just helped them scope the build.

Discounting early is the third. If your answer to build in house is a lower price, you have conceded that the only thing you offer is a cheaper version of their own labour, and you will be held to that price forever.

What actually changes the conversation?

Showing them the part they have not thought about yet. Not a feature, a category of ongoing work. The edge cases you handle that they have not encountered, the compliance artefacts you already produce, the platform changes you absorb on their behalf.

The strongest version is specific and unglamorous. There is a particular failure mode you handle in a particular way, and explaining it tells an engineer something they did not know, which is worth more than any slide.

Reframing the decision helps too. It is not build or buy, it is build this or build the thing only you can build. Framed that way, you are on the same side of the table as the engineering leader who is already short of capacity.

How do you handle the champion who is the person who would build it?

Carefully, because their credibility is attached to the alternative. An engineer who has told their leadership they could build this in a quarter has staked something, and a proposal that makes them look wrong will be resisted regardless of its merits.

Give them a way to be right and still buy. They were right that it is buildable. The question is priority, and priority is a leadership decision rather than a technical one. That framing lets them agree without retracting anything.

Better still, give them something to build on top. A product with a decent API turns the internal champion from a competitor into an implementer, and their build instinct becomes the integration that makes you sticky.

What if they already built a version?

Treat it as validation and ask what it cost. A working internal tool proves the problem is real and worth solving, which removes the hardest objection in any sale. What it does not prove is that maintaining it is a good idea.

Ask three questions. Who maintains it now, what has it not kept up with, and what would happen if that person left. The answers are usually uncomfortable and the buyer arrives at the conclusion themselves.

Never mock the internal build. Somebody in the room is proud of it, and they are the person whose support you need. Our notes on competing against a free alternative cover the adjacent version of this.

What would we do in the next deal?

Concede in the first five minutes that the build is entirely possible, then spend the rest of the meeting on the total cost over three years and the roadmap items they would be giving up to fund it. That sequence disarms the objection rather than triggering the defence of it.

Bring the arithmetic rather than assertions. A loaded developer cost, a realistic maintenance share, and an honest note about where building genuinely wins. Buyers trust a vendor who shows the working.

If you are up against this objection regularly and want help building the page and the numbers that answer it, we are happy to work through it with you. You can find us at phoenix.studio.