From Basement Servers to Billion Users: What Software Learned That Hardware Hasn't

There is a divide in technology that most people do not know exists. It is not between large companies and small ones, or between Silicon Valley and everywhere else. It is between software and hardware — between building with bits and building with atoms. And the people who have worked on both sides of it carry a particular kind of frustration that is difficult to convey to anyone who has not.

On the software side: an idea over morning coffee. A working prototype by lunch. Users trying it in the afternoon. Feedback, iteration, a second version before dinner. The distance between imagining something and knowing whether it works, compressed to almost nothing. Thinking and making as a single, continuous act.

On the hardware side: the same creative impulse, the same ambition, the same impatience to test an idea — filtered through weeks or months of waiting before you can see whether the concept works at all. Source a component. Wait. Find a manufacturer. Wait. Receive a prototype that is not quite right. Wait again. The physics of atoms imposes a patience that the physics of bits does not, and the gap between the two experiences is not a matter of degree. It is a different world.

Same founder. Same morning. Two entirely different relationships with time.

The reason for this gap is not that atoms are inherently harder to work with than bits — though they are. It is that software founders build on a platform that absorbs most of the drudgery, while hardware founders build everything from scratch. Software had its infrastructure revolution. Hardware has not. And the story of how that revolution happened — and why it has not yet crossed the divide — begins in a London basement, passes through a silk workshop in Lyon, and arrives at a question that the developed world can no longer afford to leave unanswered.

The Toll Gate

The old Prudential Insurance building in central London is a beautiful piece of Victorian architecture — the kind of building that makes you stand slightly straighter when you walk through the door. In 2000, a small technology company had the ground floor. Downstairs, in the basement, it had something less elegant: rack after rack of servers, beige and humming, cables snaking across floors designed a century earlier for deed boxes and filing cabinets, cooling systems fighting a losing battle against the heat.

The bill was heading toward two hundred thousand pounds. Not a single customer had yet used the product.

This was normal. In 2000, if you wanted to build an internet company, you first built a small industrial facility. You became, whether you liked it or not, an infrastructure company before you were allowed to become a product company. The business plan said “internet platform.” The daily reality said “facilities management with aspirations.”

The money was substantial. But what burned worse was the time. Weeks of engineering effort poured into network topology, redundant power supplies, disaster recovery — problems that were genuinely important and had absolutely nothing to do with customers. Every week spent on infrastructure was a week not spent on the product. Every pound spent on a server rack was a pound not spent understanding whether anyone wanted what was being built.

The infrastructure work was not badly done. It was simply, profoundly, beside the point. Cooling airflow matters. But it matters in the way plumbing matters — essential, invisible, and utterly unrelated to why anyone started the company. Nobody had set out to manage servers. They had set out to build something for people. The servers were a toll you paid before you were allowed to start. And every company paid the same toll, independently, as though no one had ever built a server room before.

The Toll Abolished

Six years later, the toll was abolished. Amazon Web Services launched in 2006, and the insight behind it was so simple that it is difficult, in retrospect, to understand why it took so long. Jeff Bezos noticed that every technology company was spending enormous effort on what he called “undifferentiated heavy lifting” — infrastructure that everyone needed and that gave no one a competitive advantage. So Amazon offered to provide it as a service. Rent computing power by the hour. No basement required.

Two years after that, Apple launched the App Store and eliminated the other great friction: distribution. Before 2008, getting software to consumers meant physical boxes in physical shops, or a website that users had to discover on their own. The App Store replaced all of it. Infrastructure solved. Distribution solved. What remained was the product itself — the only part that had ever mattered.

The consequences arrived quickly. When Facebook acquired WhatsApp in February 2014 for nineteen billion dollars, the company had roughly fifty-five employees serving about 450 million monthly active users. They owned no data centres, leasing their server infrastructure rather than building it. The ratio of users to staff would have been physically impossible in the Prudential basement era — not because the engineers of 2000 were less talented, but because in 2000 no platform existed. Every company built its own basement. WhatsApp had leased someone else’s. The toll had been abolished, and an entire generation of companies rushed through the open gate.

