Got an app idea? Check if you're ready to build

The App Readiness Checklist: YC Edition

expoflow app-development mvp startup y-combinator product-development

Y Combinator has funded over 5,000 startups. The patterns they’ve seen — what works, what fails, and why — are remarkably consistent. And they map almost perfectly onto the questions in the App Readiness Scorecard.

This is the same checklist, rewritten through the lens of YC’s best advice. Each question includes references to the talks, essays, and lectures where these ideas are explored in depth.

1. How clear is your app idea right now?

YC Partner Kevin Hale has a simple test: can you describe your startup so clearly that someone who hears it can explain it to someone else? If your idea requires a five-minute explanation, it’s not ready.

In his Startup School talk How to Pitch Your Startup, Hale explains that clarity isn’t just about communication — it’s about thinking. A muddled pitch usually reflects a muddled idea. The exercise of compressing your app into one clear sentence forces you to decide what actually matters.

What YC would tell you:

  • Lead with the problem, not the solution. “We help X do Y” is clearer than “We’re building a platform that leverages AI to…” Jargon and buzzwords are a sign you haven’t found the simple truth yet.
  • If you can’t explain it, you can’t build it. Paul Graham makes this point in Startups in 13 Sentences — the best founders can articulate their idea with zero wasted words.
  • Clarity compounds. When your idea is clear, everything downstream gets easier: hiring, fundraising, marketing, and making product decisions. When it’s vague, every decision becomes a debate.

2. What problem does your app solve?

Paul Graham’s essay How to Get Startup Ideas is the definitive piece on this topic. His core argument: “The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.”

The best startup ideas come from founders who notice something broken in their own lives or work. They don’t start with a solution — they start with a frustration.

What YC would tell you:

  • Live in the future and build what’s missing. Graham argues that the best founders are people who are already dealing with tomorrow’s problems today. If you’re solving a problem you personally experience, you have a massive advantage over someone guessing at other people’s needs.
  • Beware “sitcom ideas.” Kevin Hale’s How to Evaluate Startup Ideas warns against ideas that sound plausible but aren’t grounded in real pain. A sitcom idea is one that seems like it could be a startup, but nobody actually has the problem. Test this by asking: are people already spending time or money trying to solve this?
  • The best problems are ones people are actively hacking around. If your potential users are cobbling together spreadsheets, emailing themselves reminders, or paying for an expensive tool they hate — that’s a real problem worth solving.

3. Have you validated this idea with real users?

Gustaf Alstromer’s Startup School lecture How to Talk to Users is essential viewing. His key insight: most founders talk to users wrong. They pitch their idea and ask “Would you use this?” — which always gets a polite yes. Instead, you should ask about the user’s current behaviour and existing problems.

YC considers talking to users one of the two most important things a startup can do (the other is writing code).

What YC would tell you:

  • Ask about the past, not the future. “Tell me about the last time you had this problem” gives you real data. “Would you use an app that does X?” gives you wishful thinking. People are terrible at predicting their own future behaviour.
  • Five good conversations are worth more than 500 survey responses. Depth beats breadth at this stage. You’re not looking for statistical significance — you’re looking for patterns and surprises.
  • Get your first customers before you build. In How to Get Your First Customers, Alstromer explains that the best founders start selling before the product exists. If you can’t convince someone to sign up for a waitlist or pre-pay for a solution, that tells you something important.

4. How clearly defined is your target audience?

Paul Graham’s Do Things That Don’t Scale contains one of YC’s most important lessons about audience: start narrow. Deliberately narrow.

Facebook didn’t launch for the world — it launched for Harvard students. Airbnb didn’t try to serve all travellers — they started with conference attendees who couldn’t find hotel rooms. The pattern is consistent: the biggest companies started by being essential to a tiny group.

What YC would tell you:

  • “Everyone” is the wrong answer. In Startup = Growth, Graham explains that startups need to find a small market they can dominate quickly, then expand outward. If your target audience is “everyone,” you have no wedge to get started.
  • Recruit your first users manually. Graham’s “do things that don’t scale” advice means going out and finding individual users one by one. You can only do this if you know exactly who they are and where to find them.
  • Your early users are your co-designers. A narrow, well-defined audience gives you a tight feedback loop. When you know your users personally, you understand their problems deeply — and you build better products as a result.

5. Which best describes your MVP scope?

Michael Seibel’s Startup School talk How to Plan an MVP opens with a line that makes most founders uncomfortable: “Launch something bad quickly.”

He doesn’t mean launch something broken. He means launch something embarrassingly simple. The point of an MVP is not to impress anyone — it’s to start the learning cycle as fast as possible.

What YC would tell you:

  • Your MVP should take weeks, not months. In How to Build an MVP, Seibel walks through real examples of YC companies that launched with shockingly minimal products. Stripe started by manually processing payments for users. Airbnb’s first version was a basic website with photos of an apartment.
  • Cut features until it hurts, then cut more. Seibel’s rule: write down every feature you think you need, then cross out 75% of them. Whatever remains is probably still too much.
  • Don’t fall in love with your MVP. It’s a tool for learning, not a product you’re proud of. The faster you accept this, the faster you’ll ship — and the faster you’ll learn what actually matters.

6. What’s the main goal of your first version?

Kat Manalac’s How to Launch (Again and Again) reframes launching entirely. Most founders treat launch day as the finish line. YC treats it as the starting line.

