I did not set out to build Issue Flow as a product.
I built it because I was frustrated...
In September 2025, I was developing a large product while working a demanding full-time job. This is a product I was planning to build for a long tine, but never had the bandwidth. AI had opened up a new kind of possibility: I could make meaningful progress in the limited time I had outside work. With an IDE, a chat interface, and early coding agents, I started building piece by piece.
But as development accelerated, a different problem appeared.
The agents could help write code. They could help investigate. They could help with individual tasks.
What they could not do was run my entire development process in a way I trusted. With over 35 years in IT, I have my quality requirements I did not want to compromise on.
I tried the tools that were emerging at the time: Copilot agents, Cursor, the Kiro, and others. Each solved part of the problem. But none gave me what I actually needed: a way to orchestrate work from ideation through deployment, while involving me only when my judgment was truly needed. Later, when the product was testable, the problem increased - bug reports came with very vague language, so I had to replicate them one by one to recreate the issue myself.
I did not want to spend my limited time babysitting prompts.
I wanted to decide where the human checkpoints belonged. I wanted agents to keep moving through clear work and call my attention when there was a decision, a blocker, a quality concern, or a meaningful tradeoff.
That was the beginning of Issue Flow.
The real problem was not code generation
When people talk about AI-assisted development, the conversation often centers on how quickly an agent can generate code.
That matters. But once you are working on a real product, code generation is only one small part of the process.
Someone still has to understand an issue. Someone has to determine which repository owns it. Someone has to investigate the root cause, consider dependencies, sequence work, validate the result, and decide whether it is ready for production.
New features came with their own challenges: intent alignment, business value, multi-repo coordination, understanding the persona, and other challenges the AI could not do on its own - not at the quality I needed.
For a builder with limited time, this coordination becomes the bottleneck.
At first, I created something simple for my own workflow: a way to orchestrate agents around the steps I was already taking. I designed it to stay flexible because I knew my process would evolve as the product evolved.
And it did.
The early versions had plenty of problems. Agents could crash. Detecting a completed task was not always reliable. Capacity management was inconsistent. Each failure exposed another part of the workflow that needed to become more resilient.
By May 2026, I realized I needed to take it seriously as a product in its own right.
I gave it a name: Issue Flow.
From vague report to production
The need became even clearer when my original product, Aligned on Purpose, reached the stage where testers could use it.
Testers reported issues from their own perspective, as they should. But a report such as “this screen is not working correctly” does not tell a developer whether the problem lives. Is it in the frontend, the backend, an API contract, or a different repository altogether?
I found myself doing so much manual research that it sometimes felt faster to test the whole product myself.
So I expanded Issue Flow.
It could take a vague issue, gather available evidence such as screenshots, network activity, and logs, determine the likely root cause and responsible repository, and create the appropriate sub-issues. It could account for dependencies and concurrency before moving work into the system.
Over time, it became a workflow that could take a bug report or enhancement from the initial description toward production, while bringing me in only where I could contribute real value.
That distinction matters.
The goal is not to remove humans from development. The goal is to make human involvement intentional.
Control without constant supervision
As Issue Flow became more capable, I ran into another challenge: cost.
More automation meant more work could move at once. More work meant more token usage. Eventually, a quota limit could stop a workflow in the middle of its progress.
So I added another layer of orchestration: choosing models based on issue complexity, recognizing quota limits, and switching to another available agentic framework when appropriate.
Issue Flow is not meant to lock people into one AI provider or one way of working.
Whether someone prefers Gemini, Copilot, Claude, Cursor, OpenCode, or another framework, they should be able to design a workflow that matches how they work. They should be able to define their own quality gates, approval points, escalation paths, and budget controls—without maintaining a maze of configuration files.
Building the product with the product
Today, I use Issue Flow to build Aligned on Purpose.
I also use Issue Flow to build Issue Flow itself.
That is the most meaningful validation I could ask for. What started as a personal solution for building alongside a full-time job has become a product for other developers and teams facing the same reality.
AI can make us dramatically faster.
But speed alone is not the answer.
The real opportunity is to build workflows where quality stays protected, budgets stay visible, and people are involved exactly where their experience and judgment matter most.
That is why I built Issue Flow.
