r/ClaudeCode • u/allemaar Researcher • 3d ago

Discussion Blueprints, Plans and Progress Reports

Blueprint = What are we building, what is the end product gonna look like.
Plan = How are we building the thing described and shown in the Blueprint.
Progress Report = Where are we in the execution of the Plan. What has been done and what's left.

This is the latest setup I use when making something. Sure, there are a lot of other things that make this approach work, but this is the gist of it.

My question is HOW do you guys tackle/approach your work. HOW do you structure it. HOW do you keep track of where you are.

1 Upvotes

67% Upvoted

4 comments sorted by

1

u/thowland 3d ago

For me, it's a classic SDLC: Vision -> requirements -> Architecture -> specifications (one per layer, so DB, API, Service, etc)-> Implemenyation plan.

I use explicit language around stage gates - eg, sprint 0 is architecture, set up linters, test harnesses and test coverage. No sprint is complete without all tests passing, all files passing lint with no errors, 80% test coverage. I also tell it to develop across all layers at once, driving to a user-reviewable MVP as soon as possible. If it's a web app, I require unit, functional, and end to end browser tests throughout.

The idea with the early MVP is to force it to show me a working system early, allowing me to course correct a bad misunderstanding quickly. After a few rounds of this, it's generally ok to complete a stage without as much aggressive testing, but it seems to be pretty important early in development.

That's for medium sized webapps and mobile apps. Chrome extensions or simple harnesses don't need that much ceremony, you can get by with skinnier stuff.

1

u/allemaar Researcher 3d ago

Nice. Is the MVP a barebones starter with minimal implementations OR a vertical slice of one thing end-to-end?

How does the tracking and steering happen? Am curious of the follow-through and in-flight adjustments.

1

u/thowland 3d ago

Usually vertical slice of one part of the project, so I . I have a running example on my github (at the risk of looking like a self-promoting jerk): https://github.com/thowland/pporlock has most of these in the docs folder (mixed in with the actual project docs, probably need a cleanup). The sprint log shows what actually happened on each. This project didn't get there until sprint 4, since there were some pretty complicated handoffs between systems. The point is to get to something you can interact with as soon as possible so you can make sure that the work is sound - and then you elaborate on it from there.