# “We’ll Just Build It Ourselves”: How to Handle the In-House Objection and Log It in Pipedrive

https://salesbond.app/blog/build-it-in-house-objection-pipedrive/
Published: 2026-10-07 · Updated: 2026-10-07

When a buyer raises the build vs buy objection and says “we’ll just build it ourselves”, find out three things before you answer: who exactly will build it, by what date, and what is already written. If none of the three has an answer, you are not looking at a competitor. You are looking at a budget objection wearing an engineering t-shirt. Write that down in the deal, and do not keep the probability high until the internal project has a named owner and a date.

Below is how we run it on a team of four reps selling an integration service to companies with their own IT. The example is illustrative, the figures made up.

## Third call, and the head of engineering has a new idea

Bram had done two good calls with a logistics company: discovery with the ops director, then a demo for her team. On the third call the head of engineering, Elias, joined for the first time. He listened to the pricing for a while, then said the sentence every rep on our team has heard: “Honestly, this looks like something we could knock together in a couple of sprints.”

The ops director didn’t disagree. She didn’t agree either. The call ended ten minutes early with “let us talk internally”.

Bram did what most reps do. He left the deal in Proposal Sent, left the probability where it was, and wrote a note: “possible build in-house, follow up in two weeks”. Then he spent the two weeks worrying about it.

Elias might well have been able to build it. It might also have been the technical version of “send me some information”. Bram couldn’t tell, because he hadn’t asked anything that would tell him.

## Real competitor or polite no: three signs you can check

A real in-house project has a person’s name on it. Not “the team” or “engineering”, but someone who has agreed to build this thing and knows it. If the buyer can’t say who, there is no project yet. There is a sentence.

It also has a date, or at least a slot. Engineers on a small IT team don’t have idle sprints, so if the build is going to happen someone has decided what it displaces. “Next quarter, probably” is not a date. “After the warehouse migration ships in November” is.

The third sign is the strongest: something already exists. A spreadsheet macro, a script from last year, a half-finished connector in a repo. If a buyer says “we’ve actually got something that does part of this”, you have a real alternative. If the answer is “no, but it wouldn’t be hard”, you have an opinion.

Zero out of three means the objection is about money or priority, not engineering. One is still mostly a priority question. Two or three, and you have an internal competitor with a seat at the table.

## Three build vs buy questions that don’t defend the product

