Getting Real Summary & Review: Build Less, Ship Sooner

Getting Real in one minute

Most products die of extras, not of missing features. Getting Real is 37signals’ 2006 argument that a web application gets better when you subtract. Fix time and money. Flex scope. Design the middle of the screen first. Write words a human would say. Race to running software, then learn in the wild. Jason Fried, David Heinemeier Hansson, and Matthew Linderman wrote it while Basecamp was still a side project of a design firm. If a feature is not the epicenter, the default answer is no. If a meeting is a substitute for writing, cancel it. If the product cannot be used this week, it is still a document. The book will not give you a ceremony. It will give you permission to ship a smaller thing that is actually done.

Key takeaways

1. Build less: Unused features tax support and speed. Do less than competitors who collect requests.
2. Half, not half-assed: Ship a complete slice. A customer can use half, not a sketch of everything.
3. Start from the epicenter: The one job this screen must finish comes first. Chrome waits.
4. Interface first: Draw blank, regular, and error states before you pick a stack.
5. Fix time and budget, flex scope: The calendar is the constraint. Features are the variable.
6. It’s a problem when it’s a problem: Do not scale or hire for a future that has not arrived.
7. Meetings are toxic: They break flow. Decide in documents. Protect alone time.
8. Hire when it hurts: Stay at designer, programmer, sweeper until the pain is specific.
9. Real words are the interface: Specs go stale. Copy and stories teach the team what to build.
10. Launch while it is still small: Running software beats a better plan. Support it yourself.

What is Getting Real about?

Getting Real is a short field manual for building a successful web application by doing less: start at the epicenter, design the interface first, cut features by default, and ship running software with a tiny self-funded team instead of a thick spec.

About the author

Jason Fried co-founded 37signals, the Chicago design firm that became Basecamp, and has spent two decades arguing that a small, profitable, remote company is a complete ambition. David Heinemeier Hansson created Ruby on Rails inside that shop and co-wrote the philosophy that went with it: less software, ship. Matthew Linderman, a long-time 37signals designer and writer, is the third name on the jacket. Together they built Basecamp as a tool they needed for client work, then sold it. Getting Real (2006) is the first public manual of that practice — the prequel to Rework and the ancestor of Shape Up. The essays still read like someone in the room, not a keynote about scale. Explore all David Heinemeier Hansson book summaries →

Key concepts at a glance

Concept	What it means	Use it when
Build less	Do less than the feature list. Unused work is a tax.	The backlog is a museum of other people’s ideas.
Half, not half-assed	A finished slice beats a sketch of the whole product.	Every screen is 70% done and none can be used.
Epicenter design	The one action on the page comes first. Chrome waits.	You are designing nav before the job.
Interface first	Blank, regular, and error states before the database.	The stack is chosen and the screen is still a paragraph.
Fix time, flex scope	Calendar and budget are fixed. Features move.	The date keeps sliding because the list grew again.
Start with no	Default decline. Every yes has hidden cost.	You are the shop that cannot stop saying maybe.
Meetings are toxic	They break flow. Write, then decide.	The week is a calendar of status theater.
Hire when it hurts	Stay at three until a specific pain is real.	You want a hire so the org chart looks serious.

Part 1 — Build less than you think

Getting Real opens with a subtraction. Build less. The instinct on a new web product is to collect every competitor’s feature and every maybe-customer’s request. 37signals treated that pile as a liability. Each extra thing has a hidden invoice — more code, more support, more decisions next month, a slower path to the one job the product had to do. A good kitchen knife beats a gadget with twelve blades you never open.

The companion rule is the one people remember: half, not half-assed. A complete slice — login that works, a blank state that teaches, one job a customer can finish — beats twelve screens with placeholders. The half-assed version looks ambitious in a deck and collapses in the wild because nothing is actually done. The customer can use half. They cannot use almost. That is not a plea for low quality. It is a plea against the fake completeness of a spec.

Start with no. Feature requests are a menu of costs, not a to-do list. Hire the right customers instead of being the right vendor for everyone. Scale later. Ignore details early. It is a problem when it is a problem — do not build the enterprise matrix because a slide imagined ten thousand seats. Fix time and budget, flex scope. If the list does not fit the calendar, the list changes. That is how a design firm shipped Basecamp beside client work instead of waiting for a round that would let them do it properly.

