# When the customer says "we could build this ourselves": change the question, don't argue

> This objection is rarely aimed at your product. It shows the customer is worried about who will own the system, and that is a chance to bring them onto your side.

Original: https://fdetimes.net/en/guides/handling-we-can-build-it-ourselves/

Picture the first week of a deployment. In a meeting, the customer's head of data engineering opens his laptop and shows the room a demo he wrote over the weekend: it calls an LLM API directly and summarises support tickets quite neatly. Then he asks: "Our team could build this ourselves, so why should we buy?"

This is where many FDEs give the wrong answer. Some rush to defend the product feature by feature; others pull out numbers to prove the customer is deluding himself. Either approach may win the argument, but the price is losing the most important person on the project.

The irony is that the way FDEs work invites this question. PostHog describes the FDE as someone who sits inside the customer's team and builds prototypes fast, accepting that they are rough.

When a customer sees something working after a few days, thinking "we could do that too" is natural. And the person asking you is very likely the one who will run the system after you leave.

## Why start with "yes"?

"We could build it ourselves" is rarely just a technical point. It carries professional pride, a fear of vendor lock-in, and sometimes pressure from above for the internal team to do more. A direct rebuttal only touches the outer layer.

So the best answer usually starts with a sincere acknowledgement: yes, your team can build this version.

According to a panel of experts quoted in an article by Gong, build-versus-buy decisions tend to go wrong in exactly one place: people assume a quickly built prototype is already a complete capability.

You acknowledge the prototype, but not the idea that the prototype is the destination.

The next step is to change the question. According to Gong, the question to ask instead of "can we build it?" is where the real differentiation lies. The second: once the excitement about the prototype fades, does the team still want to own that layer?

Researchers at MIT Sloan offer a rule in the same spirit: when you need speed, buy off the shelf, or buy and build on top; build in-house only where it creates distinctive competitive advantage.

**Key point:** Don't argue about whether the customer can build it; ask whether they want to own it.

## The real cost arrives in year two

A weekend demo has no running costs yet, because nobody is running it. MIT Sloan defines "build" as an organisation developing, running and maintaining its own models. The demo has only done the first of those. The other two are where the effort lies.

Turn those two into concrete questions for the ticket summarisation case. On operations: tickets contain customers' personal data, so who decides which data may be sent outside, and who is on call when the system fails at two in the morning?

On maintenance: when the model provider changes versions and summary quality drops, who notices, who fixes the prompt, who reruns the eval suite?

You don't need to answer for the customer. The aim is for that engineering lead to see for himself the list of work sitting behind his demo, and then decide which parts his team wants to take on. Gong concludes that what matters is whether the team is honest with itself about ownership.

## A conversation script to use now

Below is a sample script; adjust it to your own voice.

> **Customer:** Our team could build this ourselves, so why should we buy?
>
> **FDE:** You're right, your demo works well, and your team is perfectly capable of doing it. Let me ask it slightly differently: six months from now, which parts do you want your team to own?
>
> **Customer:** What do you mean?
>
> **FDE:** For example, when the model changes, who reruns the evals, who approves what data gets sent outside, who is on call when something breaks. Whatever is unique to your company, your team should keep. Whatever is just shared infrastructure, we build on the platform so your team doesn't have to carry it.
>
> **Customer:** What's unique to us is how we classify tickets and route them to the right people.
>
> **FDE:** Then your team builds exactly that part, and I'll work on it with you. Let's also agree now who on your side will be responsible after I leave the project.

The script has three beats: acknowledge, move to the ownership question, then hand the customer a real piece of the work. The last line is not a courtesy. It is the handover plan, set out from the first week.

## Map who builds what

After the conversation, turn the agreement into a table both sides can look at, like the comparison table at the top of this article. For each component, write down who builds it, who operates it after handover and the risk if it fails. The risk column matters most, because it shows which parts must have a clearly named owner.

The split follows MIT Sloan's rule. Ticket classification and routing is the customer's differentiation, so the customer's team builds and keeps it. Data connectors, evals and access control are shared infrastructure, so they are built on the platform to move fast.

A low-risk job such as the weekly internal report is a safe place for the customer's team to build on their own and learn. If it breaks, it is a few days late and nobody is really harmed.

Don't expect one customer's table to look like another's. Rocketlane notes that for FDEs there is no one-size-fits-all model, and the same goes for the ownership map. a16z, for its part, cautions that customers don't want to feel stuck in a long consulting engagement. A table that already names the operators shows them the day you step away.

## Common mistakes

The most common mistake is using numbers as a weapon. According to an MIT report covered by Fortune, 95% of generative AI pilots in companies fail. Buying tools from specialised vendors and building partnerships succeeds about 67% of the time, while internal builds succeed only a third as often.

Menlo Ventures also found that 76% of AI use cases are now bought rather than built, because ready-made solutions reach production faster and show value sooner. These figures are worth knowing.

But using them to flatten an engineer who has just shown off his demo only makes him more defensive, so keep them as a reminder to yourself of why the ownership question is worth asking.

The opposite mistake is common too: to keep the customer happy, the FDE promises to custom-build everything. The result is a system nobody can maintain and a project with no end, exactly what a16z says customers don't want. Then there is reaching an agreement without naming the owner, so that when you leave, everything slowly drifts.

One mistake few people notice: treating "we'll build it ourselves" only as an objection to defuse. If several customers all want to build the same layer themselves, that is a signal to take back to the product team.

## Turn this skill into an edge when job hunting

On your CV, don't write "good communicator". Describe specifically how you turned a "build it ourselves" objection into a shared ownership map: which parts the customer's team kept, which were built on the platform, and who operated them after handover.

For interviews, prepare that story in situation, action, result form. A story with a named owner and a clear division of work is more convincing than any adjective you could apply to yourself.

The next time someone opens a laptop and says "our team can do this", you don't need to win that argument. What you need to come away with is an ally, the person who will keep running the system long after you have left the project.

**Try this week:**

- Pick a deployment you are working on and draw a four-column table: component, who builds it, who operates it after handover, risk if it fails.
- Write down three questions about running costs (model changes, data access permissions, who is on call when something breaks) to use the next time a customer says "we'll build it ourselves".
- Write up one time you defused a technical objection as a short STAR paragraph to put on your CV or use in interviews.

## Sources

- [The real build vs. buy question: "Do we want to own this?"](https://www.gong.io/blog/the-real-build-vs-buy-question)

- [MIT report: 95% of generative AI pilots at companies are failing](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)

- [2025: The State of Generative AI in the Enterprise](https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/)

- [How to manage the two faces of GenAI —tools and solutions— for business success](https://mitsloan.mit.edu/node/48409)

- [WTF is a forward deployed engineer? (and why everyone is hiring them)](https://posthog.com/blog/forward-deployed-engineer)

- [The Palantirization of everything](https://www.a16z.com/the-palantirization-of-everything)

- [Forward Deployed Engineering: Finding the Model That Fits](https://rocketlane.com/blogs/forward-deployed-engineering-models)