Opens in a new tab
14 min 25 sec
Available in:Englishไทย

Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

Shows founders and small teams how to build and launch a product by doing less: fewer features, people, meetings and settings, so they move faster than bigger rivals and keep customers happy.

Table of Content

Founders who try to match bigger rivals feature for feature usually end up with a slow, crowded product, and Jason Fried and David Heinemeier Hansson say to build half as much instead. In Getting Real, the two partners behind the software company 37signals put it plainly: if a competitor ships ten features, ship five, and let simplicity be the reason people choose you.

That idea grows into the book’s whole argument. A small team that deliberately does less, with fewer features, fewer people, fewer meetings and fewer barriers for customers, moves faster and builds better than a big team doing everything. The lessons come from building web applications like Basecamp, but they apply to anyone starting something new, inside a company or out.

What follows covers what to build and who should build it, how to guard working time, how to cut a feature list, and how to design and launch. Most of the moves involve removing something, which makes them easy to start this week.

Copying the market leader looks like the safe way to start a company. Fried and Hansson think it is a trap, and the product they built for their own office shows what to do instead.

Big teams and long plans look like strength, until customers suddenly want something new. A simple rule about headcount helps explain why small teams can react quickly while bigger firms struggle to change course.

Teams can lose weeks arguing over things no customer will notice. A to-do app whose whole vision was to rival a sticky note shows how to settle what matters first and leave perfection for later.

Early mornings and late nights feel strangely productive for a reason. The authors turn that reason into firm rules about meetings, interruptions and the walls between departments.

The instinct is to collect the best specialists money can buy. Fried and Hansson would rather take an average performer with the right mood, and they know where to find one.

Every feature on the list sounds reasonable by itself, which is exactly the problem. A simple bit of arithmetic, and a remark Steve Jobs made at one private presentation, show how to cut.

Customers never see the clever engineering underneath, only what appears in front of them. That changes the order in which a product should be built, and what to leave out of the settings menu.

Good products often lose customers at the very first step. The authors describe the small launch choices that turn curious visitors into paying users, including one Apple used to sell music players.

Getting Real adds up to a single habit of mind: treat every addition as a cost. Another feature, another hire, another meeting, another investor, another setting in the menu. Each one makes a company heavier and slower to turn, and each pulls attention from the few things customers came for. Basecamp began because their web design firm needed a client communication tool and could not find a good one.

Small size, in their view, is something to use. Large companies tend to address customers like impersonal machines full of jargon. A small team can write like people, be friendly and get straight to the point, and it gains nothing by pretending to be bigger.

The book supports a few concrete moves. Write one sentence on why your product exists, as short as compete with a Post-it. Halve your feature list, then halve it again. Keep half of each working day free of interruption and cap meetings at 30 minutes. And let people try what you make in under a minute, with no contract to escape.

The Post-it never needed a settings menu. Most of the time, neither does the thing you are building.

About this book

What is this book about?

Many first products fail because their makers try to match bigger competitors feature for feature, hire too early, plan too far ahead and spend their days in meetings. Jason Fried and David Heinemeier Hansson, the pair behind the software company 37signals, argue that a small team wins by doing less on purpose. Drawing on how they built web applications such as Basecamp and Ta-Da List, they set out a lean way of working. Build the product you yourself need, fund it with your own cash and start with three people. Protect long stretches of uninterrupted time, hire enthusiastic generalists and delay hiring as long as you can. Cut the feature list in half, then in half again, design the screen before the code and skip user preferences. At launch, make signing up quick, billing monthly and contracts unnecessary. The advice comes from software, but readers in any field get a practical habit: treat every addition, from a feature to a hire to a meeting, as a cost that has to earn its place.

Book Information

Rating:

Genre:

Entrepreneurship & Startups

Topics:

Execution, Product Strategy

Publisher:

37signals

Language:

English, ไทย

Narrator:

Robert

First published:

November 18, 2006

Pages:

187

Length:

14 min 25 sec

Get the book:

Amazon

Who it's for

  • Planning a first product

    Founders and solo builders planning a first product with little money and a tiny team.

  • Fighting endless feature requests

    Product managers and designers fighting endless feature requests and meetings.

  • Managers in large companies

    Managers inside large companies who want a small team to move like a start-up.

