FlowDoc started with a simple observation: product people spend hours creating documentation that developers rarely read, while the actual workflows they're documenting live in browsers where nobody captures them.
You probably know this pain. You've written step-by-step guides with screenshots, only to watch them go stale the moment someone ships a UI change. Or you've inherited a product with zero workflow documentation and had to reverse-engineer how users actually move through the system.
The insight was that the browser already knows the workflow. Every click, form input, and navigation is an event the browser can capture. The question was whether you could turn that stream of events into useful documentation automatically.
Look for automation where manual work scales poorly
Before building anything, spend time identifying where your current process breaks down. Good automation targets share three qualities:
The work is repetitive but not identical. Documenting user flows follows the same pattern every time (capture screen, describe action, show result), but each flow has different steps and different context. Pure repetition gets automated away already. Pure creativity can't be automated well. The sweet spot is structured work with variation.
The work doesn't scale with team size. One person can document five workflows. Five people working independently will create fifteen overlapping, inconsistent workflow docs. Manual coordination overhead grows faster than the team.
You're already doing the work anyway. FlowDoc automates something product people do constantly: clicking through flows to understand them, taking screenshots for bug reports, explaining how features work to colleagues. The automation saves time by capturing that work you're already doing.
Start with your own workflow
The strongest product decisions come from solving problems you experience personally. Before FlowDoc, manual screenshots for workflow documentation, losing track of which screens went with which steps, and watching docs become outdated within weeks.
This personal frustration drove every design choice. The "wait for Enter before recording" feature exists because accidentally capturing login screens kept happening. The auto-generated flowcharts exist because drawing them by hand in every presentation was tedious. The Swedish transcription exists because half the demos were in Swedish.
Building for yourself first means you'll catch usability problems early and prioritize features that actually matter. You can't fool yourself about whether the tool works. You'll know immediately if you'd rather go back to doing it manually.
Validate the core assumption before building
Every automation project has one load-bearing assumption. For FlowDoc, it was: "Browser events contain enough information to generate useful workflow documentation." Until you prove that assumption, every other feature is speculation.
The fastest way to validate was building the minimal version: capture clicks and screenshots, generate a basic markdown file. If that core loop produced something useful, the rest was just polish. If it didn't, no amount of additional features would save the project.
This is why post-processing (merging clicks with navigation, generating human readable titles) came in session 3, not session 1. The raw event log proved the capture mechanism worked. Only then did it make sense to invest in making the output readable.