Have an enemy — a stance, not a person. Getting Real is against bloated software and against funding that buys a bigger pile of maybe. Fund yourself if you can. Mass makes change expensive; less mass means you can still turn. The Three Musketeers is the staffing picture: one designer, one programmer, one sweeper who can do a bit of both. That is enough to get real. A twenty-person kickoff is a different sport.

Part 2 — Process that ships: done, not discussed

The process chapters are a race. Race to running software. Shrink your time. From idea to implementation should be short enough that the idea is still true when the pixels exist. Getting Real hates the dead document: the functional spec everyone signed and nobody can run. Tell a quick story instead. Use real words. Personify the product so the team argues about a character, not a module. Done means a person who is not you can click it. Test in the wild. Preferences are a trap — every setting is a feature you now support in two directions.

Meetings are toxic because they slice the day into pieces too small to make anything. 37signals wanted unity and alone time, not a culture of being seen thinking. Seek small victories you can ship. Staffing follows the same grain: hire less and hire later. Actions, not words. Get well-rounded people; you cannot fake enthusiasm. Wordsmiths belong on the team because the interface is made of sentences. A hire to look like a department is how a three-person product becomes a twelve-person calendar.

Write the decision. If it still needs a conversation, make it short and rare. Making software is a flow state, and a standing huddle is a tax on that state. When the pain of being understaffed is specific — support is actually drowning, the musketeers cannot cover a real hole — then hire. Not before. Getting Real is allergic to headcount as a proxy for seriousness.

Part 3 — Interface first, then code and words

Epicenter design is the visual heart of the book. Start with the one action the page must complete — the message, the to-do, the invoice — as if nav and settings did not exist. If the epicenter fails, the page fails. Chrome can wait. The three-state solution is the checklist: regular (it works), blank (teach), error (be a host). Most products skip blank and error, then wonder why day-one users bounce. Get defensive: assume people will type the wrong thing. Context over consistency — the right word on this screen beats a style guide that makes every screen equally vague.

Copywriting is interface design. One interface, not a maze of modes. Less software means the same cut you made in the feature list: every line is a future conversation. Optimize for happiness — Rails was built so the programmer could stay in flow. Code speaks; manage debt. None of that is a license to skip craft. It is a license to stop pretending a 400-page spec is craft. There is nothing functional about a functional spec that cannot be clicked. Tell a quick story. Use real words. Personify the product so what would this thing do here is a sharper question than what did we wireframe in March.

Part 4 — Price, launch, and stay small

Pricing and signup are designed for a human, not a gauntlet. Free samples so someone can feel the epicenter. Easy on, easy off — do not trap people to look big. Promotion is education and a Hollywood launch, not a budget that pretends attention can be bought in bulk. Show the work. Support is where the philosophy gets expensive in a useful way: feel the pain yourself. You should all be techs enough to hear what the product does to people. Post-launch, stay a better host. Strive for simplicity after you ship, not just before. Do not steal sleep as a badge.

Stay small enough to still turn. A three-person shop cannot do everything. It can do the epicenter, and that is usually the business. Launch now, while you can still feel every yes. Later Basecamp books give you calm companies and six-week bets. This one gives you the cut: start at the epicenter, and do not decorate it until someone has used it.

Who is Getting Real best for — and who should read something else first?

Best for founders, designers, and engineers who can still ship without a program-management layer — especially the person who is also the first user, and a team of three tired of performing a twenty-person process.

Read something else first if you do not know who the customer is — start with The Mom Test. If you need a five-day test with users in the room, Sprint is the timed path to running software. If discovery has to be a weekly habit inside a larger org, Continuous Discovery Habits and Inspired are the next floor. If the pain is hustle culture after you already ship, It Doesn’t Have to Be Crazy at Work and Rework are the culture books. The Lean Startup is the science-class cousin in Leadership, not a substitute for a cut list.

Questions to reflect on

• What is the epicenter of the thing you are building this month — one sentence, no commas?
• Which three features on your list exist because someone asked, not because a user is stuck?
• If you had to ship in ten days with the people you already have, what would you cut first?
• Where is a meeting doing the job of a paragraph you have not written?
• When did you last use the blank state and the error state of your own product as a customer would?

How to apply Getting Real (7-day plan)