For anyone who had lived through the basement years, the shift carried a particular sting. All those months of effort, all that capital poured into racks and cables and cooling — it had not been the cost of building a technology company. It had been the cost of there being no platform yet. The moment the platform arrived, the basement became a historical curiosity. A relic of the years before someone built the obvious thing.

The Drawboy

The pattern of the toll gate — and its eventual abolition — is older than software. Much older. And the clearest example involves a child, a loom, and a stack of punched cards.

In the early nineteenth century, the silk weavers of Lyon produced the most complex textiles in Europe. But producing an intricate pattern — a brocade, a damask, anything with a repeating design of real sophistication — required not one skilled worker but two. The weaver operated the loom: feeding the shuttle, maintaining tension, selecting yarns, assessing quality. The second worker was the drawboy.

The drawboy was typically a child. He sat on top of the loom — physically on top of it — and manually lifted individual warp threads according to instructions shouted up from the weaver below. Each thread was a binary decision: up or down. Each row of the pattern required hundreds of such decisions. Each inch of cloth required thousands. The drawboy executed these decisions, in sequence, without error, for hours at a stretch, hunched over a clattering machine in a Lyon workshop.

One mistake — one thread lifted when it should have stayed down — could ruin an entire section of fabric. And mistakes were inevitable, because the drawboy was a child performing monotonous precision work under physical strain. Fatigue set in. Concentration lapsed. The error rate imposed a hard ceiling on the complexity of patterns that could be reliably produced. There were designs that master weavers could imagine but no drawboy could execute — patterns that existed in the weaver’s mind but could not survive the passage through small, tired hands.

This was the toll. Before you could weave, you needed a drawboy. Before you could create, you needed infrastructure — fragile, expensive, error-prone infrastructure that had nothing to do with the creative act itself. The weaver’s genius was irrelevant without the drawboy’s hands. And every weaver in Lyon faced the same constraint, independently, as though no one had ever thought to solve it.

In 1804, Joseph Marie Jacquard patented the mechanism that solved it. His device replaced the drawboy with a chain of punched cards. Each card encoded one row of the pattern: holes where threads should lift, solid card where they should not. The cards fed through the loom automatically, one after another, executing the pattern with a mechanical precision that no child could sustain. The weaver still operated the loom. Still judged tension, selected materials, assessed quality, decided which designs to produce. But the drawboy’s work — the undifferentiated heavy lifting of the silk trade — was now performed by cardboard.

The results transformed Lyon. Patterns of extraordinary complexity became routine. Costs fell. Quality rose. And the weaver’s expertise became more valuable, not less, because the loom could now execute designs that only a master could conceive. The toll had been abolished. The creative act was liberated from its dependency on fragile infrastructure.

Here is the part that most people do not know. Charles Babbage — the mathematician who designed the first general-purpose computer — studied the Jacquard mechanism and recognised the punched card as something revolutionary: a way of encoding instructions for a machine. He owned a woven portrait of Jacquard produced on a Jacquard loom — it now sits in the Science Museum in London — and explicitly referenced the mechanism in his writings on computation. His Analytical Engine, designed in the 1830s, used Jacquard-style cards to store its programmes. Ada Lovelace, working with Babbage in the 1840s, wrote what is widely regarded as the first published algorithm, intended for this machine. The entire history of computer programming — every line of code, every app, every cloud service — descends in a direct, traceable line from Jacquard’s solution to the drawboy problem.

And now AI is automating the next drawboy. A junior developer with an AI coding assistant produces working software at a speed that would have required a significantly more experienced developer five years ago. The bottleneck shifts from “can we write the code?” to “do we know what to build?” — from execution to judgment. From the drawboy’s hands to the weaver’s eye. The pattern repeats across centuries: automate the toll, liberate the craft.

The Toll That Remains

Every hardware founder knows the drawboy’s experience. They deal with it every day.

A founder has an idea for a product — a medical device, a sensor, a piece of industrial equipment. They know what it should do. They may even know how it should work. But before they can build it — before they can test whether the idea is any good — they must first construct the infrastructure to make building possible.

