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, 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. To a court clerk it sounds like nothing, opaque and technical, the kind of thing you'd skip past in a training. Not a bug, exactly. Not in the PRD either. But noticeable.
By Block 3, I was flagging contrast questions, helper text microcopy, a disabled state that needed verifying. None of these were in the original scope. None of them were stop-the-build issues. All of them were real.
By Block 4, I was holding a list of polish items in my head while running an active build. Around 11pm 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.
So I started a 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 they need to live in different documents.
Mine grew to 14 polish items, 8 things to defer to v2, 4 cleanups for before deployment, and 4 lessons-learned entries by the end of the week. Some of it was scope creep waiting to happen, the kind of "we should add this, it's only an hour" thinking that turns four-week builds into eight-week builds. Some of it was real bugs the PRD couldn't have predicted because I hadn't shipped enough of the thing yet to find them. Some of it was language I knew was wrong the moment I read it back to myself in the voice of an actual court employee.
The thing I'd do differently next time is start the punchlist on day one, alongside the PRD. Not as a section of the PRD because they have different jobs, but as a sibling document, ready and waiting. Treating the empty punchlist as a feature instead of a placeholder.
What the punchlist taught me is that the PRD locks scope and the punchlist holds everything the PRD couldn't see yet. Both are needed. The discipline isn't writing a perfect PRD, it's knowing which document a thought belongs in and putting it there immediately instead of trusting yourself to remember.
Week three is polish and deployment. The punchlist is the running list. Loading state experience for the latency. Brand banner in the PDF. Mobile responsiveness. Then 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.
This article was originally published by DEV Community and written by L. Cordero.
Read original article on DEV Community