Listen to Preview

About the Author

Jason Fried

Jason Fried co-founded 37signals in Chicago in 1999, first as a web design firm that turned to building web applications in 2004, starting with Basecamp. He speaks around the world on entrepreneurship, design and management. David Heinemeier Hansson, a Danish programmer known as DHH, created the web framework Ruby on Rails, cofounded Basecamp and is a partner and chief technology officer at 37signals. Together they also wrote ReWork and Remote, both New York Times bestsellers.

Ratings & Reviews

Ratings at a glance

4.4

Overall score based on 48 ratings.

What people think

Listeners consider this title an efficient read that delivers actionable guidance for business and development. They value the high-quality writing, with one listener highlighting the brief phrasing and the lean 200-page layout. Listeners describe the work as motivational, with one saying it encourages them to get stuff done, and they feel it is a truly valuable use of time.

Top reviews

Roydao

Wow, this was exactly the kick in the pants I needed to stop over-engineering my side project and actually launch something. Fried and Hansson have a way of stripping away all the corporate fluff and focusing on what actually moves the needle for a user. Their mantra of building 'half a product, not a half-ass product' has completely changed how I look at my feature roadmap. To be fair, the book is quite opinionated and can come across as a bit arrogant at times, especially regarding outside funding. But if you want to get real about shipping code, there’s no better guide than this sparse, punchy collection of essays. It’s practical, it’s fast-paced, and it’s genuinely inspiring for anyone who values execution over endless planning.

Show more
Seksan

The chapter on blank slate design alone makes this book worth the price of admission. Most teams focus on the 'ideal state' of their app, but Fried and Hansson remind us that the first impression happens when the screen is empty. It’s a masterclass in empathy for the user experience. I found the 'Getting Real' philosophy to be a perfect entry point into agile and lean concepts without the confusing jargon. Not gonna lie, I was skeptical about their 'no specs' rule at first, but after seeing how much time we waste on documentation, I’m starting to come around. This is an essential read for anyone who wants to build software that people actually enjoy using. It’s fast, punchy, and incredibly practical.

Show more
Sau

This is less of a book and more of a manifesto for the modern era of lean development. It rejects the 'more is better' culture that ruins so many great applications. I love how they emphasize that the interface is the product, not just a skin you slap on at the end of a project. By focusing on the 'real'—HTML mockups over static sketches—you find the friction points much faster. It’s an empowering read that makes you feel like you don’t need a massive team or millions in VC funding to make a dent in the universe. If you’re tired of bloated specs and endless meetings, this book will be your new favorite tool. It's concise, opinionated, and absolutely essential for the DIY entrepreneur.

Show more
Nina

Finally got around to reading this classic, and it’s surprising how well most of the design advice has aged. The core argument that 'copywriting is interface design' should be required reading for every product manager and designer out there. I love the focus on the 'blank slate' stage where most users actually decide if your app is worth their time or not. My only gripe is that it feels a bit dated in its absolute rejection of specialized roles; being a generalist is great, but sometimes you need an expert. Despite that, the book is written with a concise clarity that makes it impossible to put down. It’s a quick 200-page blast of common sense for the software world.

Show more
Ploy

Ever wonder why your software projects always blow past their deadlines? This book offers a radical solution: fix your time and budget, then flex your scope. It’s a simple concept that most managers are terrified to implement, but the authors make a compelling case for why it’s the only way to stay sane. In my experience, the 'just-in-time' decision-making process they describe prevents so much wasted effort on problems that might never even happen. The text is organized into short, punchy two-page themes that make it easy to digest during a commute. While some of the 'bootstrapping' talk feels like it belongs in a very specific niche, the project management wisdom is universal. It’s a solid 4-star guide for anyone building digital products.

Show more
Matteo

Picked this up on a flight and finished it before we touched down. It’s easily the most efficient business book I’ve ever encountered, valuing your time as a reader above all else. The advice on skipping the 'lorem ipsum' and using real data during the design phase is something I'll be implementing immediately. I’ve spent too many hours looking at beautiful mockups that fall apart the moment actual content is added. The book is sparse, but every page contains an actionable insight or a sharp quote that sticks with you. It might not be a deep dive into technical architecture, but it’s a masterclass in product thinking. Highly recommended for busy people who hate long-winded theory.

