Plan, Build, Review: The Loop That Compounds

It is Monday, and the thing you are building mostly works. You open a new session and type “ok, what next”. The assistant suggests five ideas, you pick the one that sounds fun, and by Thursday nobody can say what got finished.

Here is one round of work done the slow way, start to finish, on a made-up project: a booking page for a small pottery studio, where people book a class and pay a deposit. It is an illustration, not a customer.

What goes into the plan

A plan starts by reading, not writing. Look at what came back from the last round, including anything you noticed and parked, then at the backlog and where the project is heading.

Out of that comes a small batch, usually 3 to 8 tasks. The studio gets four. Add a waitlist for full classes. Send a reminder the day before. Fix the double booking a customer hit last week. Let the owner cancel a class. Each task gets a size estimate and one line on why it made the cut.

The plan also says what is waiting on purpose: gift vouchers stay parked until booking is solid. That batch, built, reviewed and released, is one cycle.

One handoff, written out

Each task then gets a build handoff: a brief an assistant with no history on the project could build from correctly. Here is the waitlist one.

Goal. When a class is full, a customer can join a waitlist. When someone cancels, the first person on the list is emailed the place, and it is held for them for 12 hours.

Out of scope. No payments on the waitlist, no change to deposits, no redesign of the class page.

How to check it is done. Fill a test class, join the waitlist as two people, cancel one booking. Only the first person gets the email. If they do nothing for 12 hours, the offer moves to the second.

Risks. Capacity is checked in the booking form, so anything that touches it can reopen last week's double booking. Likely files: the booking form, the cancellation handler, the email templates.

Write how you will check it is done before anyone builds it, or review turns into a mood.

What comes back from the build

Your assistant builds from the handoff, then files a report. It is short, and written for the next plan rather than for you.

The waitlist was estimated as small and took about twice that, because capacity turned out to be stored in two places that disagreed: on the class itself and as a cached count on the schedule page. The build fixed only the waitlist side, as scoped. While testing, it also noticed that cancelled classes still show on the owner's admin page.

None of that was in the plan. All of it matters to the next one.

A verdict, with a reason

Review is yours. For each task you call it: accept, request changes or reject, and you write down why. The reason is the useful part.

You run the check from the handoff. The first email arrives. Then you wait out the 12 hours, and the offer never moves on.

Verdict: request changes. Reason: the hold never expires, so a full class can keep an empty seat forever, worse than no waitlist. The reminder and the double booking fix are accepted. Owner cancellation is rejected: it emailed every customer the instant the button was pressed, with no confirmation, and that needs rethinking rather than patching.

What the next plan does with it

The next plan reads the reports and the verdicts before it looks at the backlog.

Capacity in two places becomes its own task, first in the batch, because other work leans on it. The waitlist comes back with a narrower handoff whose check for done is exactly the case that failed. Owner cancellation returns with a confirmation step written into its goal. Anything touching bookings gets a bigger estimate, because the last one ran long. The stale admin page goes into the backlog instead of getting lost.

You can run this with a notes file and some discipline. PAPI is a project manager that works inside your AI chat, and it runs the same cycle: each task gets a build handoff, and every build files a report the next plan reads first. The verdict stays yours, and PAPI does not write code. Why rounds like this add up over months is in Loop Engineering: Why AI Workflows Spin Instead of Compound.

When it is overhead

For a throwaway prototype, all of this is overhead. If you expect to bin most of what you build this weekend, skip the handoffs and the reports. A written check for done on code you will delete on Tuesday is ceremony.

The cycle earns its keep once the project stops being disposable and no longer fits in your head. If that is where you are, walk one cycle on a demo project, no signup needed.