How to Build a Production App With AI

This weekend I had a CTO staying with me who built an app you've probably used. I was curious, so I asked his opinion on my “vibe coded” application.

He spent time reading through the codebase. His take: I'm more productive than a large portion of his engineers who have spent careers writing code. The code itself was sound and production-grade. He estimated it would have taken a 10 person team over a year to build it. He told me he might rethink his org structure based on what he saw.

I don't write code. I write in English. But after 15 years in SaaS, I probably know more about how software gets built through osmosis than I give myself credit for. That context matters.

Still. This is a real signal about where we are in 2026 and what one person can produce with the right system.

I put this framework together because I get asked the same question every week: “How do I actually start?” Here's the answer.

Phase 1: Start With a Problem You've Lived

Don't start with a solution. Start with frustration.

I spent months trying to buy a business. The search process was broken. No tools existed to manage it. I was copying and pasting listings into spreadsheets, losing track of conversations with brokers, and letting deals slip through the cracks.

That frustration became Searcher OS, a SaaS now used by searchers, micro-PE firms, and family offices to manage their acquisition pipeline.

You don't need a business idea. You need a problem you understand better than anyone. The depth of your domain knowledge is what separates a useful product from a toy demo.

Phase 2: Brainstorm in Plain English

Download the Claude desktop app. Open the Claude Code tab. Start talking to Opus 4.6.

Describe your problem out loud. What's broken. What you'd want. How it should feel to use. Use voice-to-text if you can. It's 3x faster than typing and it captures the way you naturally think about the problem, which matters.

Don't think about technical details yet. Don't worry about databases or frameworks or deployment. Just talk about the problem like you're explaining it to a smart colleague who has never seen your industry before.

After 15-20 exchanges, ask for a first draft product spec. You'll be surprised how coherent it is. The AI will organize your stream-of-consciousness into something structured: user stories, feature requirements, data models. It's not perfect, but it's a remarkably strong starting point.

Phase 3: Have AI Tear It Apart

This is the step most people skip. Don't.

Start a completely fresh conversation. This is important. Context windows fill up fast, and after about 15-20 exchanges the quality of responses starts to degrade. A fresh context means fresh thinking.

Hand your draft spec to a new agent. Give it one job: destroy your spec. Find logical gaps. Challenge your assumptions. Think about it from the user's perspective. Ask what happens when the user does X but Y hasn't loaded yet. Ask what the error state looks like. Ask what happens at scale.

You want this to hurt a little. That's how you know it's working.

Phase 4: Do It Again With a Fresh Agent

Take everything from Round 1. Revise your spec. Then start another fresh conversation and hand it to a third agent.

Different context means different blind spots get caught. The first reviewer might focus on user experience gaps. The second might catch data model issues. The third might question your assumptions about how the user actually behaves.

By the third pass, your spec covers edge cases you never would have thought of.

This is the same principle behind code reviews at any serious engineering team. Multiple eyes catch what one set misses. You're just doing it with AI instead of waiting for three engineers to have calendar availability.

Phase 5: Choose Your Building Blocks

You need six things:

1. Next.js — Frontend framework
2. Supabase — Database with auth built in
3. Vercel — Hosting that deploys on git push
4. Stripe — Payment processing
5. Claude Code — AI coding agent
6. GitHub — Version control

Why these specifically? Because AI writes better code when it knows the tool deeply. All six of these are mature, well-documented, and heavily represented in training data. That means fewer hallucinations, better patterns, and less time debugging AI-generated code that doesn't actually work.

Don't get paralyzed by stack decisions. These six will take you from zero to production.

Phase 6: Break the Spec Into Features

Your product spec is the big picture. Now decompose it.

Each feature gets its own document: what it does, what inputs it takes, what the user sees, what edge cases exist, what it depends on.

A login system is one feature. A dashboard is another. A notification system is another. Each one gets its own spec.

Tell Claude to organize the codebase by feature, with no module over 1,000 lines. This keeps your architecture modular and problems easy to diagnose. When something breaks, you know exactly which feature folder to look in. When you want to add a capability, you know exactly where it goes.

Then run the same adversarial review from Phase 3-4 on each feature spec. Fresh agent, fresh context, find the holes.

The pattern is always the same: write, review, revise. At every level. This is the core insight of the entire framework.

Phase 7: Features Become Tasks

Each feature spec breaks into atomic tasks. These are the actual instructions AI will execute.

A good task is small enough that someone with zero context could execute it without asking a clarifying question. Not “build the auth system.” Instead: “Add a logout button to the nav bar that clears the session and redirects to the login page.” That's a task.

For scale: I built a second SaaS this week. Across all the feature specs, the task list is over 10,000 line items long.

That's the level of granularity that produces production-quality software. It sounds tedious, but the decomposition work is what makes everything downstream fast and reliable. Skip this step and you'll spend more time debugging than building.

Phase 8: Run 3-5 Agents in Parallel

This is where it gets fast.

Use Opus to break your task list into chunks that a single Sonnet agent can complete independently. Then spin up 3-5 Sonnet agents and feed each one a chunk. They build in parallel.

When an agent finishes its chunk, hand it the next one. You're continuously feeding fresh agents new task lists until you've iterated through every line item.

Then use Claude Code to open a browser and run its own user acceptance testing. It clicks every button, checks every dropdown, validates every flow. Automated QA by the same system that built it.

Getting It Live

With Vercel, deploying is literally a git push. Push to staging, test, push to production. No DevOps team required.

Set up a staging environment and a production environment from day one. Test everything in staging before it touches real users. This discipline will save you from the kind of mistakes that erode user trust early on.

The Real Skill

It's not prompting. It's not coding.

It's decomposition and review cycles.

Break the problem down into smaller and smaller pieces. Have AI challenge every layer. Build in small, testable increments. Ship.

That CTO told me he might rethink his entire org structure based on what one person with this system can produce.

That's not a statement about me. That's a statement about where we are.

If you have deep knowledge of a problem, you already have the hard part. Start with Phase 1 this weekend. One problem. Plain English. Talk to the AI for five minutes. See what happens.