37signals-way — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited 37signals-way (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
A system for building profitable software without bloat, bureaucracy, or burnout, distilled from three books: Getting Real (build less), Rework (say no by default), and Shape Up (fix time, flex scope). Use it to shape work, bet on six-week cycles, run small autonomous teams, and ship on a predictable cadence.
Build less. The best products do fewer things exceptionally well — simplicity is the destination, not the starting point. Traditional development adds; the 37signals way subtracts: build half a product (not a half-assed product), say no by default, fix the time and flex the scope. Constraints are what make great work possible — six weeks, three people, and a shaped pitch force you to find the essential version.
Goal: 10/10. Rate product plans, feature scopes, and team processes 0-10 against these principles. Report the current score and the specific changes needed to reach 10/10.
Core concept: Win through deliberate omission — fewer features, fewer preferences, fewer moving parts, each done better than competitors do theirs. Build software you need yourself and solve problems you understand deeply.
Why it works: Every feature carries maintenance, cognitive, and opportunity costs forever, usually for a fraction of users. Building less keeps the product focused, the codebase manageable, and the team small.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature prioritization | Default answer is no | Reporting dashboard requested → ship CSV export covering 90% of use cases |
| MVP scoping | Cut until it hurts, then cut more | Drop user accounts for v1; use email magic links |
| Competitive strategy | Underdo, don't outdo | Competitor has 50 integrations; ship 3 that work flawlessly |
Ethical boundary: Cut complexity, not accessibility or safety — "less" means focused, not neglectful.
Core concept: Before work reaches a team, a senior person who bridges product and technical worlds makes it rough (room to maneuver), solved (main elements figured out), and bounded (scope limited by appetite).
Why it works: Raw ideas waste team time; detailed specs turn teams into ticket-takers. Shaping removes the biggest unknowns while leaving design freedom, and appetite ("how much time is this worth?") replaces estimation ("how long will this take?") — bounded investment instead of open-ended commitment.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature design | Breadboard before mockup | "Invite teammate": Settings → invite form → email sent → accept link → dashboard |
| Scope definition | Set appetite first | "A 2-week appetite problem, not a 6-week one" shapes which solution fits |
| Risk management | Call out rabbit holes upfront | "Permissions could get complex — limit to owner/member for v1" |
Ethical boundary: Set appetites that reflect the problem's genuine value — never artificially small to pressure teams.
See: references/shaping-work.md
Core concept: Replace backlogs and roadmaps with a betting table: senior stakeholders bet shaped pitches into six-week cycles, separated by two-week cool-downs. Unfinished work hits the circuit breaker — it does not automatically continue.
Why it works: Backlogs grow forever, create false progress, and dilute focus; limited cycle slots force real prioritization. The circuit breaker kills zombie projects, and cool-downs prevent the burnout of continuous sprinting.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Roadmap replacement | Bet each cycle | 3-4 shaped pitches every 6 weeks instead of a 12-month roadmap |
| Risk management | Circuit breaker kills zombies | 70% done at week 6? It doesn't ship — re-shape and re-bet if it still matters |
| Capacity planning | Cool-down between cycles | Two weeks for bugs, tech debt, exploration, recovery |
Ethical boundary: Apply the circuit breaker honestly — to kill zombies, not politically inconvenient projects; the point is focus, not unsustainable pressure.
See: references/betting-cycles.md
Core concept: Three-person teams (one designer, one or two programmers) work a shaped pitch autonomously — no standups, no PMs hovering. They discover their own tasks and track progress on hill charts.
Why it works: Three people can have a conversation; ten need a meeting. Teams that discover tasks from a shaped pitch develop real problem understanding, and hill charts tell the truth: uphill = still figuring out, downhill = executing known work.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Team structure | Three people max, no PM | One designer + two programmers per 6-week bet |
| Progress tracking | Hill charts, not burndowns | "Invitations" uphill (permissions unclear); "Email templates" downhill (executing) |
| Communication | Async-first, write it up | A written update or 5-minute video instead of a 30-minute meeting |
Ethical boundary: Autonomy requires genuinely manageable scope — if a team consistently works overtime to hit six weeks, fix the shaping, not the team.
See: references/small-teams-execution.md
Core concept: Great software makes choices instead of burying users in preferences — every preference is a decision the team could not or would not make. The same honesty applies to copy: say what you mean, skip buzzwords, teach what you know openly.
Why it works: Software with 47 settings has no opinion; sensible defaults reduce cognitive load and create cohesion. Clear copy builds trust where marketing-speak erodes it, and teaching openly attracts customers who share your values.
Key insights:
Product applications:
| Context | Application | Example |
|---|---|---|
| Feature requests | Default no, no false promises | "Thanks for the suggestion. We're not planning this right now." |
| UI copy | Plain language | "Your file is saved" not "Your asset has been successfully persisted to the cloud" |
| Error messages | Honest and helpful | "We couldn't send that email. Check the address and try again." |
| Preferences | Eliminate; choose defaults | Detect timezone from the browser; ship one good theme |
| Marketing | Honest positioning | "Basecamp is not for everyone. Here's who it's for and who it's not for." |
Ethical boundary: Opinionated means having a point of view, not ignoring feedback — listen carefully, then curate thoughtfully.
See: references/opinionated-software.md, references/ux-ui-copy.md
| Mistake | Why It Fails | Fix |
|---|---|---|
| Maintaining a backlog | Grows forever; false progress; diluted focus | Abolish it; bet on shaped pitches each cycle |
| Estimating instead of setting appetite | Estimates grow to fill time and invite negotiation | Ask "how much time is this problem worth?" |
| Pixel-perfect mockups before shaping | Too concrete too early; invites bikeshedding | Breadboards and fat marker sketches first |
| Extending a six-week cycle | Zombie projects teach teams deadlines are fake | Circuit breaker: not done means not shipped |
| Adding preferences instead of deciding | Complexity for all users to serve a few | Pick the best default and ship it |
| Daily standups and status meetings | Interrupt maker flow; reporting overhead | Hill charts for visibility; async updates |
| Saying yes to good feature requests | Good features still add non-essential complexity | Default to no; bet only on what matters this cycle |
| Planning multiple cycles ahead | Stale commitments reduce responsiveness | Plan one cycle at a time |
| Question | If No | Action |
|---|---|---|
| Is there a fixed time constraint on this work? | Scope expands indefinitely | Set a six-week (or smaller) appetite first |
| Is the work shaped (rough, solved, bounded)? | Scope problems surface mid-build | Define problem, appetite, solution, rabbit holes, no-gos |
| Can a team of 2-3 people do this? | Too big | Break into independent six-week bets |
| Said no to at least 5 things this cycle? | Building too much | Cut ruthlessly at the betting table |
| Is the team figuring out its own tasks? | Micromanagement; team not empowered | Hand off shaped pitches, not task lists |
| Tracking progress with hill charts? | False precision masks uncertainty | Switch to uphill (figuring out) vs. downhill (executing) |
| Is there a cool-down after this cycle? | Burnout; no cleanup time | Schedule two unstructured weeks between cycles |
| Does the software have a clear opinion here? | Decisions deferred to users via preferences | Pick the best default; remove the setting |
Jason Fried is co-founder and CEO of 37signals (Basecamp, HEY) and a leading advocate for calm companies and product simplicity. David Heinemeier Hansson (DHH) is 37signals co-founder and creator of Ruby on Rails, extracted from Basecamp's codebase; together they wrote Getting Real, Rework, Remote, and It Doesn't Have to Be Crazy at Work. Ryan Singer spent 15+ years shaping product at 37signals and codified the methodology in Shape Up.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.