MøllerBeck · Shape Up

from the book from your plan files my inference general knowledge

01 · Why this book, for you, now

Three reasons it fits, one caveat

Shape Up is a book about a specific risk: the risk of not shipping. Singer says this outright — it is not a book about building the right thing, it is a book about the risk of getting stuck, bogged down, and not free to do what you want tomorrow (p. 15). That is the correct target for you.

Reason 1 — Appetite replaces the estimate you cannot make

"Estimates start with a design and end with a number. Appetites start with a number and end with a design." (p. 29) book You have no experiential basis for estimating software work, and you won't for months. Appetite sidesteps the problem entirely: you decide what the thing is worth, then design something that fits. This is the single most transferable idea in the book for a beginner, and it is doubly true with an agent, where the variance between "20 minutes" and "three sessions" is enormous and nobody — including the agent — can predict which you'll get. inference

Reason 2 — The circuit breaker is the counter to the specific way agent projects fail

"If they don't finish, by default the project doesn't get an extension." (p. 80) book The characteristic failure of AI-assisted building is not that the agent can't do it. It is the sunk-cost spiral: three more prompts, then three more, on a codebase you stopped understanding four prompts ago. Each individual prompt feels nearly free, so nothing ever triggers a stop. A fixed appetite with no default extension is an external stop signal that doesn't depend on you noticing. inference

Reason 3 — "Level of abstraction" is precisely the prompting problem

Singer's opening argument is that wireframes are too concrete and words are too abstract (pp. 20–21). book Read that again as a description of prompting Claude Code. "Build me a proposal generator" is words-too-abstract: the agent fills every gap with its own defaults and you get a grab-bag you can't evaluate. Pasting a full specification is wireframe-too-concrete: you've already done the design work, badly, and constrained the agent out of doing anything useful. Breadboarding — places, affordances, connection lines (p. 37) — sits exactly between them, and it is the right shape for a Plan Mode prompt. inference

The caveat: Singer says shapers need technical literacy you don't have yet

"You don't need to be a programmer to shape, but you need to be technically literate. You should be able to judge what's possible, what's easy and what's hard." (p. 25) book You cannot yet. So your first shaping attempts will be wrong — you will set appetites that are far too small and declare things out of bounds that were never in scope. Treat that as the point, not the problem. The gap between what you shaped and what it actually took is the cleanest available readout of your technical literacy. Shaping is the exam your plan's evaluation threshold is studying for. inference

02 · The book, indexed

Three parts, sixteen chapters

Tap a part to open it. Each chapter has what it says and — where there is one — the concrete use for you. Page numbers are the PDF's own.

PART ONE

pp. 20–69

Shaping

Deciding what to build, before anyone builds it

▼

2 · Principles of Shapingp. 20

Rough, solved, bounded. Wireframes over-specify and kill estimation; words under-specify and grow without limit. The Dot Grid Calendar case study: a six-month "calendar" narrowed to a six-week read-only grid.

Use: the three properties are your checklist before you open the terminal. Rough enough that Claude has room; solved enough that you know what "done" looks like; bounded enough that you know what you're refusing.

3 · Set Boundariesp. 28

Set the appetite first. Fixed time, variable scope. Default response to any new idea: "Interesting. Maybe some day." Narrow the problem by asking when the person wanted the thing, not what they want. Watch for grab-bags — anything labelled "2.0" or "redesign X".

Use: the permissions case study (p. 31) is the whole discipline in one story — a six-week request became a one-day warning message once they asked what actually went wrong. Run that test on every tool idea you have.

4 · Find the Elementsp. 35

Breadboarding: places (things you navigate to), affordances (things you act on, including copy), connection lines. Words, not pictures. Fat marker sketches for genuinely visual problems — a pen so thick detail is impossible.

Use: this is the most directly usable technique in the book for you, and it happens on paper, before any code. It is also the only part of shaping you can practise right now regardless of phase.

5 · Risks and Rabbit Holesp. 48

Walk the use case in slow motion looking for holes. Patch them by dictating a solution in the shaped concept. Declare things explicitly out of bounds. "Beware the simple question: is this possible? In software everything is possible but nothing is free — ask, is X possible in six weeks?" (p. 55)

Use: "is this possible?" is the wrong question to ask an agent too. It will say yes. The right question is scoped to your appetite.

6 · Write the Pitchp. 57

Five ingredients: Problem, Appetite, Solution, Rabbit holes, No-gos. Always problem and solution together — a problem with no solution is unshaped work and handing it down is pushing research to the wrong level (p. 60).

