In one sentence
Build less, learn sooner, and keep the business small enough to make clear decisions. The authors argue that successful web applications come from focusing on a specific problem, launching a useful minimum, observing real usage, and repeatedly improving it—not from elaborate up-front planning, large teams, exhaustive feature lists, or heavy funding. This is a practical philosophy drawn from 37signals’ experience, not a universal recipe.
Overview
The book is organized as a collection of short principles covering business strategy, product definition, interface design, programming, organization, customer support, and marketing. Its recurring move is to expose the hidden cost of complexity: every feature creates design, code, testing, documentation, support, pricing, and marketing work. The recommended response is to cut scope, make decisions reversible where possible, and put a working product in front of users quickly.
Core ideas
Start with the problem, not the imagined product
Define the central problem and the smallest useful version of the solution. Avoid building a grand system for hypothetical future customers; let actual use reveal what deserves to exist.
Constraints improve product decisions
Limited time, money, and people force prioritization. The authors treat constraints as a design advantage because they make teams decide what is essential instead of accumulating options.
Build less than you think you need
Say no to feature requests first, then make any surviving request demonstrate enough value to justify its full downstream cost. A feature is not finished when coded; it also affects testing, help, screenshots, pricing, terms, and support.
Launch early and iterate in public
A real, imperfect product teaches more than extended internal debate. Short cycles create feedback from real behavior rather than opinions about plans or mockups.
Prefer simple, understandable interfaces
Reduce choices, screens, settings, and explanatory text. Good design makes the common path obvious while using clear writing and defensive handling of errors for the difficult paths.
Let the team stay small and close to the work
Small teams reduce coordination overhead and preserve ownership. Decisions should happen near the people designing and building the product, with communication kept direct and concrete.
Marketing is part of making the product
Explain the product plainly, teach through the product itself, and use the company’s work, writing, and experience as marketing assets. Customer support is also a source of product insight, not merely a cost center.
Make a sustainable business before pursuing scale
The book favors revenue, independence, and controlled growth over premature fundraising or expansion. Its implicit model is a focused software company that can prosper without becoming large.
Practical takeaways
- Write down the one-sentence problem your product solves; delete ideas that do not strengthen that purpose.
- For every proposed feature, list the secondary work it creates: interface changes, code, tests, documentation, support, pricing, and marketing.
- Choose a version that can be launched soon enough to generate evidence, then define what you will learn from the launch.
- Replace speculative roadmaps with a short list of the next meaningful problems to solve.
- Use real customer behavior and support conversations as evidence, while remembering that the loudest request is not automatically the most valuable.
- Keep defaults simple; make advanced behavior possible without making it visible to everyone.
- Write marketing and help copy in plain language, with concrete examples rather than inflated promises.
- Treat “no” as a product skill: preserving focus may create more value than adding another attractive capability.
Caveats and counterpoints
- The advice is strongly shaped by 37signals’ own context: web software, experienced founders, a narrow product focus, and unusually strong convictions about independence. It should not be treated as neutral evidence that every startup should bootstrap or remain small.
- The book’s aphoristic format makes the principles memorable but can hide trade-offs. “Launch early,” “keep it small,” and “say no” require judgment when reliability, security, accessibility, regulation, or enterprise commitments impose real costs.
- Its examples and assumptions come from the mid-2000s web-software environment. The underlying ideas about scope and feedback remain useful, but specific technology, distribution, and competitive conditions have changed.
- The book is more persuasive as a counterweight to overbuilding than as a complete operating manual. It gives limited treatment to experimentation design, quantitative analytics, hiring at scale, formal sales processes, and markets where network effects or large upfront investment matter.
- Some readers may find the contrarian tone too absolute. A serious criticism is that principles derived from one successful company can be mistaken for generally validated laws; apply them as hypotheses and test them against your product’s constraints.
Questions worth revisiting
- What is the smallest product that would solve a real problem for a clearly defined customer?
- Which current feature has the greatest hidden cost relative to its demonstrated value?
- What would we learn by launching two weeks earlier?
- Are we responding to observed customer behavior or to internal anxiety about hypothetical needs?
- Which decisions are being slowed by unnecessary coordination or abstraction?
- What must be complex internally so the customer experience can remain simple?
- Does our growth plan serve the product and customers, or merely satisfy an external expectation of scale?
Return to this when…
Return when a product or marketing plan is becoming bloated, when a team is debating abstractions instead of testing a working version, or when customer requests are pulling the product in too many directions. The most useful reread is the feature-cost and scope material before a major roadmap decision.
Highlights
Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?". Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features."
Most software surveys and research questions are centered around what people want in a product. "What feature do you think is missing?" "If you could add just one thing, what would it be?" "What would make this product more useful for you?" What about the other side of the coin? Why not ask people what they don't want? "If you could remove one feature, what would it be?" "What don't you use?" "What gets in your way the most?" More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out.
Adding people to a late software project makes it later. —Fred Brooks
Epicenter design eschews the traditional "let's build the frame then drop the content in" model. In that process, the page shape is built, then the nav is included, then the marketing "stuff" is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It's a backwards process that takes what should be the top priority and saves it for the end.
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes. So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
A "spec" is close to useless. I have never seen a spec that was both big enough to be useful and accurate. And I have seen lots of total crap work that was based on specs. It's the single worst way to write software, because it by definition means that the software was written to match theory, not reality. —Linus Torvalds, creator of Linux