A free web book told small teams to build less

The workload

'Getting Real,' self-published by the software company 37signals (renamed Basecamp in 2014), lays out a specific set of tasks for a founder or small team building a web application: cut the feature list before writing code, fix a project's time and budget and let scope move instead, and delay hiring for as long as possible. The chapter titled Build Less tells a team to solve simple problems and skip the rest; a later chapter tells the same team to hold a launch date instead of stretching it. These are the publisher's own working instructions, not measurements of outcomes.

What the documents show

The book itself, read today at basecamp.com/gettingreal, is a living document that 37signals has rewritten and re-hosted more than once; the copy retrieved on 16 September 2026 still argues, self-reported by the publisher, that adding staff to a struggling project makes it worse, citing Fred Brooks by name in the hiring chapter. A separate, dated archived 2006 order page for the same book adds a self-reported claim that the company built five web applications and Ruby on Rails 'in just two years with no outside funding, no debt, and only 7 people.' That figure describes 37signals' 2006 marketing copy for the book, not an audited record, and is not repeated here as measured fact.

The operating cost

The book's own price has changed. The 2006 order page charged $19 for a single-user, 171-page PDF and $49 for a ten-copy site licence, self-reported terms set by the publisher at the time. The current version, per Basecamp's own books page retrieved 16 September 2026, is free to read online or download. Neither page states how much time the practices inside, cutting a team to three people or holding a three-month build window, actually cost a reader to adopt; that figure would require tracking a specific team's hours against the book's advice, which is outside what these sources establish.

The stop condition

The book names its own stop condition for scope: when a fixed launch date and budget cannot fit a planned feature list, the feature list moves, not the date or the budget, per the fix-time-and-budget chapter. It gives a parallel stop condition for staffing in the hiring chapter: don't add a person until the work that person would relieve is named specifically. Where the book is silent, on how long a reader should keep testing a stalled solo build before treating the method itself as the wrong fit, this is an editorial gap, not a published rule.

• Does the team have a specific task a new hire would relieve, named in advance?
• Is the project's launch date fixed, or is scope the thing actually being protected?
• Which of the book's 2006 marketing claims are being treated as proof, rather than as the publisher's own promotion?

'Getting Real' is a self-published statement of method, not a case study with audited results. Its instructions, cut scope, delay hires, fix the calendar, are worth reading as the publisher's own working rules for building Basecamp, not as evidence that the same rules produce the same outcome elsewhere.