Build vs. Buy Is the Wrong Question. Ask What You Will Maintain for Five Years.

On 13 March 2013, Google announced it would shut down Google Reader on 1 July of that year. Reader was free, widely used, and for a lot of people the only piece of software they opened every morning. The announcement gave users about fifteen weeks to export their subscriptions and find a replacement. The stated reason was declining usage and a wish to focus on fewer products.

Three years later, on 28 January 2016, Facebook announced it would retire Parse, a hosted backend that it had bought in 2013 for about $85 million and that by then sat underneath roughly 600,000 apps. Developers got one year, an open-sourced server, and a migration tool. Then the lights went off on 28 January 2017.

Neither company did anything wrong. Both products were dependencies that other people had built on, and both were retired on a schedule those other people had no say in. That is what "buy" means over a long enough horizon, and it is the part the build-versus-buy conversation almost never prices.

The debate as it usually runs

A team needs a capability: a reporting layer, a pipeline, a forecast model, a customer data store. Someone proposes building it. Someone else proposes a vendor. The argument that follows is about the first twelve months: license cost versus engineering time, speed to launch, feature fit, what the demo looked like.

That framing treats the decision as a purchase. It is not a purchase. It is a choice between two different maintenance commitments, and the commitments diverge sharply after year one.

If you build, you are committing to maintain code. Someone has to patch it, extend it when the business changes, and understand it well enough to fix it at two in the morning. The person who built it will very likely leave before the code does, and the code will not go with them.

If you buy, you are committing to maintain a dependency. Someone has to own the integration, absorb the vendor's API changes, track their pricing, and plan for the day the vendor is acquired, pivots, or sends the email that Google sent in March 2013. The vendor will change, in price, in product, or in owner, and your reliance on them will outlive the version you evaluated.

Both are real costs. Only one of them tends to appear in the spreadsheet that justifies the decision.

The mechanism

The reason the second cost goes unpriced is structural, not careless.

A build proposal has a visible owner. The engineer who proposes it is standing in the room, and everyone can picture them maintaining it, so the maintenance cost gets discussed even if it gets underestimated.

A buy proposal has no visible owner. The vendor is the implied owner, and the vendor's sales material is careful to say that maintenance is their problem. So the conversation treats the integration as finished the day it is turned on. Nobody is assigned to it in year three, because nobody thought of year three as a thing that needed assigning.

Which is why the failure mode of "buy" is so consistent. The integration works for years. Then the vendor changes an API, or deprecates a plan, or gets acquired, and the team discovers that the person who set it up left in 2024, the credentials are in a mailbox nobody checks, and the only documentation is the vendor's, which now describes a product that no longer exists. The cost arrives all at once, in a quarter that had other plans.

The failure mode of "build" is slower and better known. The code works. The builder leaves. The next person is afraid to touch it. It accumulates workarounds. Eventually someone proposes replacing it, and the replacement conversation starts with "build or buy."

A better question

Replace "build or buy" with "what will we be maintaining in five years, and who will be doing it." The question is boring, which is the point. It forces the two options onto the same footing, and it produces an answer that can be written down.

For each option, write three things. What exists in year three: a codebase, an integration, a contract, a set of credentials. Who owns it in year three, by role, not by the name of whoever is enthusiastic today. And what happens on the bad day: the builder leaves, or the vendor sends the shutdown email. How long does it take to recover, and what runs in the meantime.

Say a reporting layer costs $40,000 to build and $18,000 a year to license. The first-year math favors buying by a wide margin. The five-year math is $40,000 plus whatever the maintenance comes to against $90,000 plus whatever the migration costs when the vendor's roadmap diverges from yours. Both of those "whatevers" are the actual decision, and the exercise above is the only way to put a number on them. The figures here are illustrative. Yours will differ, and the point is that you should know them.

Where the debate usually hides the real issue

In my experience, when a build-versus-buy argument runs long, it is rarely about cost. It is a proxy for an ownership question nobody wants to settle: who is going to be responsible for this thing when it breaks. Building assigns that responsibility to the engineering team, and they often resist. Buying appears to assign it to the vendor, which is why it is attractive, and which is also why the year-three failure is so reliable: the responsibility was never assigned to anyone inside the building.

Settle the ownership question first and the build-versus-buy question usually answers itself. If there is a team willing and able to own code for five years, building is often cheaper and the control is worth it. If there is not, buy, but assign an internal owner to the dependency on day one, with the explicit job of reading the vendor's changelog and planning the exit. That owner costs a few hours a quarter. The Parse developers who had one spent 2016 migrating calmly. The ones who did not spent January 2017 in a panic.

What to do Monday

Take the one dependency or the one homegrown system that would hurt most if it failed. Write down who owns it in year three. If the answer is a vendor, write down who inside the company owns the vendor relationship, and when they last read a changelog. If the answer is a person, write down what happens when that person leaves.

If any of those lines is blank, that is the project, and it is not a build-versus-buy project. It is an assign-an-owner project, which is shorter, cheaper, and the thing the original debate was avoiding.