By Richard Copeland, CEO, Leaseweb USA
There’s a pattern I keep seeing… and it’s not subtle. Infrastructure buying has gotten fast. Almost too fast.
Teams identify a need, spin up a requirements doc, compare vendors on price, CPU, storage, bandwidth, maybe geography, and move straight to quotes. The whole thing starts to feel like shopping on Amazon. Efficient. Familiar. Low friction.
That’s exactly where things go sideways.
Because infrastructure isn’t a one-time purchase. It’s something you live with. Every day. In production. Under pressure. What tends to happen is teams start with what they think they need to buy instead of stepping back and asking what they actually need to solve. Providers, trying to keep momentum, respond in kind. Pricing comes fast. Specs get validated. The deal moves.
On paper, it all checks out.
Then deployment hits, and reality shows up. Costs don’t behave the way they were modeled. Scaling introduces complexity that no one accounted for. Operations take more effort than expected. What looked clean and straightforward suddenly starts to feel heavier, slower, and more expensive than it should be. The decision is already locked in by that point.
Start with the problem… not the Specifications
The shift is simple, but not easy, if you want to avoid that outcome. You have to slow down just enough to ask better questions up front.
Not “what instance size do we need?”
Not “who has the best price per core?”
Start with something more fundamental, like… what problem are we actually trying to solve? It’s where most teams gloss over the details, even though that sounds obvious.
Cost optimization leads you down a very different path than performance. Data sovereignty is a different conversation entirely from operational flexibility. If you don’t define that early, you end up optimizing for the wrong thing.
Then there’s the operational side.
What is this going to require from your team?
Migration always looks clean in a plan. In reality, it pulls in engineering time, coordination across teams, and a level of effort that rarely gets fully accounted for. The technical move might be possible. The question is whether it’s practical.
Timeline is another one that gets underestimated.
Infrastructure changes don’t happen overnight. Not when legacy systems are involved. Not when hybrid architectures are part of the equation. Delays aren’t surprises. They’re guarantees, if you don’t set expectations early.
Next, there’s the question no one wants to ask until it’s too late. When something breaks, who is actually going to help you fix it? Because it will break. That’s not a knock on any provider. That’s just how systems behave at scale. The difference between a minor issue and a major disruption usually comes down to the people behind the infrastructure, not the infrastructure itself.
The return of physical reality
For a long time, the industry sold a very clean narrative. Everything is abstracted. Everything is elastic. Everything scales on demand.
For some workloads, that still holds.
However, underneath all of it, nothing about infrastructure stopped being physical. Power still matters. Data center capacity still matters. Networking still matters. Hardware supply chains still matter.
You’re seeing that become visible again, especially with the rise of AI and data-heavy workloads. Demand for compute is growing faster than a lot of people expected, and suddenly constraints aren’t theoretical anymore. Teams that understand that, early in the process, make better decisions. They plan for it. They build around it.
The ones that don’t, end up reacting to it later, usually when the stakes are higher.
Alignment isn’t optional
Another place where things quietly fall apart is stakeholder alignment.
Infrastructure decisions don’t live in a single team anymore. They cut across the entire organization. IT leadership, engineering, security, compliance, finance, the business side. Everyone has a stake, whether they’re in the room early or not. When they’re not aligned, it shows up fast.
Projects get approved and then stall. Engineers push back on decisions they weren’t part of. Finance questions assumptions that weren’t clearly defined. Security introduces requirements late in the process that change the architecture.
None of this is unusual. It’s actually very common.
The teams that avoid it do one thing differently. They bring those perspectives in earlier. They tie infrastructure decisions directly to business outcomes so everyone understands what’s being solved and why it matters.
That alignment doesn’t slow things down. It prevents bigger slowdowns later.
What this really comes down to
At a high level, the shift is pretty clear.
Infrastructure decisions are moving away from product selection and toward operating model design. That means the conversation has to evolve. Instead of focusing only on specs and pricing, the more useful discussions look at how everything works once it’s live. Where workloads should sit. How systems scale under pressure. What skills are required internally. How risk is managed. How compliance is maintained. That’s where the real value shows up.
This is because the companies that get this right don’t just end up with infrastructure that works. They end up with infrastructure they can actually operate, adapt, and grow without constant friction.
That doesn’t come from moving faster through procurement. It comes from spending a little more time in discovery, asking the right questions, and being honest about what it’s going to take to make it work in the long term.
What to do next (before you sign anything)
None of this is complicated. It just requires a little discipline at the front end instead of cleaning up a mess later. If you’re about to make an infrastructure decision, run it through this filter first:
A simple pre-purchase checklist
If you can’t answer these clearly, you’re probably not ready to buy yet.
- In one sentence, what problem are we solving?
- What matters most (pick one): cost, performance, flexibility, or compliance?
- What does “working” look like 6 months after deployment?
- How much internal time will this actually require to deploy and operate?
- What breaks first when we scale this 2–3x?
- What assumptions are we making about costs that haven’t been tested?
- Who owns the outcome when something goes wrong? Us or the provider?
If you’re hand-waving through any of those, you’re optimizing for speed, not outcomes.
The questions most buyers don’t ask vendors (but should)
This is where you separate a smooth sales process from a system you can actually live with. Ask them directly:
- “Tell me what happens when it fails.”
- “Where do customers typically underestimate cost or effort?”
- “What does scaling actually change operationally for my team?”
- “What parts of this still require manual work?”
- “Who is on the hook during an incident, and how fast do they respond?”
- “What kind of customer churn is seen after deployment, and why?”
If the answers are vague, polished, or overly optimistic… that’s a red flag.
A quick decision matrix (keep it brutally simple)
Score each option from 1–5 across these categories:
- Fit to the actual problem
- Total cost (not just initial pricing)
- Operational complexity
- Scalability under real conditions
- Support and accountability
Then weight them based on what you said matters most.
If cost is your priority, it gets the highest weight. If uptime is the business, then performance and support carry more weight.
Infrastructure decisions don’t fail because the technology doesn’t work. They fail because the operating reality wasn’t thought through. The teams that get this right don’t move the fastest. They ask better questions early, make fewer assumptions, and choose systems they can actually run… not just systems that look good in a proposal.
Do that, and everything downstream gets easier.
##
ABOUT THE AUTHOR
About Richard Copeland, CEO, Leaseweb USA (https://www.leaseweb.com/):
Richard Copeland is the Chief Executive Officer of Leaseweb USA. He is responsible for managing the company’s business across nine data center locations throughout the United States while executing and developing the company’s vision and strategy in the region. For over 20 years, Richard has held key sales leadership and account management roles within Leaseweb USA and Verizon Business. Richard holds a Bachelor of Science degree from Virginia Commonwealth University. He is passionate about working with his team to achieve company goals, maintaining employees’ work-life balance, and ensuring customer satisfaction.
