'We Can Build It Ourselves': The Objection Nobody Prices Out

Objections · hard difficulty · 8 min read

A small yellow sticky note reading 5 WEEKS leaning against a tall ream of paper whose index tabs read retries, opt-outs, quiet hours, permissions, audit trail, upgrade #3 and on-call, beside the quoted line We could build this in five weeks set large in navy above Version one is the cheap part in orange

Nearly every team that says "we can build it ourselves" is right, and that is what makes the objection hard. They have engineers, version one genuinely is a few weeks of work, and telling them otherwise makes you sound like a vendor defending a price. So do not argue the build. Move the conversation from whether it can be built to whose queue it joins, what comes off that queue to make room, and who owns it in year two. Their own engineer will answer all three out loud, in front of the person holding the budget, if you ask without putting them on trial.

The meeting where your deal becomes a sprint ticket

It almost never arrives as a rejection. It arrives as enthusiasm. The demo landed, the workflow made sense, and someone leans forward: "Honestly, most of this is a queue and a template engine. We could probably build this."

The room reorganizes in four seconds. Your champion, who was talking about outcomes a minute ago, is listening to a colleague sketch an architecture. The technical person, quiet until now, has been handed the most interesting problem of their week. You are no longer the vendor under evaluation. You are the reference design.

This is not the "we already have a vendor" objection, which comes with a contract, a renewal date and a switching cost you can work with. Here there is no incumbent. You are competing against a future version of the buyer, one with no bugs, no on-call rotation and no cost. None of those facts exist unless your questions produce them. The timing is the tell: the build idea shows up after the demo, never before it, because your product made the scope look small.

Why does arguing feasibility lose the deal?

Because it is the one claim in the room you cannot win and they cannot lose. Say "that is harder than it looks" and you have told a working engineer they are not good enough, in front of their manager. They defend the estimate, the manager backs the team, and the meeting becomes a referendum on your credibility instead of a decision about their roadmap.

Three other ways reps hand this one away:

Comparing your price to their build cost. Your quoted number against "five or six weeks of one developer" loses every time, because the weeks are a guess and your number is on paper.

Reciting the feature list they would have to build. It reads as a threat, and every item invites "we would not need that." Now you are negotiating the scope of a product they have not committed to building.

Leaving it alone and hoping. It does not come back later. It becomes a line in a planning document you never see, and four months on your champion writes to say they are going internal "for now."

All three treat the build as a competing product. It is a staffing decision nobody has made yet, and the objection handling guide rule bites hardest here: your answer is worth nothing unless the buyer can repeat it in a room you are not in.

Inside the engineer's head: the queue, not the capability

The engineer is not asking whether this can be built. They know it can. They are running a quieter calculation: what this pushes down the list, who supports it in the busiest two weeks of the year, and what happens the third time an upgrade breaks the integration at nine at night. They keep that to themselves in a vendor meeting, because "we do not have room" sounds like an excuse when leadership is listening.

So the person you were most worried about is your best ally. Give them a safe way to name the constraint and they will, because it is true and it protects them from owning something they did not ask for. It helps to be specific about where estimates go wrong. Version one was never the expensive part.

The pieceWhat the first estimate coversWhat shows up in month four
Sending messagesA queue, a template, a send buttonCarrier rejections, retries, quiet hours, opt-out records that survive an audit
PermissionsStaff log in and use itDepartment-level access, and the audit trail asked for after one bad send
The integrationA nightly file or an API readA rewrite at every upstream upgrade, plus reconciliation when the two disagree
OwnershipThe person who built it knows itThat person changes teams, and the next inherits an undocumented service with no tests

The build conversation, line by line

Eamon sells a student communications platform to universities: outreach sequences, scheduling and tracking across admissions and advising. Petra Lindow is Associate Vice President of Enrollment Systems at Thornfield State University, and Idris, one of two developers in her group, has joined the second call. Decisions go out in March, and the ten days after are the year's volume peak.

The call that turns into a build debate:

Idris: Looking at it, this is a scheduler, a message queue and some templates. I think we could put the core of this together in five or six weeks.

Eamon: There is more under the surface than it looks. Carrier compliance alone is a real project, and the quiet hours logic took us most of a year to get right.

Idris: Sure, but we already send texts out of the advising system. That part exists.

Eamon: At your volume in March it behaves very differently.

Petra: Let us take a look internally and come back to you.

Eamon answered the estimate instead of the decision. Every sentence was true and every one landed as doubt about Idris, so Idris defended his number, Petra backed her own engineer, and the call closed with the polite sentence that means nothing further will happen. Three things were never established: whether anyone has time, what it would displace, and who carries it in year two. The deal lost because the only cost quantified was the one on Eamon's quote.

The call that turns into a budget line:

Idris: Looking at it, this is a scheduler, a message queue and some templates. I think we could put the core of this together in five or six weeks.

Eamon: That matches what I would expect, honestly. The first version is the cheap part. Can I ask the boring question instead? If those five weeks started in January, what comes off your list to make room?

Idris: Realistically it would be the degree audit rewrite. That is already late.

Petra: The rewrite cannot move again. The provost asked about it in August.

Eamon: Then the honest comparison is not our price against five weeks. It is our price against the rewrite slipping another quarter. Second question, and Idris is better placed to answer it than I am: in the ten days after decisions go out, if sending stalls at nine on a Tuesday night, who gets the call?

Idris: Me. There is no one else who would know where to look.

Eamon: And in two years, if you are running something bigger by then, who knows where to look?

Idris: That is the part I do not love. It would be one person deep, same as the old transcript tool.

Petra: Which we are still paying for in a different way.

Eamon: Then do not decide against building it on my say-so. Price it properly: five weeks of Idris, a quarter of slip on the rewrite, and a day a week of someone's time forever. If that total still beats our number, build it. I would rather lose to a costed decision than win a deal that gets rebuilt internally in eighteen months.

Eamon did not find a better argument. He stopped arguing. Agreeing with the estimate took the fight out of the room, so Idris had no reason to defend anything and could name the two facts that decide this: the rewrite slips, and he is the single point of failure. A cost the buyer says out loud is one they can repeat in a meeting you are not invited to.

Run it live before your next roadmap review

Set up a discovery call against a technically confident buyer with one rule: say nothing about how hard your product was to build. Work for five outcomes.

  1. Agree with the estimate in your first sentence. It ends the feasibility argument before it starts.
  2. Get a name. Not "your team," but the person who would write it, because a name makes the time real.
  3. Find out what comes off the list. The competitor is whatever gets displaced, usually something with a deadline on it.
  4. Ask who answers at nine at night in year two. Ownership is where internal builds fail, and their engineer knows it better than you do.
  5. Hand the decision back with the full cost named. A buyer who priced the build themselves argues your case internally; one you talked out of it does not.

For your next real call, set the bar at three facts before you hang up: who would build it, what slips, and who owns it in two years. Short of all three, you have not had the conversation. You have been told no in a friendly voice.

Run this scenario for real

ConvoSparr drops you into a live voice call with an AI buyer who runs this exact play. Handle it out loud, then get a transcript, scores, and coaching notes on how you did.

Start practicing free

Free to start. No credit card required.

Keep practicing