The mistake on the call is to explain why your product is hard to build. [Sales Reality Check](https://salesrealitycheck.beehiiv.com/p/we-might-just-build-it-ourselves-just-killed-your-400k-deal) describes the same trap: the rep takes it as an objection to the product and reaches for features, another demo, a discount, when the objection was never about the product. So we don’t defend. We ask about the project as if it were real, and let the answers do the sorting.

The wording is ours; the ground comes from [SmartReach’s response frames](https://smartreach.io/blog/build-vs-buy-objection-handling-saas/) and the [Sales Enablement Collective’s ownership questions](https://www.salesenablementcollective.com/build-vs-buy-the-sales-enablement-playbook-for-technical-objections/).

1. **“Who on your side would own it, and what would they stop doing?”** An honest answer names a developer and the thing that gets pushed. A vague one tells you nobody who would actually do it has been asked.
2. **“What’s the target date for a first working version, and what happens to the ops team until then?”** We ask the ops director, who is still on the call, how long she is willing to keep doing this by hand. She usually answers before Elias does.
3. **“Who takes the support tickets and the integration breakages once it’s live?”** Engineers respect this one, because they know the answer is “me, forever”. Nobody plans the second year of an internal tool.

None of the three mention our product. They are what a good CTO would ask before approving the project. If Elias has good answers, we are genuinely in a bake-off against his team. If he doesn’t, the ops director has just watched her own engineering lead fail to describe a plan.

Bram asked all three on a follow-up call. The answers: “probably Dev A or Dev B, we’d have to see”, “maybe Q1”, and a laugh.

Zero for three.

## What goes into the deal in Pipedrive

The answers go in the deal the same day, in fields rather than a note, because a note cannot be filtered. We keep three custom fields, made in Data fields settings ( [Pipedrive: custom fields](https://support.pipedrive.com/en/article/custom-fields)); only a user with the right global permissions can create them, which on a small team usually means the admin.

- **Competitor**, a custom single-option field we already had for vendor competition. We added the option `Build in-house`, on purpose in the same field: the pipeline report should count internal builds next to the vendors we lose to. The vendor side is in [how to run a competitive bake-off in Pipedrive](https://salesbond.app/blog/competitive-bake-off-pipedrive/).
- **In-house owner** (text). Empty is a valid and informative value. “Elias said Dev A or B” is also informative, and not in a good way.
- **In-house target date** (date). Empty is allowed here too.

The answer to the third question goes in the deal note, with the date of the call. It’s what you will quote back in a month.

Bram’s deal now reads: Competitor = Build in-house, In-house owner = (empty), In-house target date = (empty). A [filter](https://support.pipedrive.com/en/article/filtering) with both conditions under ALL, Competitor is Build in-house and In-house owner left empty, gives the manager every deal where this is happening. That’s a conversation for Monday, not a surprise at quarter end.

If your team keeps a general objection log, “build in-house” goes in it like any other entry ( [objection handling in Pipedrive: log it, then coach from it](https://salesbond.app/blog/objection-handling-pipedrive-log-coach/)).

![Example deal card with Competitor set to Build in-house and the owner and target date fields empty.](https://salesbond.app/wp-content/uploads/2026/10/build-it-in-house-objection-pipedrive-2.png)

## What to do with probability and the forecast

Our position: “we’ll build it ourselves” with no name and no date is a “no budget” objection, and the deal should carry a “no budget” probability. Not zero, because the ops director still has the problem, but not what Bram’s deal showed for two weeks in Proposal Sent while nothing happened.

The rule we settled on is slightly uncomfortable. A Build in-house deal keeps its stage probability only if the owner and date fields are filled and there is a next activity with the buyer that moves the decision (not a “check in” call). Otherwise the rep sets the deal probability by hand to whatever the team uses for deals with no committed budget, with a note on the deal saying why. That only works if an admin has turned on deal probability in the pipeline settings; without it every deal carries its stage probability ( [Pipedrive: how to set deal probability](https://support.pipedrive.com/en/article/how-can-i-set-deal-probability)). Why the note matters more than the number is in [deal probability vs stage probability in Pipedrive](https://salesbond.app/blog/pipedrive-deal-probability-vs-stage-probability/).

The expected close date moves to the date the buyer actually gave, in Bram’s case “maybe Q1”. An honest close date in January is worth more to the forecast than a hopeful one in October.

Reps push back on lowering a number when the buyer was friendly. But a friendly buyer hasn’t said yes, and the forecast is for the manager and the owner, not the rep’s morale. The in-house objection is one of the most common costumes of [no-decision deals](https://salesbond.app/blog/no-decision-deals-pipedrive/).

This is also where deals go quiet. The rep has asked the questions, filled the fields, and now waits for Elias, who is not thinking about it. We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Its Deal Health checks every deal against the rules a team has switched on, so deals that break the activity or close-date rules show up on the manager’s list with the reason attached. You still have to ask the three questions yourself. To see which of your open deals are sitting like this right now, [check your CRM with SalesBond](https://salesbond.app/).

## When the project is already running

Sometimes the answers come back solid. There is a developer, she has a sprint, the connector is half-built.

Ask for one thing and step back: the target date for the first working version, written into the In-house target date field and the expected close date. Then schedule exactly one activity, a call with the ops director two weeks after that date. Chasing an engineer mid-build makes you the vendor who didn’t believe them and if the build ships on time you have lost anyway. If it slips (internal projects slip), the ops director hears from someone who respected the plan.

If the build ships and works, mark the deal lost with `Built in-house`, a reason separate from `Chose competitor`, because the two say different things about our pitch and a year of them says a lot about our ICP. More in [Pipedrive lost reasons that actually get used](https://salesbond.app/blog/pipedrive-lost-reasons/) and [win/loss analysis for a small team](https://salesbond.app/blog/win-loss-analysis-small-team-pipedrive/).

Bram’s deal, by the way, closed in February. The ops director called him when Q1 planning came round and nobody had started on the the connector. Nothing in the pipeline had predicted that, and nothing should have. What the pipeline had done, for four months, was tell the truth about it.