A Walkthrough of the Rework Skill: Building a Better Business by Doing Less
Five commands that apply Fried and Hansson's anti-conventional business wisdom — cutting meetings, launching faster, and building a product that solves your own problem.
Jason Fried and David Heinemeier Hansson built Basecamp into a profitable software company by deliberately ignoring conventional business advice. Rework collects their operating principles: stay small, launch fast, meetings are toxic, outside money is a last resort, build what you use yourself.
The Rework BookSkill has five commands that apply these principles. Here's what each does.
The Five Commands
/scratch-your-itch — Solve Your Own Problem
What it does: Fried and DHH's most consistent finding: the best businesses are built on problems the founders themselves experienced. Scratching your own itch means you understand the problem deeply, you know when a solution is good, and you have genuine motivation to make it excellent. This command helps you identify problems in your own experience that are worth solving.
What you get: A problem-solution fit assessment — the specific problems you personally experience that have inadequate current solutions, evaluated against Rework's criteria for a good business opportunity.
When to use it: When exploring new product or business ideas. The scratch-your-itch filter is an effective early screen for ideas that will maintain your genuine investment.
/meeting-audit — Kill Unnecessary Meetings
What it does: Fried's most cited argument: meetings are toxic. They interrupt work, they produce vague conclusions, they require too many people to stop doing real work simultaneously. This command audits your current recurring meetings and identifies which ones should be eliminated, which should be made async, and which are genuinely necessary.
What you get: A meeting elimination plan — specific meetings to cancel or convert, with a framework for making the same things happen more efficiently.
When to use it: When your calendar is dominated by meetings. The meeting audit typically reveals that 30–50% of recurring meetings can be eliminated without any functional loss.
/launch-now — Cut Until You Can Ship
What it does: Fried's launch philosophy: the best way to get feedback is to ship something real. Not a polished 1.0 — the smallest version that could be genuinely useful to someone. This command takes your current project and helps you cut scope until there's a version you could launch this week or this month.
What you get: A minimum launchable product plan — what to include, what to cut, and a specific launch timeline.
When to use it: When a project has been in development longer than you'd like, when scope has expanded beyond the original intent, or when you're waiting for "one more thing" before launching.
/say-no-default — Build a Policy of Restraint
What it does: Fried's principle: the default answer to feature requests, scope additions, and new ideas should be no — not because the ideas are bad, but because adding things is easy and removing them is hard. The best software (and businesses) are defined as much by what they don't do. This command helps you build a no-by-default policy and practice it.
What you get: A no-by-default policy for feature requests and scope additions — the criteria for what earns a yes, and specific scripts for communicating no to customers, team members, and stakeholders.
When to use it: When scope creep is a recurring problem, when your product is becoming complicated, or when you're struggling to maintain simplicity.
/good-enough — Define Done
What it does: Fried and DHH's observation: done is better than perfect, and perfect is often the enemy of shipped. This command helps you define the "good enough" version of your current project — the version that solves the problem adequately without the perfectionistic additions that are preventing launch.
What you get: A good enough scope definition — the specific criteria for what "done" looks like for your current project, and what falls outside that scope.
When to use it: When you're in the final stretch of a project and the goalposts keep moving. The good enough definition makes "done" concrete and specific rather than subjective.
Recommended Sequence
/scratch-your-itch— validate that you're solving a real problem/meeting-audit— free up time by cutting unnecessary overhead/launch-now— scope the minimum launchable version/good-enough— define done clearly/say-no-default— build restraint into your ongoing decisions
What Rework's Philosophy Delivers
The core of Fried and DHH's philosophy is a resistance to growth-for-its-own-sake. They're not anti-growth — they're pro-profitability, pro-simplicity, and anti-complexity. A business that does fewer things excellently is more sustainable than one that does many things adequately.
The Rework Skill operationalizes that philosophy: fewer meetings, smaller scope, faster launches, a default of no. Each command produces a concrete output that moves in the direction of simpler, leaner, and more sustainable.
Ready to simplify your business? Get the Rework BookSkill and start with /meeting-audit.