The FlowDoc story shows something important: you don't need to be a programmer to build real software. You need to understand problems, make decisions, and work with the right tools. AI coding partners are one of those tools.
Here's how to find your own FlowDoc and build it.
Start with a problem you actually have
Don't build "a productivity app" or "something with AI." Build something you wish existed for work you already do.
FlowDoc started because documenting product flows was tedious. Screenshots, descriptions, keeping everything in sync when the product changed. The pain was specific and recurring.
Your version might be different. Maybe you spend too much time formatting reports. Maybe you manually update the same spreadsheet every week. Maybe you copy data between systems that should talk to each other.
The best projects solve problems you understand deeply. You know what good looks like because you do the work.
Pick the simplest version that would actually help
FlowDoc could have been a web service with user accounts and team collaboration. Instead it started as a CLI tool that saved screenshots and wrote markdown files. That was enough to solve the core problem.
Simple doesn't mean limited. It means focused. The features you don't build can't break, can't confuse users, and don't slow you down.
Ask: if this tool only did one thing perfectly, what would that thing be? Build that first. Everything else is an experiment you can try later.
Use the AI as a senior developer who never gets tired
AI coding partners excel at translating your decisions into working code. They struggle with deciding what to build in the first place.
Come to the conversation with opinions. "Build a system that captures browser workflows" gets you further than "build something useful with Playwright." The AI fills in implementation details, not product vision.
When you're stuck on architecture, describe the user experience you want instead of the technical approach. "The user opens their browser, navigates to the right place, presses Enter to start recording" is clearer direction than "use Playwright's page object model with event listeners."
Don't accept the first implementation. Push back when something feels wrong, even if you can't articulate why. The AI has infinite patience for iteration.
Test on real work, not toy examples
FlowDoc was tested on mantus.ai and demo.unikum.net from day one. Real sites with real complexity. Real login flows, real navigation patterns, real edge cases.
Testing on your actual work surfaces problems you'd never anticipate. It also keeps you honest about whether the tool actually saves time or just moves the work around.
Build a version that handles your specific use case perfectly before you worry about general cases. Specific solutions often generalize better than you expect.
The progression is always: working, correct, fast, pretty
Working means it runs without crashing and produces some output. Correct means the output is actually useful. Fast means it doesn't waste time. Pretty means it's pleasant to use.
FlowDoc went through this exact progression. v0.1 captured clicks and wrote files. v0.2 merged duplicate events and generated readable step names. v0.3 eliminated unnecessary waiting. v0.7 added the HTML site with inline audio playback.
Each stage built on the previous one. You can't make something fast until it's correct. You can't make it correct until it works.
Most people skip to pretty because it's the most satisfying to build. Resist that. Pretty software that doesn't work is worthless.
Recognize when you need to hand it to other people
FlowDoc stayed a personal tool until v0.8. Then teammates wanted to use it, which exposed all the setup friction I'd learned to ignore. Suddenly the tool needed onboarding docs, environment checks, and clear error messages.
Other people will use your tool differently than you do. They'll try things in orders you never considered. They'll be on different machines with different software installed.
The moment someone else asks to use your tool, you have a different product with different requirements. flowdoc doctor and ONBOARDING.md weren't features. They were the minimum viable handoff.
Desktop apps matter more than you think
Web apps feel modern, but sometimes native software is the right answer. FlowDoc needed to drive a browser, record audio, and write local files. A web app would have been hobbled by browser security restrictions.
Electron gets a bad reputation, but for tools like this it's perfect. You get native file system access, no server costs, and the entire web platform for your UI. The learning curve is one afternoon if you already know HTML and JavaScript.
Signing and distribution are harder than the development. Budget time for certificate wrangling, especially on macOS. The first notarization can take hours. Auto updates require both DMG and ZIP targets. These aren't programming problems, they're process problems.
What you should build next
Look for patterns in the FlowDoc story that match your own work:
Repetitive documentation tasks. FlowDoc automated workflow documentation. You might automate API documentation, test case writing, or meeting summaries.
Data that moves between systems manually. Export from one tool, format it, import to another. These pipelines are perfect for automation and terrible for humans.
Tasks that require both human judgment and mechanical execution. FlowDoc needed human judgment about which workflows to capture, but mechanical execution for the screenshots and file generation.
Work that happens on your local machine. Desktop tools can do things web apps can't. File processing, system integration, development environment automation.
The best automation projects start with work you already do well manually. You understand the edge cases, you know what good output looks like, and you can test the automation against real examples.
Start with your most annoying recurring task. If it involves a computer, it can probably be automated. If it can be automated, an AI can help you build that automation.
The question isn't whether you can build it. The question is whether it's worth building. Most of the time, it is.