Rework
Jason Fried & David Heinemeier Hansson
Rework is Jason Fried and David Heinemeier Hansson's collection of short, blunt arguments against the startup consensus: planning is guessing, constraints are an advantage, meetings are toxic, and the way to beat a competitor is to underdo them. Its practical core is to build half a product properly, launch it now, and let customers write the roadmap.
You have been told that you need a plan, funding, a bigger team and a full feature list before you can launch. Rework was written by two people who built a profitable software company with none of those, and who think the advice is not just unnecessary but actively harmful. Each chapter is a page or two, and most of them will annoy you before they convince you.
The book in essence
The book's spine is subtraction. Fried and Hansson argue that most of what founders do, long-term planning, chasing scale, raising money, hiring ahead of need, matching competitors' features, holding meetings, is done because it looks like what a company does, not because it produces anything. Their alternative is to work with what you have: constraints force you to find the essential thing, which is the thing customers pay for. Planning is guessing, so plan for the next few weeks and treat the plan as a guess you expect to replace. Build half a product rather than a half-assed one, by cutting scope instead of quality. Underdo the competition: do fewer things than they do and do them better, and let simplicity be the reason to choose you. And launch now, because the market teaches faster than the roadmap.
The authors built Basecamp, a project-management tool, from a design agency's side project into a company that has stayed small, profitable and independent for two decades, and Rework is the philosophy written down. It is a book of chapter-length aphorisms rather than a method, and it works best as a corrective read alongside the more procedural books on this road.
Who it's for
- Founders with a small team and no funding who have been told that is a problem
- Anyone stuck in a build that keeps growing, waiting for one more feature before launch
- Managers whose weeks have become meetings and who suspect the work happens somewhere else
Who it's not for
- — Founders in deep-technology businesses where the product genuinely cannot ship half-built, such as medical devices or hardware
- — Readers who want evidence and method; the book asserts, and its authority is its authors' own company
Key lessons
01
Planning is guessing
A long-term plan is written by people who do not yet have the information, and calling it a plan makes it hard to abandon when the information arrives. Fried and Hansson's advice is to decide for the next few weeks, write plans as guesses, and treat the willingness to change them as a strength rather than a failure of discipline.
A founder in Bursa spent six weeks on a three-year plan for investors and then followed it for eight months after the market had told her it was wrong. The team that replaced it with a monthly guess, revised every four weeks, shipped more in the following quarter than in the previous year.
02
Embrace constraints
Less money, fewer people and less time are not obstacles but editors. Abundance produces waste: hiring before need, features nobody asked for, plans for a scale that never comes. A constrained team has to choose, and choosing is where the product gets good. The founder who complains about constraints is usually describing the thing that will save them.
Two founders in Gaziantep could not afford a salesperson, so they installed their software in each textile workshop themselves. Watching it used badly taught them twenty fixes that made the difference between a demo and a product; competitors with sales teams never watched a single installation.
03
Build half a product, not a half-assed product
Cutting scope is how you protect quality. The instinct is to include every feature at reduced quality; the rule is to include fewer features at full quality and leave the rest out entirely rather than half-done. A product that does one thing well is easier to explain, easier to build and easier to love than one that does ten things adequately.
A restaurant-reservation app in Istanbul launched with one feature, a booking confirmed by SMS, to eight restaurants in Kadıköy. Within a month they asked for a no-show deposit, which none of the founder's planned loyalty or waiting-list features had covered, and it became the feature that made the product pay.
04
Underdo your competition
Matching a rival's every feature and adding one produces a product that does everything adequately and nothing well, built by an exhausted team. Do less than they do, do it better, and make the simplicity the pitch. Customers do not choose the longest feature list; they choose the product that solves their problem without making them learn a system.
A note-taking startup in Ankara competed against a tool with two hundred features by shipping one: notes that synced instantly and never lost a word. Its onboarding was a single screen. It won the freelancers and students the bigger tool's complexity had been quietly losing.
Try this today
List every feature in your current build, cut everything a real customer has not described needing in the past tense, and set a launch date for what remains within two weeks.
Quick check
What do Fried and Hansson mean by 'build half a product, not a half-assed product'?
Why do the authors say planning is guessing?
Selected quotes
“Planning is guessing.”
“Build half a product, not a half-assed product.”
“Meetings are toxic.”