I Built a Framework for Getting Ideas Out of My Head and Into Code
SAPA is how I stop over-planning and start shipping

I have a problem. I get ideas faster than I can build them.
Some of these ideas are genuinely good. Most are not. But here's what I noticed: I was spending the same amount of time "planning" the bad ideas as the good ones. I'd write a PRD for something that didn't need a PRD. I'd skip planning entirely for something that desperately needed structure. The result was a graveyard of half-started projects and a few over-documented ideas that never saw a single line of code.
So I built a framework. I call it SAPA.
What SAPA Actually Is
SAPA stands for Spectrum, Assessment, Prescription, Architecture. It's a methodology I use with Claude to take an idea from "I should build this" to "here are the exact steps to build this in phases."
The key insight: not every idea needs the same amount of planning. A weekend hack doesn't need a PRD. A product you're pitching to leadership doesn't need a napkin sketch. The problem is knowing which one you're dealing with.
SAPA forces me to figure that out before I start documenting.
The Four Steps
Spectrum is about seeing all your options. Before you write anything, understand the full range of planning documents that exist:
Napkin sketch (for solo weekend builds)
One-pager (for gut-checking with trusted people)
Lean Canvas (for validating the business model)
Product Brief (for aligning a small team)
PRD (for cross-functional coordination)
Technical Spec (for detailed implementation)
Most people jump straight to "I need a PRD" because that's what they've seen in companies. But if you're building alone, a PRD is overhead. If you're pitching leadership, a napkin sketch won't cut it.
Assessment is the interrogation. Before recommending a document, I ask myself:
Is this idea validated? Have real users expressed interest?
Who is building this? Just me? A team?
What's the biggest risk? Technical feasibility? Market demand?
Is this exploration, validation, or committed execution?
The answers determine the prescription.
Prescription is the output. Based on the assessment, I produce only what's needed. Nothing more. If I'm solo and unvalidated, I get a one-pager and go straight to building. If I need buy-in from others, I get a proper Product Brief. The framework prevents over-engineering the planning phase.
Architecture is where it gets interesting. Once I have the right planning doc, SAPA produces Phase Briefs. These are self-contained instructions for each development phase, formatted specifically for Claude Code.
Each Phase Brief contains:
What exists from prior phases
What this phase accomplishes
Specific deliverables
Technical constraints
Acceptance criteria
I can hand a Phase Brief to Claude Code and say "build this." No re-explaining context. No starting from scratch. Just execution.
Why Phases Matter
Here's what I learned the hard way: if you try to build everything at once, you build nothing.
Phases force incremental progress. Each phase delivers something working. Something testable. Something you can show someone and get feedback on before you've invested 40 hours.
The phases are sized for a single Claude Code session. Roughly 1-4 hours of work each. Small enough to finish. Large enough to matter.
A Real Example
I had an idea for a product called "Infinite Intern." The concept: AI agents that work like employees, not chatbots. You hire them, give them job descriptions, assign tasks, review their work, provide feedback. They learn over time.
Without SAPA, I would have either:
Started coding immediately with no plan (and gotten lost in scope creep)
Written a 20-page PRD that took longer than actually building the thing
With SAPA, I did an assessment. Solo builder. Unvalidated idea. Technical feasibility is low risk (I know the stack). Market demand is the real question.
Prescription: Product Brief + Phase Plan. Skip the PRD. Skip the Lean Canvas. Get just enough structure to start building, then validate with real users.
The output was 8 phases:
Foundation (infrastructure, basic agent structure)
Intern Execution (actually performing tasks)
Review and Feedback (human-in-the-loop)
Frontend: Bullpen Dashboard
Frontend: Hiring Flow
Frontend: Review Queue
Additional Intern Types
Polish and Scheduling
Each phase has a brief. Each brief is ready for Claude Code. I can work through them sequentially, shipping something functional after each one.
The Meta Point
SAPA is a framework for working with AI. But it's really a framework for working with yourself.
The AI doesn't care if you write a PRD or a napkin sketch. The AI will happily help you over-plan or under-plan. The value of SAPA is that it forces you to stop and think about what you actually need before you start producing artifacts.
I've been using it for a few months now. The graveyard of half-started projects is smaller. The ratio of ideas-to-shipped-code is higher. That's the only metric that matters.
Get the Framework
I've packaged SAPA into a document you can drop into any Claude conversation. It includes:
The full methodology
Templates for every artifact type
Instructions for producing Phase Plans and Phase Briefs
An example showing the complete output
You can use the quick invoke version (just paste it with your idea) or the full framework (for understanding the methodology).
The framework is designed for Claude, by someone who uses Claude. It's opinionated. It's practical. It works.
If you're drowning in ideas and starving for shipped projects, give it a shot. The worst case is you spend 10 minutes thinking about your idea before you start. The best case is you actually finish something.
That's the whole pitch. Go build something.
Have questions about SAPA or want to share how you're using it? Find me on LinkedIn or GitHub.

