Getting Real
Build less, ship faster
Description
In 2006, a small Chicago software company called 37signals published a book called Getting Real. It was not a normal software book. There was no chapter on database schemas, no diagrams of system architecture, no fold-out appendix of code. It was a collection of short, opinionated essays — most of them a page or two — written by the same people who built a project-management tool called Basecamp. The company had roughly seven employees at the time. They had shipped a product that thousands of businesses were paying for, and they had done it without most of the machinery the industry considered essential: no detailed functional spec, no dedicated project managers, no roadmap stretching two years out.
What made the book land was the gap between how 37signals worked and how everyone assumed serious software got made. The prevailing wisdom, then as now, was that building something real meant scaling up — more engineers, more planning, more documentation, more meetings to coordinate the engineers and the planning and the documentation. Getting Real said the opposite. It argued that most of that machinery was not a sign of seriousness but a symptom of avoiding the actual work, and that a tiny team with taste and a bias toward shipping could beat a large one drowning in its own process.
The book was given away free online, sold as a cheap PDF, and passed hand to hand through a generation of developers and founders who were tired of building things nobody used. Its claims were blunt, occasionally smug, and impossible to ignore. Two decades later, a lot of what once sounded heretical has quietly become the default vocabulary of how small teams talk about their work.
The question we’re asking : What did 37signals actually argue, and why did a book that refused to teach you how to code become required reading for a whole generation of builders?What we’ll see : How a seven-person company turned its own habits into a case against the way software was supposed to be made.
Table of contents
01Chapter 1 — The book that argued against the plan
Getting Real opens by attacking the thing most teams treat as the foundation of a project: the big upfront plan. The authors — Jason Fried, David Heinemeier Hansson, and their small crew — argue that the long functional specification, the document meant to nail down every feature before a line of code gets written, is mostly theater. It feels responsible. It produces a thick artifact everyone can point to. And it is, by their account, close to worthless, because it describes a product nobody has used yet, based on guesses about what people will want.
Their objection is not that planning is bad. It is that detailed planning too early locks you into decisions made when you knew the least. A spec that runs a hundred pages gives the illusion of agreement, but the words hide a thousand small disagreements that only surface once something real exists to argue about. Better, they say, to build a rough version fast and let the working thing become the spec. You learn more from one afternoon with a clickable screen than from three weeks of meetings describing it.
02Chapter 2 — Half a product, not a half-assed one
The most quoted line in the book is a rule about scope: build half a product, not a half-assed product. The distinction carries the whole argument. Teams almost always try to ship everything a feature list demands, and the result is a wide, shallow product where nothing works especially well. 37signals says to do the reverse — pick the smaller set of things that matter, and make those genuinely good, even if it means cutting features other people insist are non-negotiable.
This is where their bias toward launching imperfect things comes in. The book is openly hostile to the instinct to polish forever behind closed doors. A product that ships with fewer features but reaches real users starts learning immediately; a product held back until it is complete learns nothing, because completeness is measured against a guess. Real usage tells you which of the features you agonized over nobody touches, and which small thing you almost cut turns out to be the reason people stay.
03Chapter 3 — Less software, on purpose
If the first half of Getting Real is about process, the second is about a temperament — a preference for less software that runs through every recommendation. The authors want fewer features, fewer options, fewer settings, fewer words on the screen. They see each addition as a tax paid forever, and they treat restraint not as a limitation you tolerate but as a design choice you actively make. Less software means fewer bugs, cheaper maintenance, and a product a new user can actually understand.
One of the sharper ideas here is designing for the customer who already loves you, not the one you are trying to win over. Software teams obsess over objections from prospects who want one more feature before they will commit. 37signals argues this is how products rot: you keep bolting on things to please people who may never pay, and in the process you degrade the experience for the people who already do. Build for your existing users, keep them delighted, and let the product's clarity do the selling.
04Chapter 4 — The manifesto behind the method
Read as a list of tips, Getting Real is easy to file under productivity advice. But underneath the how-to sits a genuine wager about where good software comes from, and it cuts against the deepest assumption of the industry that produced it. The industry believes that better products come from more resources — more funding, more headcount, more runway. 37signals bet the opposite: that better products come from constraint, and that most of what money buys a software team is the freedom to avoid hard choices.
That is the real provocation of the book. It reframes limitation as an advantage rather than a handicap. A small team with no budget cannot hire its way out of a design problem or plan its way around a hard decision; it has to actually decide, and deciding well is the whole job. The book is, at bottom, an argument that taste and judgment scale badly — that they live in small groups of people who care, and get diluted the moment you add layers of process and headcount meant to substitute for them.
05Conclusion
Getting Real began as a description, not a prescription — seven people writing down how they already worked, and discovering that their habits amounted to a quiet rebellion. The rebellion was against the idea that building something serious requires building something big: big plans, big teams, big feature lists, big documents proving you thought of everything. 37signals had shipped a product people paid for by doing almost none of that, and the book is their attempt to explain why the shortcut was actually the point.
Related books
