Week 3 of 12 · Phase 1: Build and launch

Week 3: plan the MVP, cut it down and ship v1 in seven days

55 min to read · the doing takes the week0/6Start the challenge to see your dates →
This week in short

YC’s first advice to founders is to launch right away, and partner Michael Seibel’s version is to launch something bad quickly. On average 40% of companies YC funds are just an idea at the start, so many spend the early batch building a first version. This week you write a one-page spec for the top problem from week 2, cut it to what one person can build in a week, and put it in the hands of real users.

Week 3 challenge · Build and launch

The 7-day v1 challenge

Write a one-page spec for the top problem from week 2, cut it until it fits seven days, and by day 7 have at least three people from your week 2 conversations use it for real.

You pass when
The one-page spec with its "in" and "out" lists, and the names of three users who used v1, with what each did (a screenshot, a log entry or a payment).
Why YC founders do this
Michael Seibel’s "How to Plan an MVP" (YC Startup School): launch something bad quickly, timebox the spec, write it down, cut scope.
How to do it this week ↓

YC does not publish a day-by-day calendar. We rebuilt the structure from YC’s pages, partner talks and founders’ accounts; every claim is labelled documented or reported. Unofficial, not affiliated with Y Combinator.

Inside YC · around week 3

What happens inside YC this week

Reported by founders who did the batch

YC’s FAQ says that on average 40% of the companies it funds in each batch are "just an idea". YC’s 2017 pocket guide, written up by Geoff Ralston, says "The first thing we always tell founders is to launch their product right away". Michael Seibel, a longtime YC partner, gave the method in his Startup School talk: timebox the build, write the spec down, cut scope, and build a first version in weeks, not months.

Founders describe partners pushing on speed. Nathan Leung of Harbor (Spring 2026) wrote that partners "have been aggressively pushing us to ship even more and even faster with AI." Aditya Jayaprakash of Blacksmith (W24) wrote that group partners pushed companies to launch early. Rafael Garcia of Kernel (S25) said his team went from "basically no product" to a product he calls best-in-class within the three months.

Timing varies by company. John Lafleur, cofounder of Dataline (later Airbyte), wrote that his team spent month one on customer meetings and set an alpha version as the goal for month two. YC does not publish a week by which an MVP must exist. Week 3 is our choice for this program, so that weeks 4 to 12 have a real product to launch and grow.

1 framework · explained here in full

This week’s framework

How to plan an MVP: timebox, write it down, cut

Michael Seibel, cofounder of Justin.tv and Twitch, longtime YC partner (Startup School 2019)

Seibel’s main point fits in four words: launch something bad quickly. The first version is not the product. It is the simplest thing you can give your first users to see whether you can deliver any value, so you learn from what they do instead of guessing.

He gives a rule for what to hold on to. Hold the problem and the customer tightly; hold the solution loosely. If v1 doesn’t work, you keep the problem and the user and change the solution. That is iterating, not pivoting.

His examples are deliberately unimpressive. Airbnb’s first version had no payments, so guests paid hosts in person, and no map view. Justin.tv, which became Twitch, was one channel showing one person, Justin, in very low-resolution video, and no video games. Stripe, then called /dev/payments, had almost no features, and its founders sometimes went to customers’ offices to integrate it by hand.

He also says YC sees startups begin with just a landing page and a spreadsheet. Regulated and hard-tech companies may need a heavier first version, but even their first step can be a simple site explaining what they do.

  1. 1Write the problem and the user in one sentence each, from your week 2 ranking. These stay fixed.
  2. 2Timebox the build. Seibel uses three weeks as an example and says weeks, not months. For this program, the box is seven days (our choice).
  3. 3Write the spec down: what v1 must do for the user to get value once. A written spec makes every change to it visible.
  4. 4Our addition: write an "out for now" list next to it. Everything clever goes there.
  5. 5Each day, check progress against the date. If you are behind, cut the things that clearly aren’t important; if nothing unimportant is left, Seibel says to start cutting important things. Keep the date.
  6. 6Do by hand whatever you can, like Stripe’s founders integrating for customers. A form, a spreadsheet and WhatsApp count.
  7. 7Ship to the people you interviewed, watch them use it and talk to them again. Don’t fall in love with v1; it is step one.
