There's a version of startup building that takes 18 months, costs $150K, and ends at launch day with a product nobody wanted.
There's another version that takes six weeks, costs under $500, and ends with paying customers before a line of production code is written.
The difference isn't talent or luck. It's the order of operations.
The slow version builds first and validates later — assembling a product until it feels ready, then presenting it to the market and hoping the guess was right. The fast version validates first and builds only what's confirmed — moving idea to signal to MVP to paying customer as a continuous loop, building no more than what each step requires.
AI accelerates the fast version dramatically. Lean MVPs can now launch for as little as $200, and AI startups reach $1 million in annual revenue four months faster than traditional SaaS companies. Not because AI does the thinking — it doesn't — but because it removes the production friction between thinking and testing. You can go from idea to landing page in an afternoon. From feature list to interactive mockup in a day. From raw audience research to a positioned first message in an hour.
The question has shifted from "can I build this?" to "how fast can I test this?" That shift changes everything about how you spend the first 30 days.
This guide covers the full pre-revenue sprint: idea narrowing, feature definition, mockup creation, landing page copy, onboarding flow, and first acquisition channel — all with AI doing the heavy lifting on production, you doing the thinking.
The Pre-Revenue Mistake Most Founders Make
Before the sprint, one mental model that changes how you use every tool in this guide.
Most founders treat pre-revenue as a building phase. They spend months designing, building, and refining before they show anything to anyone. When they finally do show it, they discover that what they built doesn't match what customers wanted — and the months of building were largely wasted.
The correct mental model: pre-revenue is a learning phase, not a building phase. Every action should be designed to eliminate an assumption — to replace guesswork with signal. Building is the last step, not the first.
Applied to the sprint:
Wrong order: Idea → Build product → Find customers → Discover the product is wrong
Right order: Idea → Define the problem → Validate demand → Define minimum features → Build minimum → Acquire first users → Learn → Repeat
AI doesn't change this order. It compresses the time each step takes. The order still matters. Running the sprint in the wrong direction, faster, produces wrong answers faster.
Phase 1: Idea Narrowing (Day 1, 2-3 Hours)
Most founders start with too many ideas or one idea that's too broad. Before building anything, you need a single, specific, testable hypothesis.
The idea landscape prompt:
If you have multiple ideas competing for attention:
I have several business ideas I'm considering.
Help me narrow to the one most worth building first.
MY IDEAS:
1. [Idea description — 2-3 sentences]
2. [Idea description]
3. [Idea description]
MY CONSTRAINTS:
- Solo founder, [X] hours/week available
- Budget: $[X] for first 90 days
- Technical ability: [Non-technical / Some code / Developer]
- Existing audience or network: [Describe if any]
- Domain expertise: [Where you have genuine knowledge]
Evaluate each idea on:
1. PROBLEM CLARITY: Is the problem specific and painful enough?
Rate 1-5 with reasoning.
2. MARKET EVIDENCE: Any signals this market exists
(search volume, competitors, community activity)?
Rate 1-5 with reasoning.
3. FOUNDER FIT: Does this founder's background,
network, or expertise give them an edge here?
Rate 1-5 with reasoning.
4. SPEED TO SIGNAL: How quickly could this founder
get a yes/no from the market —
days, weeks, or months?
Rate 1-5 with reasoning.
5. REVENUE CLARITY: Is there an obvious monetization path?
Rate 1-5 with reasoning.
TOTAL SCORE and RECOMMENDED IDEA:
Which one to pursue first, and why.
Also flag: What's the single riskiest assumption
in the recommended idea?
The idea sharpening prompt (once you've picked one):
Most ideas start vague. "A tool that helps freelancers manage clients" is a category, not an idea. Run this to sharpen it:
Sharpen my business idea into a testable hypothesis.
MY RAW IDEA: [Describe it]
Push it through these filters:
1. WHO EXACTLY:
Not "freelancers" — which freelancers?
What industry, what stage, what tool stack?
Give me a one-sentence ICP that would make
95% of the world say "that's not me."
2. WHAT SPECIFICALLY:
Not "manage clients" — what single workflow
or task is broken? What do they do today
that's painful and why?
3. BETTER THAN WHAT:
What are they doing right now instead
of using my product?
(Spreadsheet, different tool, manual, nothing?)
What specifically is wrong with that?
4. THE HYPOTHESIS:
Complete this sentence in one clear statement:
"I believe [specific ICP] currently struggle
with [specific problem] and will pay [rough price]
for [specific solution] because [reason current
alternatives fail them]."
5. FIRST KILL SHOT:
What's the single assumption in that hypothesis
most likely to be wrong?
What would you test first?
Save the completed hypothesis. Everything in the sprint — features, copy, channel — derives from this statement. If it changes later, update it. But you need one clear hypothesis before building anything.
Phase 2: Feature Definition (Day 1-2, 2-3 Hours)
Once the hypothesis is sharp, define the minimum feature set. The goal is not a feature-complete product — it's the smallest set of functionality that delivers the core value promised in your hypothesis.
The MVP feature scoping prompt:
Define the minimum feature set for my MVP.
MY HYPOTHESIS: [Paste your hypothesis statement]
MY ICP: [Specific description]
MY BUDGET AND TIMELINE:
Budget: $[X]
Timeline: [X weeks to first paying customer]
TECHNICAL ABILITY: [Non-technical / Some / Developer]
The MVP must:
1. Deliver the core value promised in my hypothesis
2. Be buildable within my timeline and budget
3. Be testable — I can tell if it worked or not
Run the MoSCoW prioritization for features:
MUST HAVE (without these, the product doesn't work):
[List 3-5 features — these are in the MVP]
SHOULD HAVE (valuable but not required for core value):
[List 3-5 features — these come post-validation]
COULD HAVE (nice to have, often over-engineered):
[List features founders typically build that kill scope]
WON'T HAVE (explicitly out of scope for MVP):
[List at least 5 — this is the scope protection list]
For each MUST HAVE feature:
- One-line description of what it does
- Why it's required (not just useful)
- Simplest possible implementation
(What's the version that takes hours, not weeks?)
SCOPE RISK ASSESSMENT:
What are the top 3 ways this MVP scope will expand
if I'm not disciplined?
How do I prevent each one?
The "fake door" test (for non-technical founders):
Before writing any code, the fastest MVP is often no product at all — just a test of whether people want what you're describing.
I want to test demand for my product before building it.
Design a "fake door" test for my hypothesis.
MY HYPOTHESIS: [Paste]
A fake door test shows the product's value proposition
and measures real intent without building the product.
Design:
1. LANDING PAGE STRUCTURE:
- Headline (what it does, for whom)
- 3 bullets of value (outcomes, not features)
- Social proof placeholder
(what would make this credible at launch?)
- CTA: What should I ask them to do?
(Email signup / Waitlist / Pre-order / Book a demo)
2. SUCCESS METRIC:
What conversion rate from visitor to CTA
would tell me demand is real?
(Typical benchmarks: 5% for waitlist,
2% for pre-order, 15% for "notify me")
3. TRAFFIC SOURCE:
Where do I send 100-200 visitors
to get a clean signal?
(Not paid ads — too slow and expensive for a test.
Where does my ICP congregate?)
4. WHAT "VALIDATED" LOOKS LIKE:
If X% of visitors take the CTA action,
what does that tell me?
What would I build next?
What would make me kill or pivot?
This test — landing page + one traffic source + a week — often replaces three months of building. A lean founder can produce a PRD, tech spec, and wireframe drafts in under 48 hours using AI tools, but if 0.3% of visitors click the CTA, no spec saves you. Test demand before building spec.
Phase 3: Mockups and Wireframes (Day 2-3, 2-4 Hours)
Once demand is validated (or assumed with enough confidence to proceed), mockups serve two purposes: they force you to make concrete product decisions before touching code, and they give early users something to react to in interviews.
For non-technical founders — the AI wireframe brief:
You don't need Figma skills to produce a useful mockup. You need a detailed enough brief that a tool or contractor can produce one quickly.
Create a detailed wireframe brief for my MVP.
MY MVP: [Name and one-sentence description]
CORE USER FLOW:
[Describe in plain English: user opens app →
sees X → does Y → achieves Z]
For each screen in the core user flow, describe:
SCREEN NAME: [e.g., Dashboard, Onboarding Step 1]
PURPOSE: What does the user accomplish here?
ELEMENTS: What appears on this screen?
- Primary action (the one thing I want them to do)
- Secondary information (what they need to see)
- Navigation (where can they go from here?)
COPY NEEDED: Any text/labels/CTAs on this screen
DESIGN PRINCIPLES FOR THIS MVP:
- Prioritize clarity over beauty
- Every screen should have one primary action
- Remove anything not required for the core flow
- Mobile-first if ICP is likely on mobile
Output: A screen-by-screen description I can hand
to a designer or paste into Figma/Whimsical.
Tools for solo founder mockups:
Whimsical (free): Best for quick lo-fi wireframes. Drag-and-drop, no design skills required. Use for internal planning and early customer interviews.
Figma (free tier): Industry standard. Steeper learning curve but AI-assisted features in 2025 generate wireframe layouts from text descriptions. Worth learning if design is a significant part of your product.
Lovable / Bolt.new (free tiers): AI-powered full-stack app builders. Describe your app in plain English, get a working prototype with real UI. For non-technical founders who need something clickable for early users, this is the fastest path from description to demo.
v0 by Vercel (free tier): Generates React UI components from text prompts. Best for founders with some technical ability who want production-ready UI components rather than mockups.
The mockup review prompt (before showing anyone):
Review this mockup description for common
solo founder MVP mistakes.
MY CORE USER FLOW: [Paste your screen-by-screen brief]
Check for:
1. FEATURE CREEP: Any screen that isn't required
for the core value delivery?
2. ASSUMPTION BAKING: Any design decision that
assumes behavior you haven't validated?
3. COMPLEXITY TAX: Any flow that requires more
than 3 clicks to reach core value?
4. MISSING STATES: Error states, empty states,
and loading states that will break
the first-user experience if not designed?
Flag each issue and suggest the minimal fix.
Phase 4: Landing Page Copy (Day 3-4, 2-3 Hours)
The landing page does more work than any other artifact you'll create. It validates your messaging before you've built the product, converts visitors to waitlist or paying customers, and tells you — through what converts and what doesn't — whether your positioning is correct.
Most founders write landing page copy that describes their product. The best landing page copy describes the customer's problem and positions the product as the obvious solution. The difference is whose perspective the copy is written from.
The landing page copy prompt:
Write landing page copy for my MVP.
MY HYPOTHESIS: [Paste]
MY ICP: [Specific description]
CUSTOMER LANGUAGE: [Exact phrases from community
research — how they describe the problem
in their own words]
COMPETITOR ALTERNATIVES: [What they currently use
instead — and what's wrong with it]
PRICE: $[X]/month or waitlist (if pre-launch)
PROOF I HAVE: [Any early users, testimonials,
relevant credentials, or social proof]
Write the following sections:
1. HERO HEADLINE (max 8 words)
Formula: [Outcome] for [Specific ICP]
without [Specific Pain]
Write 5 variants — I'll choose.
2. HERO SUBHEADLINE (1-2 sentences)
Expand on the headline with enough specificity
that the right person immediately thinks
"this is for me."
3. PROBLEM SECTION (3 bullets)
Each bullet: One specific pain point,
written in customer language.
Start each with "You [situation]..."
Make the reader feel seen, not sold to.
4. SOLUTION SECTION (3 bullets)
Mirror the problem bullets with outcomes.
Not features — what they can do or feel
after using the product.
5. HOW IT WORKS (3 steps)
Simple, jargon-free description of the
core workflow. Step titles should be
action verbs: "Connect, Configure, Done."
6. SOCIAL PROOF SECTION
If I have testimonials: format them.
If I don't: write placeholder copy for
the structure I should fill as I get proof.
7. CTA SECTION
Primary CTA text (the button copy —
not "Submit" — something that communicates value)
Secondary CTA text (for visitors not ready to buy)
Risk reversal line (what reduces friction:
free trial, no credit card, money-back guarantee?)
TONE CHECK:
This copy should sound like it was written by
a founder who deeply understands the ICP's
daily frustrations — not a marketing agency.
Flag any line that sounds generic or corporate.
The five-second test prompt:
Before publishing, check if the page passes the clarity test:
Read only my hero headline and subheadline:
[Paste headline and subheadline]
Answer:
1. In five seconds, can someone tell:
what this does, who it's for,
and why it matters?
2. What's the most likely point of confusion?
3. Would someone in this ICP immediately think
"this is for me" or "maybe this is for me"?
("this is for me" is passing. "maybe" is failing.)
4. What one word change would make this sharper?
Phase 5: Onboarding Flow (Day 4-5, 2-3 Hours)
Most founders build the product and forget to build the onboarding. First-time users arrive, have no idea what to do, and leave within 90 seconds. Your product could be excellent and you'd never know — because users churned before experiencing it.
Onboarding is where you transfer the value proposition from the landing page into the actual product experience. The gap between "this sounded good" and "this is actually useful" is closed or opened in the first 10 minutes.
The onboarding flow design prompt:
Design an onboarding flow for my MVP.
MY PRODUCT: [Description]
CORE VALUE MOMENT: The specific moment when a new user
first thinks "this actually works" —
[describe what that looks like in your product]
MY ICP: [Description]
CURRENT ONBOARDING PLAN: [Describe what currently
happens when a new user signs up, if anything]
Design a first-session onboarding flow:
GOAL: Get users to the Core Value Moment
in under 10 minutes.
PRINCIPLES:
- Every step should reduce time to Core Value Moment
- Remove any step that doesn't directly serve
getting to the Core Value Moment
- Ask for information only when it's required
(not "fill out your profile" —
only what's needed to deliver value)
ONBOARDING STEPS:
For each step:
- Step name
- What the user does
- Why this step is required
(if you can't explain why, remove it)
- Copy for any prompts, empty states, or instructions
- What happens if they skip this step
EMPTY STATE DESIGN:
For each main screen: what do users see
when there's no data yet?
Empty states are where most new users give up.
Design them to prompt action, not show a void.
ACTIVATION METRIC:
What single action confirms a user is
"activated" — truly experiencing the core value?
This is your north star for onboarding success.
TIME ESTIMATE:
If I implement this onboarding, how long should
the first session take an average user?
Target: under 10 minutes to activation.
The first-user welcome sequence:
For the first 10-20 users (pre-scale), personal onboarding outperforms automated onboarding. An email from you, immediately after signup, asking one specific question about what they're hoping to achieve — converts more users to active than any onboarding flow.
Write a personal welcome email for my first users.
MY PRODUCT: [Description]
WHAT I WANT TO LEARN FROM THEM:
[The one question that would most help you
improve the product at this stage]
Write:
Subject line: (personal, not promotional —
looks like it came from a person, not a system)
Body (under 100 words):
- Genuine welcome (one sentence)
- Acknowledge they're early (being honest
is a differentiator, not a weakness)
- Ask ONE specific question about their situation
- Give them one concrete thing to try first
Sign-off: Your first name only. No logo. No footer.
This email should feel like it was written in
2 minutes by a founder who's excited someone
showed up — not like a marketing sequence.
Phase 6: First Acquisition Channel (Day 5-7, 3-4 Hours)
The biggest mistake at this stage: choosing too many channels. A solo founder who splits attention across SEO, paid ads, cold outreach, social media, and community simultaneously executes all of them poorly. One channel, done excellently, produces more first users than five channels done adequately.
The right first channel is determined by one question: where does your specific ICP already congregate, and how do they currently discover products like yours?
The acquisition channel selection prompt:
Help me select and plan my first acquisition channel.
MY ICP: [Specific description]
MY HYPOTHESIS: [Paste]
MY CONSTRAINTS:
Budget: $[X] for first acquisition
Time available: [X hours/week]
Technical ability: [Non-technical / Some / Developer]
Existing assets: [Audience / Network / Content / None]
Evaluate these channel options for my specific situation:
1. COMMUNITY-LED (Reddit, Slack groups, Discord,
niche forums)
Fit score (1-5): Does my ICP congregate here?
Time to first user: Days/Weeks/Months
Skill required: [Low/Medium/High]
Risk: [What makes this fail?]
2. DIRECT OUTREACH (LinkedIn DMs, email cold outreach
to specific ICP)
Fit score: Can I identify and reach these people?
Time to first user: Days/Weeks/Months
Skill required: [Low/Medium/High]
Risk: What makes this fail?
3. CONTENT-LED (Blog, LinkedIn posts,
Twitter/X, YouTube)
Fit score: Does my ICP consume content here?
Time to first user: Weeks/Months
Skill required: [Low/Medium/High]
Risk: What makes this fail?
4. EXISTING NETWORK (People I know,
warm introductions, founder communities)
Fit score: Do I have relevant connections?
Time to first user: Days
Skill required: Low
Risk: What makes this fail?
5. PRODUCT HUNT / DIRECTORY LISTINGS
Fit score: Is my ICP active on PH or
relevant directories?
Time to first user: Days (launch day)
Skill required: Low/Medium
Risk: What makes this fail?
RECOMMENDATION:
Which single channel should I focus on first?
Why this one before others?
What does "success" look like in 30 days
from this channel?
When should I add a second channel?
The first 10 users acquisition plan:
Build my plan to get the first 10 paying users
(or 10 validated beta users) for my product.
RECOMMENDED CHANNEL: [From above]
MY ICP: [Description]
MY OFFER AT THIS STAGE:
[Free beta / Paid early access / Waitlist]
MY POSITIONING: [Headline + one-line description]
For the recommended channel, create:
1. TARGETING CRITERIA:
Exactly where and how to find
10 people who match my ICP
in this channel.
2. OUTREACH OR CONTENT SCRIPT:
The exact message, post, or content
to use to make first contact.
This should:
- Lead with their problem, not my product
- Be honest about being early-stage
- Ask for a conversation or trial, not a sale
- Be under 100 words if direct outreach
3. THE ASK:
What am I asking the first 10 to do?
(Not "buy my product" for user 1 —
what's the smallest step that confirms
real interest?)
4. WHAT TO LEARN FROM EACH CONVERSATION:
The 3 questions to ask every early user
that will tell me if I have
product-market fit potential.
5. SUCCESS DEFINITION:
What does "10 first users" look like
concretely, and by what date?
The first 10 outreach messages (for direct outreach channel):
Write 10 personalized first-contact messages
for direct outreach to potential first users.
MY ICP: [Description]
PLATFORM: [LinkedIn / Email / Twitter DM]
MY OFFER: [Free beta / Conversation / Demo]
WHAT I KNOW ABOUT THEM: [Any signals —
job title, recent post, shared community, etc.]
Rules:
- Each message is different (don't use one template)
- Lead with something specific about them or
a problem they'd recognize
- Never mention your product in the first message
- End with one easy question, not a pitch
- Under 75 words each
Generate 10 variations, each with a different
opening hook based on different ICP situations:
1. Someone who posted about the problem recently
2. Someone in a community where the problem is discussed
3. Someone at a company that would clearly face this problem
4. A warm connection (second-degree network)
5-10: Additional variations for different situations
The 30-Day Sprint Calendar
Here's how the phases map to real days, with realistic time estimates for a solo founder with a day job or other commitments (15-20 hours/week available):
Week 1: Idea and validation
Day 1-2: Idea narrowing, hypothesis sharpening (3-4 hours)
Day 3-4: Community research, demand signal scan (3-4 hours)
Day 5-7: Fake door test setup — landing page + one traffic source (4-5 hours)
Week 2: Signal reading and feature definition
Day 8-10: Review fake door results (are people clicking?)
Day 11-14: Feature scoping with MoSCoW prompt (2-3 hours)
If signal is weak: pivot the hypothesis before building
If signal is strong: proceed to mockups
Week 3: Build what's confirmed
Day 15-17: Wireframes/mockups (3-4 hours)
Day 18-19: Full landing page copy (2-3 hours)
Day 20-21: Onboarding flow design (2-3 hours)
Week 4: First users
Day 22-24: Acquire first 10 users via chosen channel (5-6 hours)
Day 25-27: Run conversations, collect feedback
Day 28-30: Decide: build based on what you learned, or pivot
Decision gate at Day 30:
3+ people paid or committed to pay: BUILD
10+ people engaged but haven't paid: CLARIFY OFFER, then re-ask
Fewer than 10 engaged: PIVOT HYPOTHESIS before building
Building before this gate is the mistake. The gate exists to ensure that what you build, someone asked for with their wallet.
Tools and Cost for the Entire Sprint
THINKING AND WRITING:
Claude Pro or ChatGPT Plus: $20/month
(All prompts in this guide)
LANDING PAGE:
Carrd (landing page builder): $9/year
or Framer free tier: $0
MOCKUPS:
Whimsical free: $0
or Figma free tier: $0
or Lovable/Bolt.new free tier: $0
WAITLIST/EMAIL CAPTURE:
ConvertKit free (up to 1,000 subs): $0
or Beehiiv free: $0
PAYMENT (when you pre-sell):
Stripe (no monthly fee): $0
ANALYTICS:
Plausible: $9/month
or Fathom Analytics free trial: $0
OUTREACH:
LinkedIn free: $0
Gmail: $0
TOTAL SPRINT COST: $29-38/month
TOTAL FOR 30-DAY SPRINT: ~$35-75
This matches the research: the total upfront costs for essentials — website, domain, marketing — can come in well under $200, making quick experimentation highly feasible for lean startups.
Common Mistakes in the AI-Assisted MVP Sprint
1. Using AI to build before validating
AI can generate a full landing page, onboarding flow, and product spec in a single afternoon. The speed is seductive. Don't build it all before testing demand. The fake door test comes before the feature spec. Validated demand comes before the mockup. The order is everything.
2. Writing copy in your voice instead of theirs
The community research prompt exists to extract customer language. Use it. Landing page copy that uses your product vocabulary ("streamlined workflow management") converts worse than copy using their vocabulary ("stop spending hours updating spreadsheets that nobody reads"). The AI needs that input to produce the right output.
3. Building the "complete" MVP instead of the "minimum" one
The MoSCoW prioritization prompt generates a "Won't Have" list for a reason. Every item on that list is something you'll want to add. Don't. The minimum viable product that gets to market in 3 weeks beats the complete product that gets to market in 4 months — because the first one generates real feedback that shapes the second.
4. Picking too many first channels
Pick one. Run it for 30 days. Measure the result. Then decide if you add a second. Community-led acquisition takes 2 weeks to learn. Direct outreach takes 10 conversations to learn. Content-led takes 90 days to learn. Running all three simultaneously makes learning from any of them impossible.
5. Skipping the first-user welcome email
The personal welcome email converting early users to active is one of the highest-ROI things you'll do in the first 30 days. It costs 10 minutes to write and generates conversations that show you what your product is actually being used for. Most founders skip it because it doesn't scale. At 10 users, scale is not the problem.
6. Treating the hypothesis as fixed
The hypothesis is your best current guess. It will be wrong in at least one important way. When the fake door test returns a signal — or when the first user conversations reveal that the problem you assumed is not quite the problem they have — update the hypothesis. Updating it early is progress. Defending it against evidence is the path to building something nobody wanted.
When to Stop Using AI and Start Using Customers
There's a specific moment in every sprint when AI research reaches its limit and real customer conversations become the only source of reliable signal.
That moment is when you have 5+ people who expressed genuine intent (clicked a CTA, joined a waitlist, agreed to a demo, or paid anything). At that point, more AI research doesn't help you. You know the channel works. You know the message resonates at least somewhat. What you don't know is why — what specific problem they're most urgently trying to solve, what almost made them not sign up, what they wish the product did differently.
Those questions are answered by conversations, not prompts.
The AI-assisted sprint gets you to the conversation faster and better-prepared. The conversation itself is irreplaceable.
Run the sprint. Get to 5 genuine signals. Stop building. Talk to those 5 people. Build what they're actually asking for.
That's it.
Comments (0)
Leave a Comment