Your first version exists to answer a question. If you don’t know what question you’re trying to answer, you’re not ready to build.

What YC would tell you:

  • Launch to learn, not to impress. YC’s Essential Startup Advice puts it bluntly: “Launching a mediocre product as soon as possible, then talking to customers and iterating, is much better than waiting to build the perfect product.”
  • Define your hypothesis. Before building anything, write down what you expect to happen when real users interact with your product. “I believe [type of user] will [take this action] because [reason].” Then build the minimum thing that tests that belief.
  • Launching is not a one-time event. Manalac argues you should launch repeatedly — on different channels, to different audiences, with different messages. Each launch is an experiment that teaches you something new.

7. What’s your target timeline for launching?

Paul Graham’s advice in Startups in 13 Sentences is characteristically direct: “Launch fast.” His reasoning: “The reason to launch fast is not so much that it’s critical to get your product to market early, but that you haven’t really started working on it till you’ve launched.”

Before launch, you’re guessing. After launch, you’re learning.

What YC would tell you:

  • Set a deadline and work backwards. Kat Manalac’s The Best Way to Launch Your Startup provides practical tactics for getting your product out the door. The key is to pick a launch date, decide what must be ready by that date, and cut everything else.
  • Weeks, not months. YC companies typically have 3 months from batch start to Demo Day. That’s not much time — and many of them launch (or re-launch) within weeks of starting the programme. If they can do it, so can you.
  • Perfectionism is procrastination in disguise. Every week you spend polishing before launch is a week you’re not learning from real users. The only feedback that matters comes from people using your product in the real world.

8. What best describes your current budget?

Paul Graham’s essay Ramen Profitable introduced a concept that changed how early-stage startups think about money. A “ramen profitable” startup makes just enough to cover the founders’ basic living expenses. It’s not glamorous — but it means you’re no longer dependent on anyone else’s money to survive.

What YC would tell you:

  • Spend as little as possible for as long as possible. Geoff Ralston’s A Guide to Seed Fundraising advises that you should “raise as much money as you need to reach profitability so that you’ll never have to raise money again.” For most startups, that means being extremely disciplined about spending in the early days.
  • Time is your most valuable currency. Your budget determines your runway — the number of months you can keep going before the money runs out. Every unnecessary expense shortens your runway and reduces the number of experiments you can run.
  • Revenue is the best funding. Before chasing investors, ask whether you can get customers to pay you. Even small amounts of revenue change the equation entirely — you have proof of demand, leverage in fundraising, and the beginnings of a sustainable business.

9. How comfortable are you with changing direction based on feedback?

Dalton Caldwell’s Startup School lecture All About Pivoting is the best resource on this topic. He walks through the mechanics of when and how to pivot, with real YC examples: Brex pivoted from VR hardware to corporate credit cards. Retool pivoted from a Venmo competitor to no-code internal tools. Segment pivoted from a classroom tool to data infrastructure.

The common thread: the founders paid attention to what was actually working rather than what they wished was working.

What YC would tell you:

  • Your idea will almost certainly change. In Before the Startup, Paul Graham tells Stanford students that “the most successful startups almost all seem to have evolved substantially from their original idea.” This isn’t a failure — it’s the process working as intended.
  • Hold the problem, not the solution. Caldwell’s framework for evaluating a pivot: Does the new direction address a bigger opportunity? Do you have founder-market fit? Can you get started quickly? Is there early market feedback? If the answer to those questions is yes, pivot without guilt.
  • Stubbornness about vision, flexibility about details. Jeff Bezos said this, but it’s deeply embedded in YC culture. Stay committed to the problem you’re solving and the people you’re serving. Be willing to change everything else.

10. How involved do you want to be during development?

Paul Graham’s 2024 essay Founder Mode — inspired by Brian Chesky’s experience at Airbnb — argues that the conventional advice to “hire good people and give them room to do their jobs” is often disastrous for startups. Founders who stay deeply, hands-on involved build better products.

This applies just as much to founders working with development partners as it does to founders managing internal teams.

What YC would tell you:

  • Nobody understands your users like you do. The hundreds of micro-decisions that happen during development — what to prioritise, how a feature should feel, what edge cases matter — all benefit from the founder’s context. Delegating these decisions entirely is how products drift away from what users actually need.
  • Stay in the details. Chesky’s lesson, as described by Graham, is that founders who engage at the detail level — reviewing designs, testing features, talking to users weekly — build products that feel coherent and purposeful. Founders who manage from a distance get products that feel like they were built by committee.
  • The best products come from tight loops. How to Build a Product — a conversation between Michael Seibel, Emmett Shear (Twitch), and Steve Huffman (Reddit) — shows how the most successful technical founders stayed deeply involved in product decisions even as their companies scaled.

Where Do You Stand?

YC’s advice boils down to a simple loop: build something small, put it in front of real users, learn from what happens, and iterate. The founders who succeed are the ones who move through this loop fastest — and that requires clarity, focus, and a willingness to be wrong.

If you’ve read through these questions and most of them feel solid, you’re in a strong position. If several made you uncomfortable, that’s useful information. The discomfort is pointing you toward the work you need to do before writing code.

Want to find out your readiness score? Take the App Readiness Scorecard — it takes less than two minutes.

Or if you’d prefer to talk it through, book a discovery call and we can figure out the right next step together.

Further Reading

All the YC resources referenced in this article: