On the last Monday of September, I saw the same build vs buy decision from both sides of the table, a few hours apart.

In the morning, one of our customers called to say they would end a service we run for them. From January, a team elsewhere in their group would have spare capacity, and the decision to move the work there had come from group level. Our contact told us several times how satisfied they had been. They wanted us to hear it from them directly before the formal letter arrived.

Around midday, I replied to a software company that had offered us their platform, even under our own brand, instead of the module we had launched a few weeks earlier. I wrote that we would continue with our own solution for now and that we would meet in the market.

Looking back, we made the same call as the customer who left us. Both of us chose to build, and neither of us did it because the alternative was bad.

What Actually Decides Build vs Buy?

In both of our cases, the deciding factor was not product quality. It was control and capacity: whether the work sits close to the core of the business, and whether someone inside has the time to do it. Cheaper building lowers the second barrier, and it lowers it for every company at the same time.

This was not a one-off. With larger customers, we keep losing to internal solutions. A few years ago, the internal alternative was usually a spreadsheet. Today it is often a tool someone built with an AI assistant, or, as in this case, a team that suddenly has time.

I wrote recently about what happens inside a product team when building gets faster than learning. The same shift is now visible from the outside. Our customers can build faster too.

Why We Said No to Buying

The software company was open about its position. They want to stay a pure technology provider, without consulting or operational services. That made our decision easier. The services around our software are a large part of what our customers pay for, and they are what makes switching harder.

The more uncomfortable part is why we started building in the first place. Manual work was piling up in our own customer success team, and customers kept asking for help with it. We had a problem close to our core and people who understood it, which is the same logic our customer followed.

Joel Spolsky made this argument back in 2001 in In Defense of Not-Invented-Here Syndrome: if something is a core business function, you should “do it yourself, no matter what.” What I had underestimated is how much the definition of core depends on who is looking. For us, the module is core. For our customer, I suspect our service was close enough to their core that it came back the moment they had the people.

What Is Left to Sell When Building Gets Cheap

I do not think the answer is to fight internal builds. Three things are changing in how we look at them.

First, an internal build is a signal, not only a lost deal. A customer who spends their own people on a problem is telling us the problem is real. At our last quarterly meeting, I asked the team to tell us whenever a customer builds an internal tool, because that is product-market fit talking. In a recent interview with a large prospect, one of the first things we wanted to understand was why they build it themselves.

Second, I would now watch capacity, not only satisfaction. Our customer did not leave because they were unhappy. They left because people became available. A reorganisation or a team losing its main task can tell you more about the next cancellation than a satisfaction score.

Third, we want to put more weight on what customers do not want to own: the responsibility for getting it right, keeping up with changing rules, and the connections to other systems. With the software company, the part that stayed open is a shared way to exchange documents between our platforms, because email does this badly today. That might turn out to be a more useful collaboration than putting our logo on their product.

I am still learning which parts of our work customers see as their core. But I now want to ask that question before the contract, not after the call.

When building gets cheap, customers keep paying for what they do not want to own.