The Eighteen-Month Trap: Why Hardware Startups Are Structurally Slow

There is a particular expression that appears on the face of a hardware startup founder about nine months into their journey. It is not despair, exactly. It is the look of someone who has just realised that the rules of the game they are playing are different from the rules they were told about — and that nobody mentioned this before they started.

The expression appears when the founder, who has raised a seed round, assembled a small team, designed a promising product, and begun to feel the first stirrings of commercial momentum, discovers that they cannot actually make anything. Not because the design is wrong. Not because the team is incompetent. But because the physical infrastructure required to manufacture their product does not yet exist, and building it will take another year, cost more than the product development itself, and force a cascade of decisions that have nothing to do with engineering and everything to do with property law, planning permission, equipment procurement, and the agonising fragility of global supply chains.

This is the Eighteen-Month Trap. And it catches nearly everyone.

Two Things at Once

The simplest way to understand why hardware is structurally slow is to count the number of things a founder must build simultaneously.

A software startup builds one thing: the product. The infrastructure already exists. Amazon Web Services, Google Cloud, and Microsoft Azure provide computing, storage, networking, and deployment at virtually any scale, available in minutes, billed by the second. A software founder with a laptop and a credit card can go from idea to global product in weeks. The infrastructure is someone else’s problem — and has been since roughly 2006, when AWS launched Elastic Compute Cloud in beta and began separating the question of “what shall we build?” from “where shall we build it?”

A hardware startup builds two things: the product and the infrastructure to produce it. For startups that need their own production facility — rather than relying on contract manufacturers — there is no AWS for atoms. No on-demand factory floor that scales like cloud computing, instantly and elastically, billed by the hour. The hardware founder must design the product and, simultaneously, find a site, negotiate a lease, obtain planning permission, design the facility layout, procure equipment, install utilities, hire specialists, and pass regulatory inspections — all before producing a single unit.

This is not a difference of degree. It is a difference of kind. The software founder’s entire cognitive and financial bandwidth goes into making the product better, faster, more desirable. The hardware founder splits that bandwidth — and often the majority goes not to the product but to the infrastructure. As Suzanne Berger documents in Making in America, the gap between designing a product and being able to manufacture it at scale has widened dramatically over the past three decades, as the infrastructure that once supported small and mid-sized manufacturers has been hollowed out across the West. The knowledge, the tooling, the supplier networks, the skilled tradespeople — all of it dispersed, offshored, or simply forgotten.

The consequence is predictable: hardware startups are slow. Not because their founders are less talented than software founders, but because the structure of the problem is fundamentally different.

The Timeline Nobody Warns You About

Consider the actual timeline of a hardware startup that needs its own production facility — even a modest one.

Months 1–3: Site search. The founder needs industrial space. Not office space, not co-working — industrial space with appropriate power supply, loading access, and zoning for manufacturing. In most Western cities, this means searching through commercial property agents, visiting sites that turn out to be unsuitable, and discovering that the vacancy rate for appropriate industrial space is often lower than expected. Industrial vacancy rates in major markets have been historically tight — running at around 3% in the United States as recently as 2022, according to CBRE, before rising somewhat as the post-pandemic surge eased. The founder, who should be refining their product, is instead learning about commercial leases, dilapidation clauses, and the difference between B2 and B8 use classes.

Months 3–6: Lease negotiation and planning. A commercial lease is not a residential tenancy. It involves lawyers, guarantors, rent deposits, and — for a startup with no trading history — the delightful discovery that landlords want personal guarantees from founders whose entire net worth is already committed to the company. Credit ratings matter. A startup with six months of history and a burn rate that makes landlords nervous will pay more, wait longer, and accept worse terms than an established business. A startup signing a ten-year lease on industrial space may need to provide six months’ rent as deposit, plus a personal guarantee, plus agreement on a fitout contribution — before it has sold a single unit. Meanwhile, any modification to the space — and there will be modifications — requires landlord consent, building control approval, and possibly planning permission. Each of these has its own timeline measured in weeks or months, not days.

Months 4–8: Equipment procurement. This is where the trap truly closes. The specialist equipment required for hardware production — CNC machines, injection moulding tools, pick-and-place systems, test rigs, clean-room infrastructure — has lead times measured in months. Six months is common. Twelve months is not unusual for specialist or high-demand equipment, and during periods of supply chain stress the situation worsens considerably. The founder must therefore order equipment before the facility is ready, before the exact specification is finalised, and before they have a clear picture of their production volumes. They are making £500,000 commitments on the basis of projections that are, at this stage, essentially fiction.

Months 6–10: Fitting out and commissioning. Equipment arrives. It does not simply plug in. Industrial machinery requires three-phase power, compressed air, extraction systems, specialist foundations, and — almost invariably — modifications that the original layout did not anticipate. The equipment supplier’s engineer arrives, notes that the cable trunking is in the wrong place, and departs. The building contractor returns. The planning inspector visits. The timeline extends.