Use: the pitch is your Plan Mode prompt and the seed of the project's CLAUDE.md. Template at the bottom of this page.

PART TWO

pp. 72–93

Betting

Choosing what to commit to, six weeks at a time

▼

7 · Bets, Not Backlogsp. 72

No central backlog. Decentralised lists per person or department, none of which feed the betting process directly. "Really important ideas come back to you."

Use: partially. See the contested-claims box below — the "ideas come back" argument is asserted, not demonstrated.

8 · The Betting Tablep. 75

Six-week cycles, two-week cool-down. Two weeks is too short and costs too much in planning overhead. Bets are commitments — uninterrupted time, no pulling people off. The circuit breaker. Bugs wait for cool-down or compete at the table like anything else.

Use: the cycle length is wrong for you and the table doesn't exist. The truths under them do. See §04.

9 · Place Your Betsp. 84

Existing product vs new product. New products go R&D mode (spike, don't ship, senior people only) → production mode (shape properly, ship into the codebase) → cleanup mode (no structure, everyone fixes what's broken, max two cycles).

Use: genuinely relevant later. Your briefing summariser is an existing product. The client intake form is a new one — expect R&D mode and don't shape it prematurely.

PART THREE

pp. 96–151

Building

How the work actually gets done inside the box

▼

10 · Hand Over Responsibilityp. 96

Assign projects, not tasks — splitting work up front "is like putting the pitch through a paper shredder". Done means deployed. Expect radio silence for the first days while the team gets oriented; that isn't idleness.

Use: this is the chapter that does not transfer. See §05.

11 · Get One Piece Donep. 103

Integrate one vertical slice early, don't build horizontal layers and hope. Programmers don't wait for pixel-perfect design — affordances are enough. Program just enough for the next step. Start in the middle: core, small, novel.

Use: the highest-value chapter in the book for you. A thin vertical slice is small enough to read line by line. A horizontal layer is not. This is how Shape Up and your "explain every line" gate stop fighting each other.

12 · Map the Scopesp. 113

Organise by structure, not by person. Scopes are integrated slices that can be finished independently — discovered by doing the work, not planned in advance. Signs they're wrong: hard to say how done it is; the name is generic ("front-end", "bugs"); too big to finish soon. Chowder list for orphan tasks, kept under five items. Nice-to-haves marked ~.

Use: scopes are the unit you hand an agent. One scope per Claude Code session. When the session ends, the scope is either done or you know precisely what's unsolved.

13 · Show Progressp. 127

To-do counts mislead because lists grow as work progresses. Estimates hide uncertainty. The hill: uphill is figuring out, downhill is execution. "Nobody says I don't know" — a dot that hasn't moved is a raised hand. Build your way uphill: thought about it → validated the approach → built enough to believe there are no other unknowns.

Use: works solo, with one addition. See §04, step 7.

14 · Decide When to Stopp. 142

Compare down to baseline, not up to the ideal. Scope hammering — the questions on p. 146 are a real checklist. Cutting scope isn't lowering quality. QA is for edges, not a gate. Extend only if the remaining work is all must-have and all downhill.

Use: "compare to baseline" is the calibration you're missing. Baseline for your summariser isn't a polished product — it's you reading a spreadsheet before a client call.

15 · Move Onp. 150

Let the storm pass. Stay debt-free — a gentle no to your own follow-up ideas. Feedback is a raw idea; it has to be shaped before it's actionable.

Use: after you ship anything you use in the business, you will immediately think of six improvements. Each is a raw idea. None is a project.

Appendicespp. 156–175

Basecamp implementation (skip). Adjust to Your Size (p. 165) — separates basic truths from scale-dependent practice; explicitly says a two-or-three person team should throw out cycles, cool-down, pitches and the betting table and just alternate hats deliberately. How to Begin (p. 169): fix shipping first. Glossary p. 172.

Use: read pp. 165–171 first, before anything else. It is Singer giving you permission to strip the ceremony, in his own words.

03 · Translation layer

Basecamp's fifty people → you and an agent

Every role in the book collapses into you, except one, which collapses into Claude Code. That collapse is what makes the method both easier and more dangerous to run.

Shaper (product strategist)

You, on paper, before the terminal

Closed-door, rough, private. Singer's point that this work is deliberately not shared until it's bet on applies exactly: don't show Claude a half-formed idea, it will start building it.

Betting table (CEO, CTO, senior dev)

A written appetite and a stop date

You have nobody to say no to you. The substitute is weak but real: write the appetite and the stop date down before starting, where you'll see it. Unwritten appetites are not appetites.

