Build Club Week Two: The PRD doesn't catch everything

Source: Dev.to

Building the Week

Last week I posted that I had no code, just the work that makes the code possible: the PRD, the prompt spec, the architecture doc, and the build brief for Kiro. I went into this week thinking I had every decision pre‑made.

Then I started building.

• By Block 2, real testing surfaced a phrase the model was using that no court employee would say. “Strip identifiers” sounds reasonable to a developer, but to a court clerk it is opaque and technical—the kind of thing you’d skip past in training. Not a bug, exactly, and not in the PRD either, but noticeable.
• By Block 3, I was flagging contrast questions, helper‑text microcopy, and a disabled state that needed verifying. None of these were in the original scope, nor were they stop‑the‑build issues, but they were real.
• By Block 4, I was holding a list of polish items in my head while running an active build. Around 11 pm I asked Claude how it was tracking everything. The answer was honest: it wasn’t, in any reliable way. That was exactly the kind of “I’ll remember it” trust I’d called out as a problem in my own build brief, and I’d let it creep in anyway.

The Punchlist

The punchlist isn’t the PRD. The PRD says what to build; the punchlist captures what surfaces when you actually build it. They have different jobs and need to live in separate documents.

By the end of the week my punchlist grew to:

• 14 polish items
• 8 items deferred to v2
• 4 clean‑ups before deployment
• 4 lessons‑learned entries

Some of these were scope‑creep waiting to happen—the “we should add this, it’s only an hour” thinking that turns four‑week builds into eight‑week builds. Others were real bugs the PRD couldn’t have predicted because I hadn’t shipped enough of the product yet to discover them. And some were language I knew was wrong the moment I read it back to myself in the voice of an actual court employee.

What I’d Do Differently

Start the punchlist on day 1, alongside the PRD. Not as a section of the PRD (they have different jobs), but as a sibling document, ready and waiting. Treat the empty punchlist as a feature instead of a placeholder.

Takeaways

• The PRD locks scope; the punchlist holds everything the PRD couldn’t see yet.
• Both documents are needed.
• The discipline isn’t writing a perfect PRD; it’s knowing which document a thought belongs in and putting it there immediately, rather than trusting yourself to remember.

Next Week: Polish and Deployment

Week three is focused on polish and deployment. The running punchlist will guide us through:

• Loading‑state experience for latency
• Brand banner in the PDF
• Mobile responsiveness
• AWS Amplify deployment to a live URL

Building alongside Build Club in the Women in AI Accelerator. Tagging Annie Liao and Caroline Ciaramitaro who run a thoughtful, generous community.