There's a question I get asked a lot as someone who builds solo: "how do you actually ship things?" Not "how do you write code faster" or "how do you use AI to autocomplete functions." The deeper question: how do you take an idea from a rough thought to a working, deployed product without a team of engineers, PMs, and QA to carry the load?
The honest answer is that I built a workflow where the only part that requires my sustained, high-effort input is the beginning — turning an idea into a detailed plan. Once that plan exists, my AI workflow takes it from there. Autonomously. Phase by phase, sprint by sprint, until there's something running.
This is how that workflow works.
The Problem With Building Solo
Solo builders don't have a code problem. AI handles code. The problem is coordination overhead — everything that isn't the actual implementation.
You still have to figure out what you're building. You have to break it into pieces small enough to be actionable. You have to track what's done and what's next. You have to context-switch constantly between thinking strategically and executing tactically. And every time you start a new session with an AI assistant, you re-explain the project from scratch.
That last part compounds fast. AI assistants are stateless. Every conversation starts from zero. You become the project manager, the sprint planner, and the relay between every task — on top of being the person doing the building.
I wanted to eliminate that overhead. I wanted to show up with an idea and have a system that could take it the rest of the way.
The Workflow: Three Steps From Idea to Product
The workflow has three stages. The first requires real thinking. The second is structured but AI-assisted. The third is almost entirely automated.
Step 1: Idea → PRD
Everything starts with an idea, which is usually a mess. A rough problem statement, a hunch about what should exist, maybe a few notes on how it might work.
The first step is turning that mess into a Product Requirements Document — a clear, detailed description of what the product is, what it does, who it's for, and what the technical approach looks like. This isn't a spec you write alone. I work through it with Claude or Cursor, using AI to pressure-test the idea, identify gaps, and push the thinking further than I'd get on my own. What stack makes sense? What are the core data models? What are the edge cases in the UX?
The output is a document that a development agent could read and understand the product completely. It's not a novel — it's a dense, precise artifact that answers all the questions a competent engineer would ask before writing a line of code.
This is the part that requires my real input. It's also the part where all strategic decisions get made. Every choice I make here ripples through everything that follows.
Step 2: PRD → Development Plan
Once the PRD exists, I hand it to the Sprint-Planner — an AI skill that reads the requirements and produces a structured development plan.
The plan is divided into phases (major product milestones, like "Foundation and Schema" or "Orchestrator Agent") and sprints (focused chunks of work within each phase). Each sprint has a goal, a task table, acceptance criteria, and a list of dependencies. Every task has a status: not started, in progress, done, blocked, cut, or deferred.
The output is a set of Markdown files living in docs/Phases/ — readable by humans, parseable by machines. This format matters. It's not documentation for its own sake. It's the context injection layer that makes the next step possible.
The Sprint-Planner does the translation work I used to do manually: taking a product vision and breaking it into concrete, sequenced engineering work. It's not perfect and I review the output, but it gets 90% of the way there on its own.
Step 3: Development Plan → Shipped Product
This is where the automation kicks in.
The Phase-Runner is an orchestrator skill that reads the development plan and runs it. You tell it "run phase 1" and it handles the rest:
1. Reads the phase plan, identifies which sprints are incomplete 2. Takes stock of which tools are connected in the current session (Supabase MCP, Vercel MCP, GitHub, etc.) 3. Spawns a focused implementation sub-agent for the first sprint, injecting the full context it needs — project root, coding conventions, the phase plan, the sprint scope, and a structured output format 4. Waits for the sub-agent to finish and return a machine-readable result block 5. Parses the result, updates the phase file, and advances to the next sprint
The loop continues until the phase is complete. Then it stops, shows a summary, previews the next phase, and waits for a go/no-go before continuing. That's where I show up — to test, review, and decide if the foundation is solid enough to build on.
Between those checkpoints, I'm not involved. The system is running.
What the Automation Actually Handles
The sub-agent spawning mechanism is worth understanding, because it's what makes the statelessness problem disappear.
Each implementation agent is spawned fresh for a specific sprint. It has no memory of previous sessions — but it doesn't need any, because the orchestrator injects everything it needs at spawn time: the absolute path to the project root, all project convention files, the full phase plan, the specific sprint with its task table and acceptance criteria, a list of available tools and how to use them, and a required output format for reporting results back.
That last part is what closes the loop. Every agent ends its run with a structured block:
SPRINT RESULT: COMPLETED: 1, 2, 3, 4 BLOCKED: 5 BLOCKED_REASONS: Task 5: Supabase CLI not found in environment NOTES: Created RLS policies for all user-scoped tables
The orchestrator reads this, updates the phase file, and decides what to do next. No human relay required.
The Two Checkpoints That Keep It Safe
Full automation sounds appealing until something goes wrong silently. The system has two designed interruption points.
Blocker checkpoints. If an implementation agent can't complete a task — missing credentials, an ambiguous requirement, a dependency that hasn't been built yet — it marks the task BLOCKED and explains why. The orchestrator surfaces this immediately with three options: resolve and rerun, skip and continue, or stop entirely. It never invents a workaround or silently proceeds.
Phase boundary checkpoints. After every phase completes, the orchestrator pauses for a human review. It shows which sprints ran, how many tasks completed, what's blocked, and previews the next phase. You test, review, and give a go/no-go. The system never crosses a phase boundary on its own.
These two checkpoints are the only places I need to consistently show up. Everything in between is automated.
What This Actually Changes
The shift isn't about writing code faster. It's about what I spend my time on.
Before this workflow, I was managing sequence myself. I knew which sprint was next. I re-explained the project at the start of every session. I manually tracked what was done. I was the relay between every step.
Now, the project plan is the relay. My job is to craft a strong PRD — to think clearly about what I'm building and why — and then to show up at phase boundaries to make real decisions: does this phase look right before I build on it? Is this blocker something I can resolve quickly, or does it signal a deeper problem?
That's a better use of time. Strategic decisions at the start. Quality gates between phases. Everything else, automated.
The Broader Pattern
The specific tools I'm using — Claude, Cursor, these skills — aren't the point. The pattern is:
Invest heavily in the plan. Automate the execution. Design your checkpoints around decisions that actually require human judgment.
Most AI workflows fail not because the AI isn't capable, but because the context it operates on is incomplete or inconsistent. If your project plan is machine-readable — structured tasks, clear states, explicit conventions — you can build automation on top of it that compounds. Each layer gets smarter because the layer below it is solid.
The phase plans I use are just Markdown files with tables. The skill instructions are just text files. None of this requires special infrastructure. The leverage comes from the structure, not the technology.
The idea is still the hardest part. But once you have a clear one, the path from there to shipped is short.