Find a contract manufacturer willing to discuss their volumes, which are laughably small. Source components from suppliers who would rather serve customers ordering millions of units. Establish quality control processes as though no one in manufacturing had ever inspected a part before. Navigate regulatory certification — designed for established companies, applied without adjustment to a team of four. Commission tooling. Build test fixtures. Negotiate logistics.

Every one of these problems has been solved, thousands of times, by people with decades of experience. But the hardware founder cannot access that experience at the scale they need. They do not require a full-time supply chain director for eighteen months. They need four hours of expert judgment at the right moment. They do not need a permanent quality engineer. They need someone who has seen a thousand failure modes to review the test protocol before production begins. The expertise exists — locked inside large companies, or retired into consultancy at day rates that would consume the seed round, or invisible to someone who does not yet know what questions to ask.

So the founder does the drawboy’s work. Sits on top of the loom, lifting threads by hand, making mistakes that experience would have prevented, spending months on problems that are not their product. As we explored in The Eighteen-Month Trap, this is structural — hardware startups spend their first year building the ability to build, burning time and capital on the toll before they are allowed to start weaving.

And the toll is heavier than it needs to be, because the West no longer has the manufacturing density that once made hardware development fast. In the 1850s, Birmingham’s gun quarter clustered every specialist within walking distance, as we traced in The Fifteen-Minute Advantage. Today, that density exists in Shenzhen, where the Pearl River Delta concentrates more manufacturing capability into a smaller area than any cluster in history. Andrew Huang’s The Hardware Hacker captures what this means in practice: a hardware startup in Shenzhen can source a component, have it modified, and hold a working prototype in days. The same process in the West takes weeks, not because Western engineers are less capable but because every part, every process, every test requires reaching across continents to someone else’s cluster. The drawboy is not just still present — he is working in slow motion.

The Morning After

There are founders who know both sides of this divide. Who write software in the morning and work on hardware in the afternoon. Who experience the delight of one — idea to prototype to test in a single sitting — and then turn to the other and feel the weight of everything that has not yet been solved.

For software, the toll was abolished years ago. AWS, the App Store, AI coding assistants — each one removed another layer of drudgery, another stretch of undifferentiated heavy lifting, leaving the founder free to focus on the thing that matters: the product. The weaver liberated from the drawboy. The creative act freed from its infrastructure dependency. Edward Glaeser’s The Triumph of the City argues that innovation clusters wherever proximity reduces the friction between people and ideas — for software, that friction has now collapsed almost entirely, with a deploy replacing the walk across the workshop floor.

For hardware, the toll remains. Every founder pays it. Every startup burns its first year on infrastructure. Every investor watches capital disappear into problems that are not the product.

And the clock is running. The generation now entering the workforce across the developed world is dramatically smaller than the one it replaces. South Korea’s fertility rate fell to 0.72 in 2023. Japan, Italy, Germany, China — all far below replacement. As we explored in The Builders Are Dying, the populations that built the modern world’s industrial infrastructure are the ones declining fastest. Each young engineer, each young founder, must be vastly more productive than any previous generation — not because more is demanded of them, but because there are fewer of them carrying more weight. A shrinking generation cannot afford to spend its years doing the drawboy’s work.

Jacquard saw the waste in 1804 and built the loom. Bezos saw it in 2006 and built the cloud. In both cases, the pattern was the same: every practitioner struggling with the same undifferentiated problem, and a platform that solved it once for everyone. Brad Stone’s The Everything Store records that many inside Amazon thought Bezos was wrong to build infrastructure for strangers. As Bent Flyvbjerg shows in How Big Things Get Done, the projects that succeed are those that decompose the infrastructure problem into solved, repeatable modules rather than building everything bespoke from scratch.

The punched cards exist. The platform pattern is proven. Software founders have lived in the liberated world for fifteen years. Hardware founders still sit on top of the loom, pulling threads by hand, one at a time, waiting.

The delight of one world. The grinding patience of the other. Same ambition. Same morning. And every morning, the same asymmetry — the unresolved gap between what building could feel like and what it does.