Build team (designer + 2 programmers)

Claude Code, one scope at a time

Fast, tireless, no stake in the outcome, no judgment about whether the project is worth it. It will not scope-hammer. That job stays with you.

Cycle (6 weeks × 3 people ≈ 720 hrs)

Your cycle ≈ 2 weeks × 12 hrs = 24 hrs

A Basecamp big-batch bet is roughly 30× your six weeks in person-hours. The agent closes some of that gap on typing speed, none of it on your reading speed — and reading is your bottleneck.

Kick-off message with the pitch

Plan Mode prompt + project CLAUDE.md

Singer posts the pitch as the first thing in the project. Do the same: the pitch's no-gos and rabbit-hole patches belong in CLAUDE.md, where they persist across sessions.

Hill chart in Basecamp

Three lines in a text file per scope

Scope name · uphill/downhill · date last moved. The value is the second-order view — what's stuck — not the graphic.

QA person, late in cycle

Running it on real, messy client data

Your plan already has this as a scheduled day. Singer's framing — QA is a level-up, not a gate — is the right expectation.

Cool-down (2 weeks)

Consolidation sessions

Your plan's "read every file, comment anything you can't explain" day is structurally a cool-down. Keep it. It is where the learning consolidates and where small fixes go.

04 · The protocol

Eight steps, from raw idea to shipped

This is what "guiding actual work" looks like in practice. Steps 1–4 happen away from the computer. Step 5 is the only place a bet gets made. Steps 6–8 are inside the box.

Refuse the raw idea

"Interesting. Maybe some day." (p. 31) Your default answer to every tool idea, including your own good ones. An idea that is genuinely load-bearing will come back; one that doesn't come back was a mood.

In practice: keep a plain text file of raw ideas. It is not a backlog — you never groom it and it is not an input to anything. It exists so ideas stop occupying your attention.

Set the appetite before you understand the problem

Not after. The number comes first and constrains the design (p. 29). Use the sizes in §05 below, in hours, not weeks — weeks are meaningless when your weeks contain twelve working hours.

The test: if you can't say what this is worth without first knowing how hard it is, you're estimating, not setting an appetite. Ask instead: what would I pay someone for this outcome?

Narrow the problem — ask when, not what

Singer's calendar case study (p. 32): they didn't ask the customer what a calendar should do, they asked when she wanted one. The answer — driving to the office to check a wall calendar — turned "build a calendar" into "help me see free spaces". A six-month project became six weeks.

For your own tools you are the customer. Ask yourself: the last time I wished this existed, what exactly was I doing, and what did I do instead? That specific story is the problem definition. If you can't produce one, you don't have a project yet.

Grab-bag alarm: "proposal first-draft generator" is at risk of being a grab-bag in the same way "Files 2.0" was (p. 33). Narrow it to one proposal, one client type, one section you actually hate writing.

Breadboard it on paper

Places underlined, affordances listed beneath them, lines between. Words only. Ten minutes, no screen. Then walk the use case in slow motion looking for holes (p. 50), and patch or fence anything you find.

Why paper and not Claude: if you breadboard in the chat, you will be reacting to the agent's suggestions instead of finding out what you actually think. Singer's insistence that shaping is closed-door is doing real work here.

Write the pitch and date the stop

Five ingredients (template below). Then write one more line the book doesn't have: the date you stop. Compute it from your real available hours, not from the calendar.

This is your betting table. It is a poor substitute for four people who can say no, and you should know that. What it does supply is a written commitment made while calm, that a later, more invested version of you has to argue against explicitly rather than drift past.

Get one piece done — core, small, novel

One vertical slice, end to end, in the first sessions. Core to the concept; small enough to finish; and where two candidates are both core and small, pick the one you've never done (p. 112). Start in the middle — stub the login, stub the file handling, go straight at the interesting part.

The learning payoff: a vertical slice of a real feature is a few dozen lines. You can read it all. A horizontal layer — "build all the data handling" — is hundreds of lines you'll wave through. Shape Up's sequencing rule and your evaluation gate want the same thing.

Map scopes; track uphill/downhill with a second axis

Break the work into slices that finish independently. Then track each on the hill: uphill means unknowns remain, downhill means only execution is left. A dot that hasn't moved in two sessions is a raised hand (p. 136).

The addition for you: a scope is only downhill when both are true — the approach is proven, and you can explain what the code does without looking it up. Working code you can't explain is uphill. That is not Singer's rule; it is the one modification your situation requires, and without it the hill chart will lie to you.

