Sep 18, 2026
By Victor Teran
What to Build First When You Have an Idea and No Users
Only 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Most of the other 95% did not fail at building. They failed at choosing what to build first, which is a different and much cheaper mistake to avoid.
Build
Zero to One
Validation
The first version of a product is not a small version of the finished one. It is an argument, and the only thing it has to do is make that argument checkable by someone who is not you.
That framing changes what goes in it. Founders default to building the thing they can describe, which is usually the full workflow, because that is what lives in their head. What gets you to a real answer is smaller, stranger, and often embarrassing to show.
RevenueCat's data across more than 115,000 apps puts the odds plainly: 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Very little of that gap is engineering talent.
Key takeaways
Build the single path that proves your core claim, not the product that surrounds it. Everything else is deferrable.
Pick the one user action that would tell you the idea works, and design backwards from it.
Y Combinator's own framing is that retention, not signups, is the evidence of product-market fit. That decides what your first build has to be capable of measuring.
A first version that cannot produce a decision is not an MVP, it is a prototype with a payment form attached.
What is the first version actually for?
To find out whether anyone repeats the core action without being asked.
Not to be impressive. Not to be complete. To generate one piece of evidence you cannot get from conversation, which is whether a stranger comes back and does the thing again.
Gustaf Alstromer's guidance in the Y Combinator library is direct about this: identify your value metric, measure repeat usage, and look for the retention curve to flatten (YC, Growth for Startups). A flat curve means a group of people kept using it. That is the signal. Signup counts are not.
So the design constraint on version one is unusual: it must be capable of producing a retention curve. That rules out a landing page with a waitlist, and it rules out a demo you drive yourself.
How do you choose the one thing to build?
Write your core claim as a sentence, then build only the path that tests it.
The sentence has a shape: for [specific person] with [specific recurring problem], we [do the thing] so they get [specific outcome] instead of [what they do today].
Once that sentence exists, most of your feature list becomes obviously deferrable. The test is brutal and simple: if this feature were missing, could a user still get the outcome once? If yes, it waits.
Usually essential in v1 | Usually deferrable, however uncomfortable |
|---|---|
The single path to the core outcome | Settings, preferences, customisation |
Whatever proves the output is trustworthy | Onboarding tours and empty states |
A way for a stranger to reach the outcome unaided | Integrations, team seats, permissions |
Instrumentation on the core action | Billing tiers, annual plans, coupon logic |
Enough design that it is not confusing | A complete design system |
The right-hand column is where most first builds go to die, because each item is individually reasonable and collectively it is a year.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What does "enough design" mean at this stage?
Enough that nobody blames the interface for the answer you get.
This is the part founders either over-invest in or skip entirely, and both are expensive in the same way: they contaminate the experiment.
Skip design and users bounce off confusion, and you conclude the idea is wrong when the wireframe was wrong. Over-invest and you spend eight weeks on a design system for a product whose core claim has not been tested.
The bar is: a stranger can reach the core outcome without you sitting next to them, and it looks credible enough that they trust the output. In fintech and AI that trust threshold is genuinely higher, because people will not act on a number or a recommendation from something that looks provisional. That is the honest reason design is not cosmetic at this stage.
It is also why our own Zero to One engagement is four weeks and includes a brand, the key flows designed, and a landing page, rather than a full build. Those are the pieces that decide whether the test is clean.
What should you instrument before launch?
The core action, the step before it, and the return.
Three events, decided before you write the code, because retrofitting analytics onto a live product is how six months of data becomes unusable.
1. Reached the core outcome. The single moment your claim is about. This is your activation event, and it is worth defining it in one sentence before launch rather than after. 2. The step immediately before it. Without this you can see that people did not arrive, but never where they stopped. 3. Returned and did it again. The only event that produces a retention curve, and therefore the only one that answers the real question.
Everything else can wait. Three well-chosen events beat forty badly named ones, and forty badly named ones is what you get if you defer the decision until after launch.
When do you know it is working?
When a cohort of strangers keeps coming back without you prompting them.
Not when people say they like it. Not when signups climb after a launch post. Those are both compatible with a product nobody needs.
Dalton Caldwell's account in the YC library of Socialcam is the useful cautionary version: millions of downloads and retention that did not hold (YC, The Real Product-Market Fit). Enormous top-of-funnel numbers alongside no underlying business.
The honest read on your own curve, once you have one:
Flattens after the initial drop. You have something. Now find out who those people are and get more of them.
Decays toward zero, every cohort. The claim is wrong, or the product does not deliver it yet. More acquisition makes this worse and more expensive.
Too few users to tell. Not a signal. Keep going until a cohort is big enough to read.
The last one catches people out. A flat line drawn through eleven users is a picture of nothing, and it is very easy to see what you want in it. Once you do have a readable curve, the pattern in who leaves is rarely random.
The reason to be disciplined about all of this early is arithmetic. Every week spent building past the point where the answer was available is a week of runway spent buying no information. The 95% mostly did not run out of ideas. They ran out of money finding out.
WHAT NEXT
Want this fixed in your product, not just explained?
Sep 18, 2026
By Victor Teran
What to Build First When You Have an Idea and No Users
Only 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Most of the other 95% did not fail at building. They failed at choosing what to build first, which is a different and much cheaper mistake to avoid.
Build
Zero to One
Validation
The first version of a product is not a small version of the finished one. It is an argument, and the only thing it has to do is make that argument checkable by someone who is not you.
That framing changes what goes in it. Founders default to building the thing they can describe, which is usually the full workflow, because that is what lives in their head. What gets you to a real answer is smaller, stranger, and often embarrassing to show.
RevenueCat's data across more than 115,000 apps puts the odds plainly: 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Very little of that gap is engineering talent.
Key takeaways
Build the single path that proves your core claim, not the product that surrounds it. Everything else is deferrable.
Pick the one user action that would tell you the idea works, and design backwards from it.
Y Combinator's own framing is that retention, not signups, is the evidence of product-market fit. That decides what your first build has to be capable of measuring.
A first version that cannot produce a decision is not an MVP, it is a prototype with a payment form attached.
What is the first version actually for?
To find out whether anyone repeats the core action without being asked.
Not to be impressive. Not to be complete. To generate one piece of evidence you cannot get from conversation, which is whether a stranger comes back and does the thing again.
Gustaf Alstromer's guidance in the Y Combinator library is direct about this: identify your value metric, measure repeat usage, and look for the retention curve to flatten (YC, Growth for Startups). A flat curve means a group of people kept using it. That is the signal. Signup counts are not.
So the design constraint on version one is unusual: it must be capable of producing a retention curve. That rules out a landing page with a waitlist, and it rules out a demo you drive yourself.
How do you choose the one thing to build?
Write your core claim as a sentence, then build only the path that tests it.
The sentence has a shape: for [specific person] with [specific recurring problem], we [do the thing] so they get [specific outcome] instead of [what they do today].
Once that sentence exists, most of your feature list becomes obviously deferrable. The test is brutal and simple: if this feature were missing, could a user still get the outcome once? If yes, it waits.
Usually essential in v1 | Usually deferrable, however uncomfortable |
|---|---|
The single path to the core outcome | Settings, preferences, customisation |
Whatever proves the output is trustworthy | Onboarding tours and empty states |
A way for a stranger to reach the outcome unaided | Integrations, team seats, permissions |
Instrumentation on the core action | Billing tiers, annual plans, coupon logic |
Enough design that it is not confusing | A complete design system |
The right-hand column is where most first builds go to die, because each item is individually reasonable and collectively it is a year.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What does "enough design" mean at this stage?
Enough that nobody blames the interface for the answer you get.
This is the part founders either over-invest in or skip entirely, and both are expensive in the same way: they contaminate the experiment.
Skip design and users bounce off confusion, and you conclude the idea is wrong when the wireframe was wrong. Over-invest and you spend eight weeks on a design system for a product whose core claim has not been tested.
The bar is: a stranger can reach the core outcome without you sitting next to them, and it looks credible enough that they trust the output. In fintech and AI that trust threshold is genuinely higher, because people will not act on a number or a recommendation from something that looks provisional. That is the honest reason design is not cosmetic at this stage.
It is also why our own Zero to One engagement is four weeks and includes a brand, the key flows designed, and a landing page, rather than a full build. Those are the pieces that decide whether the test is clean.
What should you instrument before launch?
The core action, the step before it, and the return.
Three events, decided before you write the code, because retrofitting analytics onto a live product is how six months of data becomes unusable.
1. Reached the core outcome. The single moment your claim is about. This is your activation event, and it is worth defining it in one sentence before launch rather than after. 2. The step immediately before it. Without this you can see that people did not arrive, but never where they stopped. 3. Returned and did it again. The only event that produces a retention curve, and therefore the only one that answers the real question.
Everything else can wait. Three well-chosen events beat forty badly named ones, and forty badly named ones is what you get if you defer the decision until after launch.
When do you know it is working?
When a cohort of strangers keeps coming back without you prompting them.
Not when people say they like it. Not when signups climb after a launch post. Those are both compatible with a product nobody needs.
Dalton Caldwell's account in the YC library of Socialcam is the useful cautionary version: millions of downloads and retention that did not hold (YC, The Real Product-Market Fit). Enormous top-of-funnel numbers alongside no underlying business.
The honest read on your own curve, once you have one:
Flattens after the initial drop. You have something. Now find out who those people are and get more of them.
Decays toward zero, every cohort. The claim is wrong, or the product does not deliver it yet. More acquisition makes this worse and more expensive.
Too few users to tell. Not a signal. Keep going until a cohort is big enough to read.
The last one catches people out. A flat line drawn through eleven users is a picture of nothing, and it is very easy to see what you want in it. Once you do have a readable curve, the pattern in who leaves is rarely random.
The reason to be disciplined about all of this early is arithmetic. Every week spent building past the point where the answer was available is a week of runway spent buying no information. The 95% mostly did not run out of ideas. They ran out of money finding out.
WHAT NEXT
Want this fixed in your product, not just explained?
Sep 18, 2026
By Victor Teran
What to Build First When You Have an Idea and No Users
Only 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Most of the other 95% did not fail at building. They failed at choosing what to build first, which is a different and much cheaper mistake to avoid.
Build
Zero to One
Validation
The first version of a product is not a small version of the finished one. It is an argument, and the only thing it has to do is make that argument checkable by someone who is not you.
That framing changes what goes in it. Founders default to building the thing they can describe, which is usually the full workflow, because that is what lives in their head. What gets you to a real answer is smaller, stranger, and often embarrassing to show.
RevenueCat's data across more than 115,000 apps puts the odds plainly: 4.6% of newly launched subscription apps reach $10,000 in monthly recurring revenue within two years. Very little of that gap is engineering talent.
Key takeaways
Build the single path that proves your core claim, not the product that surrounds it. Everything else is deferrable.
Pick the one user action that would tell you the idea works, and design backwards from it.
Y Combinator's own framing is that retention, not signups, is the evidence of product-market fit. That decides what your first build has to be capable of measuring.
A first version that cannot produce a decision is not an MVP, it is a prototype with a payment form attached.
What is the first version actually for?
To find out whether anyone repeats the core action without being asked.
Not to be impressive. Not to be complete. To generate one piece of evidence you cannot get from conversation, which is whether a stranger comes back and does the thing again.
Gustaf Alstromer's guidance in the Y Combinator library is direct about this: identify your value metric, measure repeat usage, and look for the retention curve to flatten (YC, Growth for Startups). A flat curve means a group of people kept using it. That is the signal. Signup counts are not.
So the design constraint on version one is unusual: it must be capable of producing a retention curve. That rules out a landing page with a waitlist, and it rules out a demo you drive yourself.
How do you choose the one thing to build?
Write your core claim as a sentence, then build only the path that tests it.
The sentence has a shape: for [specific person] with [specific recurring problem], we [do the thing] so they get [specific outcome] instead of [what they do today].
Once that sentence exists, most of your feature list becomes obviously deferrable. The test is brutal and simple: if this feature were missing, could a user still get the outcome once? If yes, it waits.
Usually essential in v1 | Usually deferrable, however uncomfortable |
|---|---|
The single path to the core outcome | Settings, preferences, customisation |
Whatever proves the output is trustworthy | Onboarding tours and empty states |
A way for a stranger to reach the outcome unaided | Integrations, team seats, permissions |
Instrumentation on the core action | Billing tiers, annual plans, coupon logic |
Enough design that it is not confusing | A complete design system |
The right-hand column is where most first builds go to die, because each item is individually reasonable and collectively it is a year.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What does "enough design" mean at this stage?
Enough that nobody blames the interface for the answer you get.
This is the part founders either over-invest in or skip entirely, and both are expensive in the same way: they contaminate the experiment.
Skip design and users bounce off confusion, and you conclude the idea is wrong when the wireframe was wrong. Over-invest and you spend eight weeks on a design system for a product whose core claim has not been tested.
The bar is: a stranger can reach the core outcome without you sitting next to them, and it looks credible enough that they trust the output. In fintech and AI that trust threshold is genuinely higher, because people will not act on a number or a recommendation from something that looks provisional. That is the honest reason design is not cosmetic at this stage.
It is also why our own Zero to One engagement is four weeks and includes a brand, the key flows designed, and a landing page, rather than a full build. Those are the pieces that decide whether the test is clean.
What should you instrument before launch?
The core action, the step before it, and the return.
Three events, decided before you write the code, because retrofitting analytics onto a live product is how six months of data becomes unusable.
1. Reached the core outcome. The single moment your claim is about. This is your activation event, and it is worth defining it in one sentence before launch rather than after. 2. The step immediately before it. Without this you can see that people did not arrive, but never where they stopped. 3. Returned and did it again. The only event that produces a retention curve, and therefore the only one that answers the real question.
Everything else can wait. Three well-chosen events beat forty badly named ones, and forty badly named ones is what you get if you defer the decision until after launch.
When do you know it is working?
When a cohort of strangers keeps coming back without you prompting them.
Not when people say they like it. Not when signups climb after a launch post. Those are both compatible with a product nobody needs.
Dalton Caldwell's account in the YC library of Socialcam is the useful cautionary version: millions of downloads and retention that did not hold (YC, The Real Product-Market Fit). Enormous top-of-funnel numbers alongside no underlying business.
The honest read on your own curve, once you have one:
Flattens after the initial drop. You have something. Now find out who those people are and get more of them.
Decays toward zero, every cohort. The claim is wrong, or the product does not deliver it yet. More acquisition makes this worse and more expensive.
Too few users to tell. Not a signal. Keep going until a cohort is big enough to read.
The last one catches people out. A flat line drawn through eleven users is a picture of nothing, and it is very easy to see what you want in it. Once you do have a readable curve, the pattern in who leaves is rarely random.
The reason to be disciplined about all of this early is arithmetic. Every week spent building past the point where the answer was available is a week of runway spent buying no information. The 95% mostly did not run out of ideas. They ran out of money finding out.
WHAT NEXT