Illustrative: a one-page, 7-day spec
Problem: tuition teachers can’t easily track who has paid when parents mix cash and UPI.
User: home tuition teachers with 20–60 students.
Timebox: 7 days. Ship to 5 teachers from week 2 on day 7, whatever state it is in.

In:
- A sheet per teacher: student, fee, paid or not (we set it up for them)
- Every Sunday we send the teacher a "not paid yet" list on WhatsApp
- One polite reminder message per parent, copy-paste ready

Out for now:
- An app or login
- Automatic UPI matching
- Payment links
- Class scheduling
- Reports, analytics, multiple languages

Done by hand: we update the sheets from teachers’ screenshots each evening.
2 talks · play here

This week’s talks

Michael Seibel - How to Plan an MVP
Y Combinator · 14 min

The source for this week’s method. Pause at the Airbnb, Twitch and Stripe examples and compare them with your own spec.

How to Build An MVP | Startup School
Y Combinator · 31 min

Seibel’s later Startup School talk on the same subject. Listen for why founders fear launching early and how he answers those fears.

6 assignments · saved on this device

Your week

Do these before next week. Each one says why it matters and what done looks like.

0 of 6 done

  • Seibel: hold the problem and the customer tightly, the solution loosely.

    Done when: Two sentences that name a specific user and a problem at least half your interviewees raised.

  • Seibel says to write the spec down so that changes to it are visible.

    Done when: One page, and the "out" list is at least as long as the "in" list.

  • Seibel’s landing-page-and-spreadsheet start, and Stripe’s founders integrating by hand.

    Done when: Each manual step has a named person and a daily time to do it.

  • Seibel: when you are behind, cut the spec, not the deadline.

    Done when: A dated note of what you cut, or "nothing cut".

  • Seibel: get anyone using your product as early as possible, then talk to them.

    Done when: Three named users who used it for real, with what each did.

  • Keep the weekly rhythm; this is the first week your primary metric can move.

    Done when: Update sent with ship date, users on v1 and your primary metric.

Office hours · run it yourself

Questions a YC partner would ask you now

Answer each in one or two sentences, out loud first, then in writing. If an answer is vague, that is this week’s problem to fix.

  1. 01
    Why a partner asks this

    Seibel’s rule: hold the problem and the customer tightly. A vague user means a vague spec.

  2. 02
    Why a partner asks this

    Seibel says to cut the spec, not the date, when you fall behind.

  3. 03
    Why a partner asks this

    Seibel’s timeframe is weeks, not months, and YC’s first advice is to launch right away.

  4. 04
    Why a partner asks this

    Seibel says YC sees startups begin with exactly that.

  5. 05
    Why a partner asks this

    Seibel: keep the problem and the customer, change the solution. Iterate before you pivot.

Weekly update · users on v1 this week

Write this week’s update

Update #3: did v1 ship (date), how many people used it and what they did, what you cut, what you are doing by hand, your primary metric versus target, and one ask.

Your update, ready to send
Our company: week 3 update

Our number: ?
This week's focus: users on v1 this week
What we did: -
What we learned: -
Biggest obstacle: -
Ask: -

Your number also goes into the growth tracker on the program page. Saved on this device.

Checkpoint before week 4

Before week 4: a written one-page spec, v1 shipped within seven days, and at least three real users who used it. The seven days are our timebox; the method is Michael Seibel’s in "How to Plan an MVP" (launch something bad quickly, timeboxed in weeks), and the urgency comes from Geoff Ralston’s YC essential advice to launch right away.

Questions about week 3

How long should it take to build an MVP?

Michael Seibel says weeks, not months, and uses three weeks as an example timebox. This program uses seven days so one person can ship v1 inside the week. Write the spec down and cut features when you fall behind.

What if my MVP is embarrassing?

That is normal. Seibel’s examples: Airbnb had no payments or map, Justin.tv was one low-resolution channel, and Stripe’s founders integrated it by hand. More in /paul-graham/launch-and-talk-to-users.

Is doing things by hand a real MVP?

Yes. Seibel says YC sees startups begin with just a landing page and a spreadsheet. Doing the work by hand also teaches you what to automate later. More in /paul-graham/do-things-that-dont-scale.

Sources for week 3