Most of Your Infrastructure Can Be Standard. Some of It Shouldn't Be.

A renewal is coming, or you are staring at a stack that grew fast and was never reexamined. Either way, not every part of it deserves the same scrutiny. Knowing which parts do is the actual skill.

The Default Still Has to Earn the Decision

Technology teams do not have unlimited time. Not every infrastructure choice gets rebuilt from first principles, and it should not. That is a reasonable way to run a technology function.

The problem starts when standard becomes the reason for a decision instead of one input into it. Once enough people choose the same provider, region, or architecture, that choice stops getting questioned, not because anyone proved it was right for your business, but because consensus itself lowers how much scrutiny a decision gets. That is the mechanism worth naming. It does not require a vendor to behave badly. It only requires enough other buyers to stop asking questions first.

Not Every Technology Choice Deserves Equal Scrutiny

The instinct after hearing that is to interrogate everything. That is not what this is asking for. Most of your stack can run on the default and be fine. The work is finding the small number of decisions where accepting the default without comparison could materially affect the business, and treating those differently.

Find Where the Business Actually Feels It

A technology decision deserves more scrutiny than the default gets it when it changes one of the following.

Cost. Could this materially change your unit economics or operating expense at scale, not just this year’s invoice.

Resilience. Does a failure here stop revenue, operations, or customer access, not just an internal dashboard.

Customer experience. Can performance here directly change what your customers experience, not just what your engineers experience.

Flexibility. Will this decision make it hard to shrink, change direction, migrate, or renegotiate later, if the business needs to. In practice, most committed cloud spend agreements do not move even when the business does, no matter how flexible the sales conversation made them sound.

Concentration. Are several important systems depending on the same provider, region, platform, or contract, so one failure becomes many.

Competitive advantage. Could doing this differently materially improve your economics, your service, or your ability to compete with someone who is still renting the same function.

If getting one of these wrong would materially hurt the business, the default has earned a comparison. If none of them apply, leave it on the default and move on.

Netflix Controlled the Part That Mattered

Netflix is a useful case because it did not treat this as all or nothing. Its website, signup flow, recommendations, and much of the rest of the business run on AWS. But viewed through the filter above, its decision is easy to understand. Video delivery was both a major cost lever and a major customer experience lever at the same time. More than 95 percent of Netflix’s streaming traffic is delivered through Open Connect, its own delivery network, giving the company direct control over a strategically important part of delivery, an advantage a competitor still renting that function cannot easily match.

A Different Company Can Reach a Different Answer

37signals ran a similar test and landed somewhere else. In 2022 its cloud bill hit 3.2 million dollars a year. It bought its own hardware and moved seven applications off AWS, bringing that number down to around 1.3 million dollars, a savings of roughly 2 million dollars a year. The hardware paid for itself within the year, and a projected 7 million dollars in five year savings is now tracking past 10 million.

Netflix kept most of its architecture in the cloud and took control of one strategically important layer. 37signals moved seven applications off AWS after the economics stopped making sense. Different answers, same discipline: neither treated the accepted option as automatically correct.

Popular Does Not Mean Risk Free

In October 2025, AWS’s US East 1 region went down for about 15 hours, and the disruption reached well beyond AWS customers directly, Snapchat, Ring doorbells, and a foreign government’s tax filing site were all affected. A widely adopted architecture can still create shared concentration risk. Popularity does not remove the need to understand what you are depending on.

Before You Commit, Ask Compared to What

Every decision that clears the filter above deserves one more question before you commit. Compared to what. If you never ran a credible alternative against the default, the evaluation is not finished.

This test comes straight from Max’s breakdown of the same pattern in Playbook: Buy on Purpose, worth fifteen minutes if you want the full mechanism behind it, not just the framework.

Existing infrastructure decisions are easy to inherit. The provider is already approved, the architecture already works, and changing it creates new work and new risk. That makes renewal the easiest moment to re-test whether the original reasoning still holds. ITBroker runs that comparison from the buyer’s side, without a vendor relationship determining the answer.

If a renewal is coming up and nobody has gone back to ask whether the original decision still holds, this is where that conversation starts. It covers what changes once a decision that was never actively made gets locked in again by default.

If you can name the two or three decisions in your stack that meet the filter above, you have done the important part. If you cannot, that is worth finding before the next renewal decides it for you.

Before vendors shape the direction. That’s when Strategy matters most. Get Started.

No pitch. No prep. Just answers.