Stop by comparing down, then move on

Compare to baseline, not to the ideal (p. 143). Run the scope-hammering questions (p. 146): could I ship without this? What happens if I don't do it? Is this a new problem or one I already live with? Mark survivors ~ and cut them.

Baseline for your tools is you, doing it by hand. A script that formats four of five client fields correctly and saves you fifteen minutes beats a spreadsheet. That is the comparison, and it is much more forgiving than the one you'll instinctively make.

Then stay debt-free (p. 150). The improvements that occur to you an hour after shipping are raw ideas. They go in the text file from step 1. They do not go into the current project.

05 · Appetite sizes, recalibrated

Six weeks is the wrong number for you

Singer's own reasoning is that a cycle must be short enough that you feel the deadline from the very beginning (p. 76) — that's the constraint, not the number six. At ~12 hours a week, six calendar weeks is 72 hours and the deadline is invisible for the first month. These are the sizes that preserve his logic at your throughput.

Session

2 hrs

one weekday evening

One scope. One thing you can click at the end. If a scope doesn't fit here, it isn't a scope yet.

Small batch

6 hrs

≈ 3 sessions

A self-contained addition to something that already works. Add a field, change an output format, handle a new error case.

Big batch — your default

24 hrs

≈ 2 weeks

A whole small tool, shaped and shipped. Everything in your plan's project list is this size. This is the unit to think in.

Ceiling

48 hrs

≈ 4 weeks

Deployment projects only, where hosting and environment setup add irreducible overhead. Above this, the appetite is fiction — narrow the problem instead.

The arithmetic behind this

A Basecamp big-batch bet is one designer and two programmers for six weeks — roughly 720 person-hours. book, p. 77 Six of your weeks at 12 hours is 72. plan files Ratio: about 10 : 1, and closer to 30 : 1 against the three-person team's parallel throughput. The agent recovers a large part of the typing, none of the reading — and since you must read everything, reading is the binding constraint. inference Note the two-week plan actually schedules ~14 hrs/week; 12 is the figure in your project instructions. Use 12 for planning and treat the extra as slack.

06 · Where it enters the learning plan

Phase by phase

Shape Up is not a Phase 4 topic. Part One is paper work and enters immediately; Part Three needs a codebase and waits.

▶ You are here · conceptual language building; no environment yet

Read pp. 165–171. Then shape the environment as your first bet.

No Claude Code, no Git, no repository, no local project — all work so far in the desktop app, and the vocabulary is coming. That splits cleanly against Singer's own division of labour: you have started on the shaping half and not on the building half. Shaping needs technical literacy to judge what's easy and hard (p. 25), and conversation builds exactly that. It does not build the environment, and the two are not substitutes.

The relevant claim: conceptual fluency about programming and the ability to evaluate code are separable, and the first can grow indefinitely without the second. Your own plan anticipates this — every gate in it is "paste your code," not "explain the concept." Singer's version is on p. 170: fix shipping first. Build the muscle for finishing before improving anything upstream of it.

Concretely: the first thing to run this method on is the environment setup itself. It is bounded, it has a known shape, and it is a notorious rabbit hole — which makes it the ideal first pitch. Appetite, elements, holes patched in advance, no-gos. See the strip below.

Phase 3 · Weeks 9–14 — where the whole method lands

Pitch → Plan Mode → scopes → explain-gate

This is the phase Shape Up was written for, transposed. You shape; Claude Code builds; you evaluate. The pitch becomes the Plan Mode prompt. The no-gos and rabbit-hole patches become CLAUDE.md entries so they survive between sessions. Scopes become the unit of a session. Your plan's rule that a task too large to evaluate line-by-line must be broken down is Singer's scope-mapping rule arriving from the other direction.

Concretely: next Claude Code project, don't start in the terminal. Write the five-ingredient pitch first, then paste it into Plan Mode as the opening move.

Phase 4 · Weeks 15+

Cycles become real; R&D vs production mode starts to matter

The client intake form is a new product in Singer's sense (p. 84) — deployment, hosting, a database, auth. Expect R&D mode: spike, don't ship, don't shape it prematurely, and don't judge the first cycle by whether anything shipped. Then production mode once the architecture settles. Then cleanup, capped at two cycles.

Concretely: the failure mode here is shaping the intake form as though you already know the architecture. You won't. Bet a cycle on learning it.

07 · What does not transfer

Four places the book breaks on your situation

1. You cannot hand over responsibility

