Turn YouTube videos into a SaaS in 7 days (a builder's playbook)

I'll start with the obvious caveat: shipping a polished, scaling SaaS in seven days is a fantasy. Shipping the v0 of a real product — landing page, auth, paid plan, the one core loop working end-to-end — in seven focused days is not. We've watched indie hackers do it cleanly when the research-to-build handoff is tight.

The bottleneck for most of them isn't code. It's deciding what to build with enough conviction to commit a week. That's the part this playbook addresses, day by day.

Day 1 — Choose a research topic worth a week

The biggest lever you'll pull all week is the topic itself. Pick wrong and even perfect execution loses. The filters that have worked for us:

• Active discussion volume. If there are no recent 15-minute-plus YouTube videos on the topic from credible creators, the audience isn't there yet.
• Disagreement among credible voices. Boring consensus topics ("everyone agrees you should use Stripe") have no wedge available. Topics where two thoughtful creators contradict each other on workflow ("you should run agents locally" vs "you should never run agents locally") have a wedge hiding in the resolution.
• One named pain you can articulate in one sentence. If you can't, you don't understand the topic well enough to commit a week.

Ship Day 1 with: a one-paragraph project brief in a Notion doc that names the topic, the audience, the candidate pain, and one line about why now. Don't worry if it's wrong yet — Day 3 will sharpen it.

Days 2–3 — Gather and synthesize the research corpus

Two days for this is generous. If you're using YouTubeToSaaS or a similar pipeline, the actual processing is hours; the rest is watching the synthesis output and adjusting your topic framing based on what's actually in the corpus.

Day 2: collect 15–20 videos

The corpus rules:

• 4–6 critics, 10–12 builders. A balanced corpus surfaces real disagreement. An all-builders corpus produces marketing.
• Mix lengths. A 90-minute podcast and a 5-minute tutorial bring different signal. Aim for at least three videos over 60 minutes — that's where the failure-mode discussions happen.
• One reference video from 12+ months ago. If the old approach still works, that's signal. If it doesn't, understanding why is signal.

Day 3: run synthesis, sharpen the brief

Whether you're running synthesis manually (our methodology guide walks through it) or using YouTubeToSaaS, the output you need by end of Day 3:

• 3–5 repeated patterns across multiple videos with evidence URLs
• 2–3 contradictions you have a credible take on
• A defensible wedge — one sentence, named, specific
• ≥4 named failure modes with triggers and mitigations
• An MVP scope of 3–5 features (not more)
• A "Do Not Build Yet" list that's honest about temptations you're refusing

Hold yourself to the rule: if the wedge is generic ("better UX", "AI-powered"), Day 3 isn't done. Run synthesis again with a sharper question. Ten minutes spent re-running synthesis beats four days spent building toward a non-wedge.

Day 4 — Generate CLAUDE.md and STARTER_PROMPT, set up the repo

Day 4 is the day you stop thinking and start scaffolding.

The order:

1. Generate CLAUDE.md from the synthesis. This is the agent contract for the whole week. (our guide on writing one if you're doing this manually.)
2. Generate STARTER_PROMPT.md — the first message you'll send to a fresh Claude Code session. Includes the stack mandate, the deploy targets, and the v0 scope.
3. Create the repo with auth scaffolding, Stripe test-mode integration, and one placeholder feature page. Do this via Claude Code with the STARTER_PROMPT as message 1.
4. Deploy to Vercel + Render (or your preferred targets). The act of deploying on Day 4 — even with no real feature — saves you from the Day-7 deploy panic.

Day 5 — Build the one core loop end-to-end

Day 5 is for the MVP's single hero feature. Not all 5 you scoped — the one. The other 4 are decoration if the hero feature doesn't deliver value alone.

The discipline:

• End-to-end first, polish second. Ugly button → API call → real model output → result rendered. Wire it up before you style it.
• One real user story, fully. Not five user stories at 70%.
• The output has to feel like the product, not a demo. If the hero feature emits a markdown file, the file should be formatted like a real artifact — headings, sections, citations — not bullet-point chatGPT slop.

End of Day 5: you (and one trusted friend) can run the core loop and the output is something you'd genuinely use. If it isn't, Day 6 is for fixing that, not for adding features.

Day 6 — Onboarding, billing, and the marketing surface

Day 6 is the day everything outside the hero feature gets just enough attention to ship. The list:

1. Auth that works. Email + password is fine. Don't spend Day 6 on OAuth.
2. One paid plan in Stripe (test mode), priced based on your unit economics. Two tiers if you must, but most v0s ship with one.
3. A landing page with the hero, three feature cards, a pricing card, and a 3-question FAQ. Don't write a manifesto.
4. Onboarding empty-state — when a new user signs up, what do they see? "Welcome, here are 3 example projects" or "Paste your first input here" beats an empty dashboard.

Day 7 — Launch (small)

The Day 7 mistake everyone makes: a Product Hunt launch. PH is a spike + a single-day attention window. You don't have a feature roadmap to keep that attention engaged yet. Save it for Week 4 when you have iteration data.

What to do instead on Day 7:

• Write the launch post for one community. Indie Hackers, Hacker News Show, or one Reddit subreddit where your audience genuinely hangs out. Pick the one most likely to give you honest feedback.
• Personally DM 10 people who would actually use this. Not "check this out" — "I built X because Y. I'd genuinely like 15 minutes of your honest reaction." 3 will respond. 1 will become your first paying customer in week 2.
• Tweet thread, but with a posture. Not "I built this!" — "I spent 7 days going from research to launch on $X and here's what surprised me." A meta-post about the process gets attention; a "look at my product" post gets crickets.

What happens in week 2

Week 2 is when you find out which of your synthesis claims were right. This is good. The whole point of Day 3's "Do Not Build Yet" list is that you have the discipline to stay focused on the wedge instead of building toward whatever the first 5 users ask for.

The rule for week 2:

• Strengthen the wedge before you broaden the product. If users are saying "the wedge is great but X is rough", fix X. If they're saying "I'd love feature Y", evaluate Y against the wedge. If Y is the wedge done better, ship it. If Y is a different wedge, write it down for v2 but don't build it.
• One paying customer beats fifty signups. Don't measure week 2 by signups. Measure it by "someone gave me money for this".

Honest caveats

Three things this playbook doesn't fix:

• It can't compensate for picking the wrong topic. If Day 1 is a topic with no real audience, no execution speeds you up. Day 2-3 should kill bad topics. If your synthesis surfaces no contradictions and no failure modes, that's the corpus telling you the topic is too thin.
• It assumes you ship. The plan is meaningless if you don't deploy on Day 4 and launch on Day 7. The deadlines are load-bearing — they prevent the perfectionism that kills v0 launches.
• It produces a v0, not a finished product. What you ship on Day 7 is a forcing function for week 2. The real product is week 4.

Closing thought

Seven days isn't a stunt. It's the cadence of disciplined indie hackers who treat research and code as the same workflow, not two separate domains. The synthesis output of Day 3 directly becomes the CLAUDE.md and STARTER_PROMPT of Day 4, which directly becomes the working code of Day 5. Each day's output is the next day's input.

The compression that makes this work is in the handoffs. Tools that produce buildable artifacts (CLAUDE.md, STARTER_PROMPT) save you the day or two of manual translation between "what I learned" and "what I'm building". That's what we built YouTubeToSaaS to do — because we needed it ourselves, weekly.