Most software gets built badly for a fairly boring reason: people build the pieces before they build the whole. The frontend team builds screens against an API that doesn’t exist yet. The backend team builds endpoints against a schema that’s still a guess. Everyone works in parallel, everyone feels productive, and then near the end someone finally wires all of it together — and that’s when you find out how many of your assumptions were wrong, all at once, with no time left to fix any of them.
There’s a name for the alternative, and once you have the name you start noticing it everywhere. It’s called a steel thread.
The term comes from bridge-building. When engineers span a valley, they don’t build out from both sides and hope the two ends meet in the middle. They throw a single thin steel cable across first — light enough to sling over, doing no useful work on its own — and then use that cable to haul something slightly heavier across: a walkway, then a beam, then eventually the deck itself. Every later, heavier piece depends on that first thin thing already being in place.
Picture dated Oct. 1935 of the Golden Gate Bridge, in the San Francisco Bay, during construction. The construction began on Jan. 5, 1933, and the bridge was inaugurated on May 27, 1937, by Franklin Delano Roosevelt, who pushed a button in Washington, D.C., signaling the official start of vehicle traffic over the bridge. The idea of engineer Joseph Strauss, it was the largest suspension bridge in the world. (AFP via Getty Images)
Software can be built the same way. A steel thread is the thinnest possible version of a system that still runs start to finish — button to server to database and back — built around whichever part of it is riskiest or least understood. It isn’t a prototype you’ll throw away. It’s real, if minimal, and it becomes the skeleton the rest of the system eventually hangs off of. It’s also smaller than what most people mean by an MVP, which is usually still a bundle of features. A steel thread is one path, actually working, before you’ve committed to any of the others.
Other people have described the same move under other names, which is usually a sign an idea is true rather than just fashionable. In The Pragmatic Programmer, Hunt and Thomas call it a tracer bullet — code that’s lean but complete, that shows you exactly where you’re aiming, as distinct from a prototype, which you fire once and discard. Alistair Cockburn calls it a walking skeleton. Three metaphors, one instruction: build something whole and thin before you build something partial and thick.
The reason this beats the layer-by-layer approach isn’t really about elegance. It’s about where the pain shows up. Build every layer in isolation and integrate at the end, and all of your integration risk gets backloaded into one stretch of the project — usually the stretch right before a deadline, exactly when you have the least slack to absorb surprises. A steel thread front-loads that same risk instead, in small, manageable doses, spread across the whole build. Jade Rubick, who has written the clearest account of this I’ve come across, puts it simply: you never have a lot of integration pain to wade through — instead you have small integration pain, all along the way. You find out on day three that the third-party API doesn’t do what you assumed, instead of finding out in week eleven.
The idea holds up a level above code, too. Sam Gerstenzang, who’s spent his career around early-stage startups, has said that thinking in steel threads is probably the single biggest influence on how he approaches building a new company. His version: get the bare-minimum end-to-end thing working — the actual full path from idea to a paying customer — before spending real effort making any one piece of it good. Concretely, that can mean closing your first sale badly, by hand, held together with a spreadsheet, before you’ve built any of the automation you assume you’ll eventually need. He frames it as a choice between two kinds of progress: bicycle, then scooter, then car, then airplane — each one a complete, working, if crude, vehicle — versus wheel, then chassis, then engine, then car, where nothing actually works until the very last step.
I think that second image is the whole idea in one picture. Most unfinished projects aren’t unfinished because people ran out of time. They’re unfinished because they spent all their time on a wheel, a chassis, and an engine, and never once had a vehicle. A steel thread forces you to have a vehicle — a bad one, immediately — and then spend every day after that making it less bad. That’s a very different way to work than trying to make each piece perfect before anything moves.
It’s also, I think, why this matters even more now that so much building happens with an AI model in the loop. A model does much better work against a narrow, concrete goal with a clear definition of done than it does holding a sprawling, half-wired system in its context all at once — a point Bryce York has made well. Steel threads were always a way of managing human attention. It turns out they’re a good way of managing a model’s attention too.
Further reading: Jade Rubick on steel threads in practice · Sam Gerstenzang on steel threads and product-market fit · LeadDev on steel threads in system design · the Wikipedia entry, for the bridge-building origin · Bryce York on steel threads and AI-assisted coding