Semiconductor supply is a structurally slow system. Fabrication capacity takes years and enormous capital to add, which means demand shifts get absorbed by price and lead time long before they get absorbed by supply. For anyone shipping hardware, or renting compute, that lag is the whole story.
Why the cycle is long
A new fabrication plant is a multi-year, multi-billion commitment made on a forecast of demand at completion, not demand today. Get that forecast wrong in either direction and the correction takes years, because there is no way to add a little capacity quickly. Layered on top are geographic concentration, packaging and substrate bottlenecks that are separate from wafer capacity, and export policy that can move in a week. The result is a market where the price signal arrives long before the supply response does.
The other structural point is that leading-edge and mature nodes behave differently. The chips in the news are the advanced ones, but the parts that strand a product are usually unglamorous: power management, microcontrollers, connectivity modules, and the passive components nobody lists on a spec sheet. Shortages in those are what actually stop a production line.
How it reaches software teams
- Hardware products face long, volatile component lead times and forced substitutions.
- Accelerator scarcity raises both the price and the queue time of AI compute.
- Cloud instance families quietly change availability by region, so the instance type your infrastructure code names may not exist where you need it.
- Client capital budgets tighten when their own hardware costs rise, and a delayed device programme delays the software attached to it.
- Device replacement cycles lengthen, which changes the hardware your users are actually holding.
That last point is the one that reaches a Nepali team most directly. When device prices rise, and import duties are already a significant part of the shelf price, people keep phones for longer. A roadmap that quietly assumes a recent mid-range Android device will meet a user base still running four-year-old hardware on a weak network. That is a performance budget question rather than a supply chain one, but the cause is the same. The practical response is to set a floor device and hold to it: pick the oldest phone you will support, keep one in the office, and test releases on it rather than on whatever the team happens to carry. It is the cheapest constraint you can impose on a mobile app project, and it is far easier to hold from the start than to retrofit after a client complains that the app is unusable on their staff's handsets.
Designing for substitution
If your product depends on a specific part or a specific accelerator, the useful engineering work is making substitution cheap. Abstract the interface, qualify a second source before you need it, and know which performance claims break if you have to switch. Teams that do this treat a shortage as a scheduling problem rather than a crisis, and the work is almost entirely done in advance, which is why it rarely gets done at all.
The time to qualify a second supplier is while the first one is still delivering.
The compute version of the same discipline
For AI workloads, avoid writing code that only runs on one vendor's stack in one region. Keep the model interface behind your own abstraction so swapping a provider is a configuration change rather than a rewrite. Measure the quality you actually need rather than assuming the largest available option, and know the smaller model you would fall back to and what it costs you in accuracy. Most production workloads need far less than the headline configuration, and the teams that know their number by measurement rather than by instinct are the ones who can absorb a price change without a redesign.
- One interface for model calls, with the provider and model as configuration.
- A named fallback model, tested on your evaluation set, not chosen during an incident.
- Region flexibility, unless a data residency commitment forbids it.
- Batch or off-peak scheduling for anything that does not need an immediate answer.
- A cost per request figure you can actually quote, so a price change is arithmetic rather than alarm.
The evaluation set is the load-bearing item there. Without one, "can we use the cheaper model?" is an argument; with one it is a measurement that takes an hour, which is the same reason it matters for shipping AI features that users trust.
Rent capacity, and read the commitment terms
Buying accelerators outright is rarely right for a small team, because the asset depreciates quickly and the utilisation is almost never high enough to justify it. Renting is the default, but read what you are signing: reserved capacity trades flexibility for price, and a long commitment made during a shortage looks expensive the moment supply loosens. Keep commitments shorter than your confidence in the workload. If you are already choosing a provider, the trade-offs are the same ones we set out for cloud and DevOps work.
Contract terms that matter more than the price
For any project with a hardware dependency, the commercial terms decide how bad a shortage gets. Agree in writing what happens when a component becomes unavailable: who bears the cost of a substitution, who pays for re-qualification and re-certification, how long a quoted price holds, and what the delivery penalty is when the delay is upstream rather than yours. A client who understands this before signing is an easier conversation than one who discovers it in month five.
What is worth watching, and what is noise
Lead times and spot prices for the specific parts you use are signal. Headlines about a new plant being announced are not, because the capacity arrives years later and often into a different market than the one that prompted it. Export controls and trade measures matter because they act quickly, and so does anything that concentrates a single step of the supply chain further. Read the trade press for the components you actually buy and ignore the rest, which is the general habit described in reading tech news critically applied to a narrow and unusually noisy beat.
The planning posture
Do not forecast the cycle. Assume volatility, keep options open, and make sure no single component or vendor decision can stop the roadmap. Write down which parts of your plan depend on a specific chip, a specific accelerator or a specific region, and treat each one as a risk with an owner rather than an assumption. That is unexciting advice and it survives contact with every version of this cycle so far. It also fits the same posture we take on AI and machine learning projects: decide by measurement, keep the vendor swappable, and never let a roadmap rest on a single supplier's good week.
Abishek Bimali
Founder & Engineer
Abishek founded SiteCraft Innovation and leads its engineering. He writes about building web and mobile products that hold up in production, for teams in Nepal and abroad.
