The fastest way to kill a software project is to build everything except the thing that matters. FlowDoc could have started with authentication, database design, or a fancy React frontend. Instead, it started with the core question: can you actually capture a browser workflow and turn it into documentation?
Session 1 took 15 minutes to plan. Session 2 took 40 minutes to build. By the end of those 55 minutes, the tool opened a browser, recorded clicks and navigation, took screenshots, and generated a Markdown file. It was ugly, but it worked.
Focus on the happy path first. The initial implementation had one command: flowdoc capture --url https://example.com --name my-flow. No branches, no audio, no fancy post-processing. Just: open browser, click around, get a document. Every other feature came later.
The architecture reflected this focus. Nine small files, each doing one thing:
capture.tsorchestrated the browser sessionrecorder.tsinjected JavaScript to detect clicksscreenshot.tssaved images at each stepmarkdown.tswrote the final document
This wasn't accident. During planning, Claude asked about scope creep risks. The response was deliberate: "No AI, no web UI, no database — just a CLI tool." Constraints force clarity.
Test on real sites immediately. The first test ran against mantus.ai, a live website with navigation and interactive elements. Not a toy example, not localhost, not a mock. Real sites surface real problems that synthetic tests miss.
The first test revealed the core bug: clicks weren't being recorded. The injected script only ran on future page loads, not the current page. This would have been invisible in a controlled test environment. Against a real site, it was obvious within seconds.
Build for the 80% case, note the 20%. The initial version captured linear workflows perfectly. Branching workflows, audio narration, and Miro integration all came later as separate sessions. Each was valuable, but none were essential to prove the concept worked.
The key insight: working beats perfect. A rough tool that captures workflows is infinitely more useful than a polished tool that doesn't exist. You can iterate on working. You can't iterate on planning.
This approach compressed months of typical development into hours. No requirements docs, no technical specifications, no stakeholder reviews. Just: build the smallest thing that could possibly work, test it, and move forward.