A team plans its own infrastructure, draws a quarter-long schedule, and misses one thing: hardware does not arrive when you order it. In 2026 the lead times on GPUs and on some server parts are such that they are not a line in the budget but an architectural constraint. We plan around the supply chain on every deploy contract, and below we cover what that looks like in practice.
Lead time is part of the architecture
Standard planning treats hardware as instantly available: pick a configuration, budget a price, and "procurement will handle it." But if a deploy depends on hardware that ships in 8 to 12 weeks, lead time decides the launch date more than any engineering choice. An architecture you cannot get on time is not an architecture but a wish.
So we cost lead time alongside performance and price. Sometimes the right choice is not the best card on the spec sheet but the one in stock in the right region on the right timeline. The best configuration that arrives after the window of opportunity loses to a middling one that is ready now.
What lead times look like in 2026
The picture differs by hardware class:
- GPUs for AI and ZK remain the tightest bottleneck. Recent cards go by allocation, lead times jump, and scarcity at peak demand is real. Planning a GPU deploy as "we'll order it when we need it" in 2026 means regularly missing the window.
- Server CPUs and memory. EPYC-class platforms and DDR5 in the volumes you need are no longer "off the shelf tomorrow" but weeks. Not a catastrophe, but it has to be in the schedule.
- Colo and racks. A colocation contract in a new country is 4 to 6 weeks of negotiation in the calm case, and legally longer in some jurisdictions. The rack space and cross-connects do not appear instantly either.
It all adds up to a simple thing: deploying on your own metal in a new geography is not days but months, and most of those months is not racking but waiting.
Why we keep some capacity in cloud for exactly this reason
Scarcity and lead times are one of the main reasons we deliberately keep some capacity in cloud, even knowing it is more expensive than metal long term on cost-per-token and on slot-month. Cloud is the way to start now while the metal ships, and to cover an urgent window the supply chain physically cannot meet. When you need a node or a card "yesterday," a provider's regional edge solves it in minutes, and that is the right choice despite the per-hour premium.
The hybrid here is not a compromise but an answer to the supply chain: a flat base on metal ordered in advance for predictable load, and cloud for what is needed faster than metal ships.
Vendor diversity and RMA
Lead time hits not only at the start but in operation. If the whole fleet is on one vendor with one platform, that vendor's shipping delays and RMA queue become yours. One problematic vendor slows both expansion and replacement of failed hardware.
So we keep several vendors and platforms and know in advance who has what available and on what timeline. Replacing dead hardware is also supply chain: the hoster's shelf stock and their RMA queue decide how fast a dead drive stops costing you missed slots.
How this affects your plan
On the polygon we keep a current picture of availability and lead times across vendors and regions, because we test it on our own procurement. On a client contract this becomes an honest schedule: what we order in advance, what we start in cloud while the metal ships, where we move to metal once it arrives.
If you are planning your own infra and want a schedule that accounts for real lead times rather than assuming instant hardware, that is part of what we cover through deploy on our infrastructure. Want to reconcile a deploy plan with lead times for your geography: get in touch.