When Methodology Meets Reality: Building While Learning
September 7
Some days your systematic process saves you. Other days it teaches you something about itself while saving you. Sunday was the second kind.
The goal was straightforward: connect our Morning Standup feature to the web interface and test it. We’d restored the CLI functionality yesterday, so this should be simple verification work. Look, command-line output from Piper Morgan with real integrations and live data:
Instead, it became a masterclass in how methodology can enable real achievement while simultaneously improving itself in real-time.
The morning assumption
“Test the web UI” seemed clear enough. I’d been thinking we needed to verify whether our web interface could handle the Morning Standup workflow. My Chief Architect created a gameplan based on that assumption — phases for UI testing, browser verification, polish work.
A while back we added a Phase 0 to our gameplan template — a step where we have Claude Code create or open the GitHub issue and make sure it has the right description. (We then bookend at the end of the process so our tracking keeps up.) Now we were adding an even earlier pre-step, which I’m calling Phase −1 to the methodology after too many painful discoveries: infrastructure investigation. Don’t assume. Check what actually exists.
What actually existed (which I knew but the bots had to re-discover) was a complete 18KB FastAPI application. The CLI worked fine. What was missing wasn’t a working web UI for Standup to test — it was a single API endpoint to connect the working CLI orchestrator to the existing web framework.
When process becomes self-improving
Here’s where it gets interesting. Instead of just fixing the gameplan and moving on, we treated this assumption failure as methodology data. Within hours, we’d updated our entire framework:
- Infrastructure verification checkpoints became mandatory in gameplan templates
- Lead Developer onboarding got emergency reality-check procedures
- Agent prompts got infrastructure verification as step one
- The Chief Architect role now requires PM confirmation before any planning
The morning’s mistake became a systematic prevention system by afternoon. Not just “let’s be more careful next time,” but “let’s make it impossible to repeat this category of error.”
The web interface emerges
Meanwhile, the actual work proceeded beautifully. Claude Code added the missing /api/standup endpoint. Cursor Agent built a clean dark-mode UI with mobile responsiveness. The orchestrator we'd debugged yesterday connected seamlessly to the web layer.
Performance came in at 4.6–5.1 seconds — well under our 10-second target. The interface pulled real data from GitHub. No mock-ups or placeholders. A genuine daily tool, accessible via browser, ready for 6 AM usage. (It can see real calendar events and real document indexes too, but we haven’t integrated that data yet.)
The methodology enabled this achievement not through rigid process adherence, but through systematic error recovery. When assumptions broke, we had patterns for course correction. When agents needed coordination, we had established handoff protocols. When testing revealed gaps, we had GitHub tracking to ensure nothing got lost.
Refining the roadmap
But Sunday’s deeper work happened in the project organization layer. We’d been operating with a linear now/next/later roadmap that kept everything in artificial dependency chains. Features couldn’t start until others finished. Priorities got muddled in long lists of PM-XXX numbered items.
I finally bit the bullet and proposed parallel tracks, since each has its own roadmap, only some are dependent on each other, and they all need to hit some sort of target before we get to the Core MVP (0.1, an alpha release that can benefit from outside testers), let alone the release MVP (1.0, the first public release).
Each track has its own MVP thresholds:
- CORE — Core capabilities → Good enough when fundamental workflows work
- FEAT — Features → Good enough when users can accomplish their goals
- OPS — Operations → Good enough when daily tools are reliable
- INFR — Infrastructure → Good enough for current user load
- UX — User Experience → Good enough when non-technical users succeed
Each track can progress independently while maintaining alignment. More importantly, each has a clear “good enough” line that prevents endless polishing.
The great renaming
This led to completely restructuring our 50+ GitHub issues from cryptic PM-XXX numbers to meaningful TRACK-EPIC-Story names. Instead of “PM-151,” we now have “OPS-STAND: Fix blank fields bug.” Instead of guessing what “PM-119” means, we see “OPS-STAND-MVP: morning standup feature.”
This is also helpful when sorting or filtering in GitHub, an it will prevent the routine confusion our agents experienced when they realized that PM-199 might be GitHub issues #276 in our repository, and so on. We’re trying to avoid using numbers aside from the issue series, to prevent that.
The renaming was more than just organizational housekeeping. It revealed our actual architecture and made development priorities obvious. Monday morning’s focus became crystal clear: four OPS-STAND issues that will complete the standup workflow. Next week: the UX-FTUX epic that will make the whole experience excellent.
The synthesis
Here’s what struck me about Sunday’s work: the methodology improvements and the roadmap clarification weren’t separate activities. They were two sides of the same systematic thinking coin.
Good methodology enables you to build the right things efficiently. Clear roadmap organization helps you recognize what the right things actually are. Together, they create a feedback loop where tactical execution informs strategic decisions, and strategic clarity improves tactical execution.
The infrastructure verification system we built will prevent wasted development cycles. The track-based roadmap will prevent feature sprawl and priority confusion. Both emerged from the same systematic approach to learning from reality rather than defending assumptions.
The human element
None of this was smooth sailing. I got frustrated when assumptions proved wrong. The Chief Architect initially created truncated file updates instead of proper incremental changes (this new Anthropic bug was going to become a real problem over the coming week). Agents needed multiple course corrections. The day included the usual comedy of errors that accompanies complex coordination work.
But the key insight is that systematic methodology doesn’t prevent all mistakes — it provides better recovery patterns. When things go wrong, you have frameworks for diagnosis, correction, and prevention. When priorities get confused, you have organizing principles for clarification.
What we shipped
By evening, we had:
- A production-ready web interface for Morning Standup
- A comprehensive infrastructure verification system
- A completely reorganized project roadmap with clear MVP milestones
- Six new GitHub issues documenting improvement opportunities
- Updated methodology templates that embed the day’s learning
Not bad for a Sunday. More importantly, each piece reinforces the others. Better methodology enables better execution. Clearer roadmaps reveal methodology gaps. Real user tools validate strategic decisions.