How Dora Flow Actually Came Together

This is the story of how Dora Flow went from a rough idea to a fully integrated AI-assisted product: tested beyond software, validated by real users, and still evolving. No fluff — just the decisions and the order they happened in.

The idea trap (and how to get out)

I had lots of ideas, but getting from a vague thought to something concrete always felt heavier than it should. Before writing any code, I’d get stuck in research, feasibility, and “is this even worth it?” Most ideas never got past that stage.

So the shift was simple: stop starting with features, start with structure. I defined the areas I always want to understand before committing to an idea. That structure eventually became the backbone of Dora Flow itself.

Structure first, prototype second

The areas that mattered became the product’s sections: problem definition (problem, personas, jobs to be done), competitive analysis, product definition (features and MVP), feasibility and risks, and go-to-market and feedback. From there came a rough prototype — multiple AI models to explore ideas from different angles. The goal wasn’t “the answer”; it was to compare perspectives and sharpen my own thinking.

I also started testing it beyond software: scientific ideas, research directions. That showed the framework wasn’t tied to software at all; it was really about structured thinking in any domain.

When the prototype started shipping (yes, really)

The prototype grew faster than I expected. It could generate structured strategies, detailed roadmaps, and even open GitHub pull requests from an idea definition. At some point it was creating full GitHub Projects with tasks and milestones, wired through webhooks — for example, a comment on a PR could trigger updates automatically. You can still see one of those early roadmaps here: early roadmap (GitHub Project).

Automating everything early — then forgetting about it

Once the prototype proved the idea, the focus became building the real product with one rule: minimize future friction. That meant automating infrastructure early with Pulumi on GCP, a monorepo (console, core-api, infrastructure) so AI tools could see the whole system in one place, and a full CI/CD pipeline before any user-facing features. The goal was simple: once building started, the only thing left to think about was product decisions.

All of that — automation, monorepo, pipeline? Maybe 1% of the total time spent building and thinking. The rest went into product, feedback, and iteration.

Coding with AI — but with rules

When it came time to code, AI was a big part of it — with clear boundaries. I defined explicit rules for how AI agents should work: domain-driven design, test-driven development, observability, and clear architectural constraints (hexagonal architecture, Result types, no try-catch in domain). Along the way, some of those patterns were extracted into an open-source library — jsfsi-core-typescript — so the same DDD, hexagonal, and Result-type foundations can be reused elsewhere.

With that in place, development felt unusually smooth; most of the energy went into building features and occasionally refining ideas that didn’t work as expected.

Validating the idea (before overbuilding)

After the core was in place, validation had to happen early. I reached out to around 30 people from very different backgrounds — product, engineering, startups, academia — and asked for honest feedback. About 20 responded. Their input didn’t just tweak features; it reshaped the product definition.

Feedback that changed the product

All feedback went into a simple Kanban board, and from there development became very focused: pick a real problem, implement a solution, ship it. Often quickly.

Momentum beats perfection

What happened confirmed it: Dora Flow didn’t get clearer or more useful because everything was designed upfront, but because something real was shared early and improved through genuine feedback. Staying close to users kept the momentum and grounded every decision in real needs, not assumptions. A good reminder: momentum beats perfection when customers are part of the process.

Inspired by

The thinking behind this draws on work that keeps coming back: Modern Software Engineering by Dave Farley, and Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim — both had a real influence on flow, feedback, and delivery.