Build-Buy-Partner

Building was the default for a long time. Payments got built in house, so did email delivery, and so did video calls. The company was full of people who knew how to build things, so building felt natural, while buying from outside looked like spending money on something you could do yourself.

Meetings asked only one question as a result. "How long would it take us to build that?" A product manager asked, an engineer said three months, and three months went on the calendar. Nobody asked what a finished version cost on the open market, or whether plugging one in would take two weeks instead. The payment feature built that way took six months, and what came out was harder to use than what was for sale.

Leaning the other way created its own problem. A product assembled entirely out of other people's parts shipped a screen in six months but couldn't answer which part of it belonged to the company. Competitors could buy the same parts, so catching up didn't take long.

Build-buy-partner exists to open that question into three branches instead of two and hold them to the same standard. Once building, buying, and partnering sit side by side, a decision that used to turn on "how long" picks up a different question: is this something we need to be good at?

The decision runs in five steps, and it runs on one capability at a time. Compare a whole product and the three options stop being comparable.

1. Write down what's needed in one line. Not "payments" but "charge a monthly subscription to a card and retry when it fails" — otherwise the three quotes describe three different things.
2. Check whether the capability is a differentiator. A differentiator is a strength competitors can't easily copy. If it's part of why customers chose you, build it; if it isn't, buy or partner. This one line usually settles the remaining four steps.
3. Put all three options in the same unit. Building means two engineers for six months, so roughly $115,000 in salary; buying runs $30,000 a year; partnering costs 2.5 percent of transaction volume. Add running costs on top. Anything built in house keeps asking for attention every year after it ships.
4. Count the cost of reversing. Write down what switching would cost if the vendor doubles its price or shuts down in three years. That number gets large when your data accumulates on their side.
5. Record the reason and the date you'll revisit it. Something like "buy for now, and look at building again once this capability touches 30 percent of revenue."

The three branches behave differently. Building costs the most time and buys the freedom to change anything. Buying trades money for time, and the connection usually runs through an API — an agreed interface between programs. How open that interface is decides how much you can adjust later. Partnering, the branch usually called a partnership, trades customers or channels rather than cash. It costs the least and is the only branch you can't decide alone, because the other side has to agree.

This works best where other people have already built something good. Payments, login, email delivery, video calls, maps — capabilities whose requirements look about the same at every company. A capability that solves a problem only your customers have has nothing available to buy, so the comparison never runs.

The limitation is that the numbers tilt. Put cost and schedule in a table and buying wins almost every time, because three things never make it into the table. The first is how tightly you get tied to the vendor. Once a price increase can't be escaped, the vendor sets the price. The second is that your service becomes only as reliable as theirs. When they go down you go down, and the compensation written into an SLA is usually a credit worth about a month of fees, which doesn't bring back the customers who left. The third is customer data piling up on someone else's servers.

Timing is a limitation too. Ten times the usage pushes the cost of buying past the cost of building, and the answer flips. Skip the reversal cost in step 4 and the review date in step 5 and the whole exercise spins without going anywhere.

"Could you put this through build-buy-partner for me?"

A request to line up all three options in one table with cost, schedule, and switching cost side by side.

"That's not a differentiator for us, so let's buy it."

A judgment that there's no reason to build it, and at the same time a declaration that improvement requests in that area won't be picked up.

"Partnering is the cheapest, but why would they want to work with us?"

A reminder that this branch isn't ours to choose — the other side has to say yes.

The quarter Pagedeck added payments for enterprise customers looked like this. Mia put the three options on one page. Building meant two engineers for six months, a payment processor charged 2.5 percent of volume, and an accounting service would take no fee at all in exchange for sharing the customer list.

Grace picked the second one, and the reason was sequence rather than price. A delay in payments pushes paid conversion itself out by ten months, and the revenue lost over those ten months was larger than the fees. She added one line to the document: once monthly volume passes $750,000, the fees exceed the cost of building, and the decision gets reopened then.

The most common mistake is reading it as a one-time choice. A table was built, a meeting was held, a conclusion was reached, so it looks finished. But the numbers move with scale. Ten times the transaction volume means ten times the fees while the cost of building stays flat, so last year's answer is wrong this year. Without a review date nobody reopens it, and the fees keep going out for several more years.

Reading it as a way to pick the cheap option is common too. Choosing whichever branch costs less today seems like the point. What the framework actually asks is where your time goes. An area you decide to build is an area you're committing people to for years; an area you decide to buy is one you're taking your hands off. Chase the cheap branch every time and nothing is left that you can change, and you end up assembling the same product out of the same parts as your competitor.