"Build versus buy: how a venture studio decides"

Every studio faces this choice on every venture, and most of the advice about it is useless because it treats the two paths as interchangeable options on a menu. They are not. Building and buying fail in opposite directions, and the decision is really about which kind of failure you are equipped to survive at this particular moment.

The two risks

Building carries demand risk. You can execute perfectly and still discover that nobody wants the thing. All of your effort sits in front of the answer, and the answer arrives late. What you get in exchange is exactly the product you intended, no legacy decisions, and a clean cap table.

Buying carries diligence risk. Demand is already proven, because people are paying. What you cannot see from the outside is why they are paying, how long they will keep paying, and what is quietly broken underneath. The revenue is real. The question is whether it is durable, and you are making that call on incomplete information under time pressure.

Notice these are not two flavors of the same risk. Demand risk is a question about the world. Diligence risk is a question about a specific asset. You reduce them with completely different work.

What actually drives the decision

Three factors, in order of weight.

How certain is the demand? If we have talked to twenty potential customers and heard the same specific complaint twenty times, demand risk is already low, and building is cheap insurance against inheriting somebody else's technical decisions. If we are working from a hunch, buying lets the market answer the question before we spend a year on it.

What does the studio have too much and too little of right now? This is the least discussed input and often the deciding one. A studio with engineering capacity and no cash should build. A studio with cash and no free engineering attention should buy. Ignoring this produces the classic mistake of buying a product that then needs a rewrite nobody has time for, which is the worst of both paths.

How long can we wait? Building puts revenue somewhere past the horizon. Buying puts revenue on day one. If the studio needs a venture to contribute cash inside a year, that constraint decides the question on its own, whatever the other factors say.

The tests we run either way

Whichever path we are on, the venture has to clear the same four filters before we commit time or capital.

Is the problem durable? Will someone still pay to solve this in five years? This rules out most things that are exciting this quarter. A problem tied to a platform shift, a regulatory quirk, or a temporary gap in someone else's roadmap is a problem with an expiry date, and you inherit that date.

Does the revenue recur? One time revenue means starting every month at zero. Subscription and usage models compound, and compounding is the entire thesis.

Is there a path to profit that does not require raising again? We are not underwriting a company that only works if a stranger agrees to fund it in eighteen months. That is a bet on the funding market, not on the business.

Does the product earn a habit? Daily or weekly beats quarterly. A product people open once a quarter is a product they can cancel without noticing, and churn will quietly eat every acquisition win.

A venture that fails any of these is a no regardless of how clever the acquisition price is or how much we like the idea.

What we look at when buying

If we are buying, the four tests above get supplemented with diligence on the things that do not appear in a listing.

Revenue concentration. Ten customers paying the same total as four hundred customers are not the same asset. One of those is a business, the other is a relationship that can end in a single email.

Why people churn, in their words. Aggregate churn is a number. The reasons are the signal. Churn caused by a fixable onboarding gap is an opportunity. Churn caused by the product not actually solving the problem is the whole thesis failing quietly.

What the code costs to keep alive. Not whether it is elegant. Whether a new team can safely change it. A codebase that only its author can modify is a codebase with a person shaped dependency you are also buying, and that person is usually leaving.

Where the customers come from. Acquisition that depends on one channel, one integration, or one partner is a business with someone else's hand on the tap.

What the seller is optimizing for. Someone selling because they are bored is a different situation from someone selling because they can see something coming. Both are fine. Knowing which one you are in is not optional.

The mistake we watch for

The most expensive error in this decision is not picking wrong. It is picking for the wrong reason and then not noticing.

Building because you enjoy building is the common version. It feels like conviction and it is actually preference. The tell is when the build case rests on the product being better rather than on the demand being certain, because "better" is a claim you get to make without evidence and "certain" is not.

The buying version is subtler. Buying because revenue is reassuring, when the revenue is real but the problem underneath it is not durable, gets you a business that looks healthy on the day you close and declines slowly enough that you can always find another explanation.

The protection against both is writing the reasoning down before the decision, with the specific thing that would change your mind, and then rereading it in ninety days.

Why studios do both

A studio that only builds carries concentrated demand risk across every venture at once, and all of it resolves late.

A studio that only buys is dependent on deal flow it does not control, competing against buyers who do this full time, in a market where the good assets are priced accordingly.

Running both paths means the risks are not correlated. An acquisition can carry the studio through the long middle of an originated venture, and an originated venture can be exactly the thing an acquisition market has no supply of. That balance is a large part of why the model works at all.

The venture studio playbook covers where this decision sits in the wider operating model, including the capital structures that make one path more viable than the other.