Chapter 10 is built on trusting a team to look after the whole because "the designers and programmers doing the real work are in the best position to make changes and spot missing pieces" (p. 97). book An agent is not in that position. It has no stake, no memory across sessions by default, and no judgment about whether the project is worth finishing. Give the agent a scope; never give it the project. The pitch, the appetite, the trade-offs and the decision to stop stay entirely with you. inference

2. There is no betting table, and the substitute is genuinely weaker

The circuit breaker works at Basecamp because someone else enforces it. Alone, you are both the person who set the appetite and the person who wants to keep going. A written stop date helps; it does not make you a betting table. Name this honestly rather than pretending the written date is equivalent. If you want something closer to the real thing, the nearest available mechanism is bringing the pitch into a session here before you start, and the overrun after — which turns your appetite into a commitment someone else witnessed. inference

3. "Important ideas come back" is asserted, not demonstrated

The no-backlog argument (p. 74) rests on a claim about memory that Singer supports with a rhetorical question — "when's the last time you forgot a really great idea?" book This runs against what's known about how unreliably people recall their own past intentions; the general finding that memory for intentions is poor and reconstructive is well established, though I'm not aware of research testing this specific claim in a product context. general The practical fix is cheap: keep the raw-ideas file. It costs nothing and doesn't become a backlog unless you start grooming it. inference

4. Six weeks, cool-down, and two tracks are scale-dependent — Singer says so himself

"A tiny team can throw out most of the structure... Set an appetite, shape what to do next, build it, then shape the next thing. Your bets might be different sizes each time." (p. 166) book Don't run cycles. Don't run a cool-down as a fixed calendar block. Alternate hats deliberately and know which one you're wearing. The one thing you should not throw out is the appetite, because that's the load-bearing piece.

08 · Evidence status

How much weight this book can carry

What it is

A practitioner report from one company, written by an insider, describing what worked there over fifteen years. Singer is explicit that it is "a book of practice, not theory" (p. 10) and that the specific practices are scale-dependent (p. 165). There is no controlled evidence that six-week cycles outperform two-week sprints, and none is offered. Widely adopted and widely liked is not the same as validated. general

Which parts have independent support

Two. Abandoning estimates has real backing: the planning fallacy — systematic underestimation of one's own task completion times, robust across domains — is one of the better-replicated findings in judgment research (Kahneman & Tversky; Buehler, Griffin & Ross). Appetite dodges it structurally rather than trying to debias. Fixed time with variable scope is timeboxing under another name and has a longer independent track record than Shape Up itself. general

Which parts are craft, not evidence

The hill chart is a visualisation, not a validated instrument — its value is that it prompts a conversation about unknowns, and it inherits whatever accuracy the person moving the dot has. Six weeks specifically, the two-week cool-down, and the no-backlog position are Basecamp's practice. Useful defaults; not findings. Treat them as such and the book holds up well. inference

09 · The pitch template

Copy this. It is also your Plan Mode prompt.

Five ingredients from p. 58, plus the stop date the book doesn't need and you do.

PROBLEM — one specific story of the last time this went wrong. Not a category.
APPETITE — hours, decided before you understood the problem. 2 / 6 / 24 / 48.
SOLUTION — the breadboard, written out. Places, affordances, connections. No implementation detail.
RABBIT HOLES — the decisions you're dictating in advance so nobody wanders into them.
NO-GOS — what this explicitly does not do. Put these in CLAUDE.md.
STOP DATE — computed from real available hours, written before starting.
DONE MEANS — the output exists, I've used it once for real work, and I can explain every line.

Sourcing. Page numbers, quotations and all method descriptions are from the attached PDF — Shape Up: Stop Running in Circles and Ship Work that Matters, Ryan Singer, Basecamp, 176 pp. Phase structure, project list, hours-per-week and the session protocol are from your project instructions and two_week_plan.html / jakob_learning_plan_mobile.html. The planning-fallacy and timeboxing references are general knowledge and are not drawn from the book. Everything tagged inference is my own reasoning about how the method maps onto solo work with an agent — none of it is Singer's claim and none of it has been tested.

Assumption this rests on: that no environment exists yet — no Claude Code, no Git, no repository — and that the work so far has been conceptual, in the desktop app. That makes §04 steps 1–5 (shaping, on paper) live immediately and steps 6–8 (scopes, hill chart, scope-hammering) a discipline to read once now and apply once a real project is running. The appetite sizes in §05 apply to anything, starting with the setup session itself.

Prepared 13 August 2026 · week 14 by the calendar since the plan began 11 May 2026