Decide When to Build or Buy Core Cloud Infrastructure

When we debate building an internal solution versus adopting a managed service for core cloud infrastructure, we make the call by looking at where our team's time actually goes after the initial build. The single criterion that changed how I decide is separating billable versus non-billable hours, so we can see whether we are investing in customer value or accumulating internal overhead. If the internal path consistently drives up non-billable time through maintenance, rework, and coordination, that is a signal we should simplify and consider a managed service. If we can keep that overhead contained and the work directly supports what clients need from us, building can make sense. The key is to use the time split to drive a decision, not to create another dashboard.

The single criterion that changed how I decide between building internally and adopting a managed service is simple:

Who owns the failure when the system is down?

Early in my career, we adopted managed platforms thinking they would reduce operational load. On paper, they did. Fewer components to maintain. Fewer updates to track.

But during incidents, the responsibility didn't disappear. It shifted.

Vendor dependency meant waiting for support. Waiting extended recovery time. And the local team still carried the pressure, but without the authority to act.

I remember sitting on an incident bridge where dashboards showed the managed component as "healthy," while service recovery depended on escalation chains we didn't control. That moment changed how I evaluate these decisions.

Since then, I evaluate build vs buy through a failure lens. Not features. Not pricing. Not convenience.

Operational ownership during failure.

Infrastructure decisions are not tested during deployment.
They are tested during failure.

We used to frame it as a cost or control decision—build if it's cheaper long-term, buy if it's faster. That turned out to be the wrong lens.

What changed our approach was focusing on **operational burden over time**, not just initial effort or cost.

The question we ask now is: *does running this ourselves create ongoing work that compounds every month?* Not just maintenance, but on-call load, edge cases, upgrades, security patches, and the need for internal expertise. If the answer is yes, we lean heavily toward a managed service—even if building looks attractive upfront.

One case that shifted our thinking was around a core data pipeline component. We initially built it in-house because it gave us flexibility and seemed straightforward. Over time, it became a constant source of small issues—nothing critical, but enough to drain engineering time and attention. We eventually replaced it with a managed solution that was less customizable, but far more predictable.

The net result was that engineers stopped thinking about that layer entirely, which is exactly what you want for infrastructure.

The key lesson is that infrastructure isn't just about capability—it's about what you're choosing to own long-term. If it's not a core differentiator, the hidden cost is usually in the ongoing operational drag, not the build itself.

The single criterion that changed how I decide is asking whether the capability is actually a differentiator or just plumbing. Early in my career I'd default to building because it felt like more control, but control without strategic value is just maintenance debt waiting to happen.
A few years ago, we built our own in-house messaging layer because we were convinced we had unique requirements. Two years later we realized 90% of what we had reinvented was already sitting in AWS SQS, working better than ours, with a full team maintaining it for free. We ripped it out and migrated. The hours we got back went straight into product work that actually moved the business.
Now my first question is always the same. If this capability disappeared overnight, would our customers notice? If yes, build it. If no, buy it. Engineering time is the most expensive resource in any company, and quietly burning it on undifferentiated infrastructure is the most common failure mode I see in technical leadership