Show more
Anong

After hearing about 37signals for years, I finally dug into this book, and I was pleasantly surprised by how applicable it is. I work in corporate training, not software, yet the ideas about shrinking timelines and cutting out 'stuff that doesn't matter' hit home. We often spend months planning programs that could have been prototyped in a week. The authors' take on 'flexible scope' is a game-changer for project management in any field. I particularly liked the section on treating your product like a person with a distinct voice and personality. It’s a refreshingly honest look at how to get things done without the usual corporate bloat. A few sections are definitely too tech-heavy, but the core message is universal and inspiring.

Show more
Wacharapol

As a developer working in a large enterprise, I found the advice here a bit of a mixed bag. The authors champion a 'stay small' mentality that feels incredibly refreshing if you're drowning in meetings, yet much of it seems unfeasible for complex systems. Frankly, the idea that you should just build for yourself and the market will follow is a dangerous oversimplification for most B2B sectors. However, the sections on designing for 'blank states' and the importance of copywriting in UI were absolute gold nuggets. It’s a breezy 200-page read that challenges your assumptions, even if you can’t apply every single tip. I’d recommend it as a mental palate cleanser, but don’t expect a comprehensive roadmap for a global startup.

Show more
Tuck

Look, the philosophies here are basically the 'Bonsai Tree' method of business—deliberately stunting growth to keep things manageable. If you’re an entrepreneur who wants to stay small and self-funded, this is your Bible, but it's not for everyone. The authors seem to abhor the idea of scaling or finding experts, which feels like a recipe for eventual burnout for most founders I know. That said, I can’t deny that the 'Less is More' approach to features is a vital lesson for the industry. The writing style is incredibly direct and avoids the usual business book fluff, which I truly appreciated. It’s a provocative read that will either make you nod in agreement or grit your teeth in frustration.

Show more
Penelope

Not what I expected based on the massive hype surrounding 37signals. While there are a few decent nuggets about interface design, most of the book felt like a collection of overly simplistic platitudes. Telling people to 'just build for themselves' ignores the reality of market research and user needs for 90% of the software industry. It’s easy to give this advice when you already have a successful product, but for a new startup, it feels dangerously narrow. The tone is quite dismissive of anyone who doesn't follow their specific path of bootstrapping and staying tiny. If you’re looking for actionable, nuanced business strategy, you’re better off looking elsewhere. It’s a very quick read, but ultimately lacked the depth I was hoping for.

Show more
Show all reviews

Questions about this book

Jason Fried and David Heinemeier Hansson argue that a small team doing less on purpose beats a big one trying to do everything. Instead of copying competitors, build a simpler product with fewer features, start with about three people, protect working time from meetings, design the interface before the code and make signing up and paying easy. The lessons come from building web applications like Basecamp.

The authors suggest starting with three people. For a web application, that means a developer, a designer and a sweeper who connects design and development. For other businesses, it means one person for the core technology, one for business development and one for finances. If three people cannot build the first version, they say the idea is too ambitious and should be scaled down.

Fried and Hansson suggest counting every planned feature and dividing by two to get the basics, then dividing by two again to find the essentials. Build the product you yourself would want, launch it once it is good enough, as Mark Zuckerberg did with the first Facebook, and answer most requests for extra features, like font formatting in a chat app, with no.

The authors see meetings as time taken from real work, since they tend to drift into abstract ideas. They recommend a strict 30-minute limit, inviting as few people as possible and refusing to attend any meeting without a clear agenda. They also suggest keeping half of each working day free of talking, phone calls and email so people can get into the zone.

No. The examples come from web applications, but the authors present the lessons as useful for executives, marketers, designers and any entrepreneur. Staying small, hiring enthusiastic generalists, cutting meetings, mixing teams across departments, avoiding long contracts and talking to customers in a friendly, human voice all apply well beyond software.

AUDIO SUMMARY AVAILABLE

Listen to Getting Real in 15 minutes

Get the key ideas from Getting Real by Jason Fried, plus 5,000+ more nonfiction titles.

  • 5,000+ titles
  • Listen as much as you want
  • 7-day free trial
  • Cancel anytime

Getting Real

Preview · Full summary 14 min 25 sec
Home

Discover

Open app

Log in