Months 8–14: Regulatory clearance. Before a hardware product can be sold commercially in most markets, it must pass a battery of certifications. CE marking, UL listing, and FCC certification are legally mandatory for relevant product categories in the EU, North America, and elsewhere; ISO accreditation, while not always a legal requirement, is frequently a de facto market or customer expectation that cannot be ignored. Each costs money and time, and each must be completed — or at least substantially progressed — before the first commercial sale. The certification bodies have their own queues. Their own requirements. Their own timelines. None of them are in a hurry.

Month 15 onwards: First production. If everything has gone reasonably well, the startup can now begin manufacturing. The first units will have problems. They always do. The design that looked perfect on screen does not behave perfectly in production. Tolerances that were acceptable in prototype are not acceptable at volume. The team that designed the product now has to learn how to manufacture it — a different skill set, requiring different people, different processes, and a different kind of patience.

Eighteen months. Two years. Sometimes more. This is not a failure of ambition or management. It is the physics of building physical things.

The Obsolescence Problem

While the infrastructure is being built, the market is not waiting.

The product the founder designed eighteen months ago was designed for the market as it existed eighteen months ago. In that time, competitors have moved. Customer requirements have evolved. A new component has emerged that would have changed the design entirely — but the tooling is already cut, the certifications are already filed, and the equipment is already installed and configured for the original specification. Changing the design now means starting significant portions of the process again.

This is not a hypothetical. It is the lived experience of most hardware founders. The product that reaches market after eighteen months of infrastructure development is, in some meaningful sense, already eighteen months old. In consumer electronics, that can be a generation. In industrial equipment, it can mean that a key customer has already signed with someone else. In medical devices, it can mean that the regulatory landscape has shifted.

Bent Flyvbjerg and Dan Gardner, in How Big Things Get Done, demonstrate that large physical projects almost universally take longer and cost more than planned — not because planners are incompetent, but because physical projects face irreducible uncertainties that compound over time. Each delay creates dependencies that create further delays. The hardware startup is, in miniature, living the same dynamic. The site takes longer than expected, which delays the equipment order, which delays fitting out, which delays certification, which delays first production, which delays revenue, which exhausts the runway, which forces a fundraise at a moment of maximum vulnerability.

The Flyvbjerg principle applies at every scale. A hardware startup is just a megaproject with a smaller budget and a shorter runway for error.

The Cost Structure Nobody Planned For

Software startups have a cost structure that is, from a capital perspective, almost uniquely forgiving. The marginal cost of serving an additional customer approaches zero. A software product that takes six months and £200,000 to build can serve ten million users on infrastructure costing a few thousand pounds a month. Revenue scales dramatically faster than costs.

Hardware has the opposite cost structure. Every additional unit requires additional materials, additional labour, additional quality control, and additional logistics. Fixed costs are enormous: the facility, the equipment, the tooling. Variable costs are real and do not compress easily with scale — not at the volumes a startup is operating at. And the cash cycle is punishing: suppliers want payment on order or within thirty days; customers, particularly B2B customers, commonly do not pay until sixty to ninety days after delivery. The startup is, in effect, financing its customers’ inventory out of its own working capital.

This creates a pressure that software startups rarely face: the need to raise significant capital before generating any revenue, and to spend that capital not on the product but on the infrastructure. A hardware startup that raises a £2 million seed round may find that £1.5 million goes on lease deposits, equipment, fitout, and regulatory fees — and the remaining £500,000 on the engineering team and product development. The ratio feels wrong because it is wrong, from the perspective of building a product. But it is the unavoidable arithmetic of building physical things.

Banks make this worse. Banks want three years of accounts. The startup has three months. Equipment finance is available, but at rates that reflect the lender’s assessment of the risk — which is: considerable. The founder finds themselves in a position familiar to anyone who has dealt with institutional finance at the wrong end of the power dynamic: the money is available, but on terms that assume you do not actually need it.

The Hiring Paradox

Software startups hire for the product. Hardware startups must hire for both the product and the infrastructure — and they must do so before they know what either will fully require.

A hardware startup in month three needs, simultaneously: product engineers (to continue development), manufacturing engineers (to design the production process), procurement specialists (to manage the supply chain), regulatory affairs managers (to run the certification process), and facilities managers (to oversee the site build-out). Most of these people are expensive. Most of them are needed before there is anything to sell.

This creates a secondary pressure: the startup hires a sales and marketing team because investors expect commercial traction, and investors expect commercial traction before the product exists in manufacturable form. The sales team is selling a promise. The marketing team is building awareness for a product that cannot yet be delivered. The burn rate climbs. The runway shrinks. And the product — the thing the company actually exists to make — receives less attention than it deserves, because the people who could be refining it are instead managing an estate agent, a planning consultant, a certification body, and a commercial landlord.

Peter Thiel’s observation in Zero to One — that startups must focus relentlessly on doing one thing exceptionally well — is wisdom that the hardware startup simply cannot follow. The structure of the problem will not permit it. The hardware founder is forced into breadth at precisely the moment when depth is what the product requires.

