The Build vs. Buy Decision Has Nothing to Do With Technology

At Ford, I led a comprehensive analysis to decide whether to invest in enterprise data centers or move everything to the cloud. Half a billion dollars on the table. Nine countries. The decision would shape the company’s infrastructure for the next decade.

Last month, I chose Vercel to host a personal website. Took about ten minutes.

Both were build-vs-buy decisions. The same framework applied to both. The difference was stakes, not process.

One-Way Doors and Two-Way Doors

Amazon’s culture drilled this lens into me, and it stuck: is this a one-way door or a two-way door?

One-way doors are hard or impossible to reverse. A $500 million data center investment. A core architecture choice that every system will depend on. A vendor contract that locks you in for years. These deserve months of analysis, detailed scoring criteria, and rigorous evaluation. You can’t walk through this door and walk back.

Two-way doors are reversible. Your hosting platform. Most SaaS tools. A database choice for a new microservice. These deserve a quick evaluation and a decision. If it’s wrong, you switch. The cost of being wrong for a few months is almost always less than the cost of debating for a few months.

Most teams treat every decision like a one-way door. That’s how you end up with six-month vendor evaluations for a tool that costs $200 a month.

A Framework for Build vs. Buy Decisions

What I add to the door framework: a weighted scoring matrix with a political layer. For one-way door decisions, I build objective scoring criteria that map to what actually matters — not vendor marketing, not the loudest voice in the room, not what the last company used.

At Ford, the data center evaluation weighted factors like: total cost of ownership over 10 years, capacity for the ML and AI workloads we were planning, compliance requirements across 9 countries, operational complexity, migration risk. Each criterion had an objective score. Then I layered in the subjective factors — organizational readiness, team capability, political dynamics — because ignoring those is how technically correct decisions fail organizationally.

For two-way door decisions, I skip most of that. Does it work? Can we switch later if it doesn’t? Ship it.

Where Teams Get Stuck

The build-vs-buy debate paralyzes teams because it feels like a technology decision when it’s actually an organizational decision. The right answer depends on:

Is this capability a differentiator? If the thing you’re evaluating is core to what makes your product different, build it. You need to own the roadmap, control the iteration speed, and understand how it works deeply.

Is this plumbing? Authentication, payments, email delivery, hosting — buy it. Every hour your team spends rebuilding Stripe is an hour they’re not spending on what makes your product unique.

The trap is when teams convince themselves plumbing is a differentiator. “Our authentication needs are unique.” They almost never are. The other trap is outsourcing your differentiator to a vendor — then you’ve handed your roadmap to someone who doesn’t care about your product.

The Honest Part

I’ve gotten this wrong. At one company, I recommended building something internally that should have been a vendor solution. The team spent months on it. The result was technically fine and organizationally expensive — we’d used engineering capacity on plumbing instead of differentiation. The lesson: my bias is toward building. I have to actively check it.

Knowing your bias is part of making the decision well. That team spent months building something I should have told them to buy. I think about that wasted capacity every time I’m tempted to say “let’s just build it” — and sometimes I still have to catch myself.