1. Day 1 — Write the epicenter. One sentence: the job this product must finish. No commas, no “and also.” Put it at the top of the list.
2. Day 2 — Cut the list in half, then cut it again. Start with no. Anything that is not the epicenter waits. Hidden cost counts as a no.
3. Day 3 — Sketch the three states. Blank, regular, error — on paper, for the one screen that matters. Interface first. No stack argument yet.
4. Day 4 — Kill one recurring meeting. Replace it with a written update. Protect a half-day of alone time for the musketeers.
5. Day 5 — Race to running software. A thin slice a real person can click. Done means they finished the epicenter, not that you demoed a deck.
6. Day 6 — Rewrite the words. Personify the product. Replace “submit” and “solution” with what a human would say on that screen.
7. Day 7 — Launch to a handful and support it yourself. Feel the pain. The next yes should cost you something you can name.

Frequently asked questions

What is Getting Real about?

Getting Real is 37signals’ 2006 field manual for building a web application with a tiny team and almost no waste. Instead of a thick spec, a big staff, and a launch date that keeps sliding, the book asks you to start at the epicenter: the one job the product must do. You design the interface first, cut features by default, and race to running software a real person can click. Jason Fried, David Heinemeier Hansson, and Matthew Linderman wrote it while shipping Basecamp beside client work. Read it when your backlog is a wish list and you still have not shipped a smaller thing that works.

Who should read Getting Real?

Read Getting Real if you are a founder, designer, or engineer on a product that is drowning in extras. The book is written for people who can actually ship: a designer, a programmer, and someone who can do a bit of both. It is especially useful when you already know the customer because you are the customer. Skip it as a first book if you have never spoken to a user; start with The Mom Test so you do not epicenter the wrong problem. Product leaders at a large company will still get the cut-list, then want Inspired or Empowered for the org layer Getting Real refuses to grow.

Getting Real vs Rework — which should I read first?

Read Getting Real first if you are building the product. It is the earlier, more tactical sibling: epicenter design, interface-first, half not half-assed, meetings, hiring, pricing, support. Rework, four years later, is the company manifesto — plans are guesses, workaholism is not heroic, sell your by-products. The two overlap on build less, and that is the point. If you only have one evening, Getting Real will change what you ship this week. If you only have a commute, Rework will change what you refuse to pretend. Most TGR readers who already live in Basecamp’s world start here, then read Rework as the culture layer.

What does “half, not half-assed” mean in Getting Real?

Half, not half-assed means you ship a complete slice instead of a sketch of everything. A login that works, a blank state that teaches, and one job the customer can finish beats twelve screens with placeholders. The half-assed version looks ambitious in a deck and collapses in the wild because nothing is actually done. Cut the list until the remaining work can be finished, then finish it. That is not a plea for low quality. It is a plea against the fake completeness of a spec. If a feature cannot be whole this cycle, it waits. The customer can use half. They cannot use almost.

Is Getting Real still useful in 2026?

Yes, as a cutting tool, not as a stack tutorial. The screenshots are from an earlier web; you will not copy Basecamp’s 2006 signup flow. The useful parts aged well: constraints as a design input, start with no, epicenter before chrome, real words, hire when it hurts, and launch while the product is still small enough to feel. Shape Up later boxed those instincts into six-week bets. Inspired is how a larger product org discovers what to bet on. Getting Real is still the shortest permission slip to delete the backlog you do not believe in and ship the middle of the page first.

How long does it take to read Getting Real?

Most readers finish Getting Real in three to five hours. It is a stack of short essays, not a weekend argument. You can read Build Less, Half not half-assed, Epicenter design, and Meetings are toxic in a lunch and already have a cut list. The TGR 7-day plan is a work week: one epicenter sentence, one halved list, one three-state sketch, one cancelled meeting, one thin slice in the wild. There is a free web edition from the authors if you want to sample before you buy print. Either format is enough to start this week.

Does Getting Real replace Agile, sprints, or Shape Up?

No. Getting Real is a stance, not a ceremony. It will not give you a sprint board, a six-week appetite, or a discovery script. Agile theater can still produce a bloated product; this book says the board is not the work. If you need a time box and a betting table, Shape Up is the later Basecamp operating system. If you need five days with users in the room, Sprint is the timed path to running software. If you are not the user, The Mom Test comes first. Use Getting Real to cut. Use those books to structure the cut.

Related summaries

• Rework Summary & Review — the later culture cut from the same authors
• Shape Up Summary & Review — six-week bets after you believe in build less
• It Doesn’t Have to Be Crazy at Work Summary & Review — calm as the operating system
• Inspired Summary & Review — coaching product teams that are no longer three people
• Best productivity books — the full Productivity silo