The Lean Fallacy

The dominant startup methodology of the past fifteen years — The Lean Startup, by Eric Ries — prescribes building minimum viable products, releasing them quickly, gathering feedback, and iterating. Build, measure, learn. Fail fast. Pivot early.

This methodology was developed in the context of software, and it works extraordinarily well there. A software team can release a new version of their product in a day. They can A/B test two different approaches simultaneously. They can respond to user feedback within a sprint cycle. The cost of iteration is low. The speed of iteration is high. Build, measure, learn operates at a tempo that keeps the product aligned with the market.

Hardware cannot do this. The minimum viable product of a hardware startup is constrained by tooling costs, lead times, and the physical properties of materials. Changing a dimension requires new tooling. Changing a component requires re-certification. Changing the manufacturing process may require reconfiguring equipment that took months to install. The hardware equivalent of “release a new version” is measured not in days but in quarters.

Clayton Christensen’s The Innovator’s Dilemma describes how established firms lose to disruptive newcomers who can move faster and iterate more cheaply at the low end of the market. Hardware startups face an inverted version of this dynamic: it is the newcomer that is trapped by infrastructure commitments, while the established incumbent — with amortised equipment, trained staff, certified processes, and existing supplier relationships — can often iterate faster within their existing capability envelope. The structural advantage that the lean startup model assumes the newcomer has does not exist in hardware.

What This Means in Practice

None of this is speculation. Andrew ‘Bunnie’ Huang, one of the most experienced hardware developers writing today, captures this reality in The Hardware Hacker. The knowledge and infrastructure required to bring a physical product to market is vast, distributed across dozens of specialists, and largely undocumented. A hardware developer must navigate a world of tacit knowledge, personal relationships, and hard-won manufacturing experience that cannot be Googled. The Shenzhen manufacturing ecosystem that Huang writes about — with its extraordinary density of suppliers, fabricators, and component traders operating in close proximity — exists precisely because proximity and informal knowledge-sharing are the only way to make hardware development move at anything approaching software speed.

This connects directly to what we explored in The Fifteen-Minute Advantage: How Birmingham’s Walking-Distance Supply Chain Built the Modern World: the Victorian hardware revolution succeeded because proximity compressed the feedback loops that hardware development requires. The toolmaker was three streets from the stamper; the stamper was two streets from the roller. Problems were solved in an afternoon, not a quarter. The modern hardware startup, attempting to recreate that dynamic in a world where the supply chain has been globally dispersed, faces the full cost of that dispersal in every procurement decision it makes.

The COVID-19 pandemic made this structural fragility impossible to ignore. Supply chains that had seemed acceptably robust turned out to be extraordinarily brittle. Single-source dependencies — a chip from one Taiwanese foundry, a sensor from one Japanese supplier — propagated through entire product categories. Hardware startups that had been managing their procurement carefully enough discovered that careful management of a fragile system is not the same as resilience. As we explored in The Severed Circuit: How the US-China Tech War Is Splitting the World in Two, the geopolitical fracturing of technology supply chains has added a new and permanent dimension to this fragility. Hardware founders must now make procurement decisions with one eye on engineering requirements and another on the shifting landscape of export controls, tariffs, and strategic competition between great powers.

The Structural Diagnosis

It would be comforting to believe that the Eighteen-Month Trap is a problem of execution — that better founders, with better plans and better discipline, avoid it. They do not. The trap is structural. It emerges from the nature of physical things: they take up space, they have lead times, they require certification, they demand capital before they generate revenue. No amount of founder talent eliminates these properties.

What makes the trap especially cruel is that it punishes founders precisely when they are most vulnerable — in the early months, before revenue, before proof, before the confidence that comes from a product that works in the market. The software founder in the same position can iterate their way to product-market fit. The hardware founder cannot iterate. They can only wait, and spend, and hope that the market they designed for twelve months ago still exists when the equipment finally arrives.

The software industry solved this problem not through better execution but through better infrastructure. AWS did not make software founders better engineers. It removed an entire category of problem — the infrastructure problem — from their cognitive load entirely. They no longer had to think about servers, because servers had become someone else’s permanent, professional concern. The result was an explosion of software innovation that the previous generation of founders, who had to build and manage their own infrastructure, could not have imagined.

Hardware has not had its AWS moment. The infrastructure problem remains stubbornly, expensively, exhaustingly the hardware founder’s problem. Every hardware startup builds its own version of the same infrastructure. Every hardware founder learns the same hard lessons about commercial leases, equipment lead times, certification bodies, and the fragility of supply chains. The knowledge does not compound. The infrastructure does not persist. Each new startup begins again from scratch.

That is not a law of nature. It is a gap. And gaps, in the history of industry, tend eventually to be filled.

The hardware founder staring at their empty factory floor, waiting for equipment that is six months delayed, is not looking at a personal failure. They are looking at the shape of the next platform waiting to be built.