DEV Community: Spencer Claydon

You Vibe-Coded an MVP. Now What?

Spencer Claydon — Thu, 03 Sep 2026 21:00:30 +0000

So you opened Lovable on a Friday night, described the thing you'd been thinking about for months, and by Sunday you had a working app with auth, a database, and a landing page. It deploys. It has a URL. You've shown it to four friends and they all said "oh that's sick."

Now what?

Here's the uncomfortable part. The weekend you just spent was the easy weekend. Everything that determines whether this becomes a company happens after the build, and almost none of it can be prompted into existence. A vibe coded MVP is a starting line that a lot of founders mistake for a finish line, and the gap between those two things is where most of these projects quietly die.

Let's talk about what actually comes next.

What does "you vibe-coded an MVP" actually mean in 2026?

It means you described a product in plain English to an AI tool and got back real, deployable source code rather than a locked template. That's the difference from the old no-code era: the output is an actual codebase you can export, modify, and eventually hand to an engineer.

Andrej Karpathy coined the term in a February 2025 post, and within about a year it went from weekend curiosity to the default way early software gets made. The numbers back that up. YC managing partner Jared Friedman said that for a quarter of the W25 batch, 95% or more of the codebase was AI-generated. Lovable went from roughly $100M in annualized revenue to about $400M in eight months. Bolt.new hit $40M ARR five months after launch.

So you're not doing anything unusual. You're doing what a very large number of people did last weekend. That's the whole problem, and it's also the first thing to internalize.

Why does building an MVP no longer prove anything?

Because supply exploded and demand didn't move. Shipping code used to be a costly signal that you were serious. It isn't anymore, so it no longer separates you from anyone.

The clearest evidence comes from Apple's own numbers. App Store submissions hit 235,800 in Q1 2026, an 84% year-over-year jump and the biggest single-quarter surge in a decade. Review times that used to run 24 to 48 hours stretched to as long as 30 days at the peak. Meanwhile, a Financial Times chart drawing on research by Demirer and colleagues showed iOS releases climbing about 80% from 2024 to early 2026 while the number of apps with meaningful usage stayed essentially flat. Flat. Not slower growth. Flat.

And the money is even more concentrated than the attention. The top 1% of apps took 92.2% of all in-app purchase revenue in 2025, roughly $154 billion against $13.1 billion split among everyone else.

Read those two facts together and the conclusion is hard to dodge. We automated app creation without improving app discovery. Your build is no longer the scarce thing. Someone caring is.

I've watched this pattern play out with founders over and over. They ship, they post it on X, they get 40 likes and 3 signups, and then they go build more features because building is the part that feels like progress. Six weeks later they have a much better product that still nobody uses.

Is your vibe-coded MVP actually safe to put in front of customers?

Probably not without a review, and this is the least fun paragraph in this article. Security is the thing AI-generated code is measurably worst at, and it's also the thing that founders skip because no customer ever asked for it.

The data here is pretty grim. Escape.tech scanned more than 1,400 production vibe-coded applications and found 65% had security issues, with 58% containing at least one critical vulnerability. That scan turned up over 400 exposed secrets and 175 instances of exposed personal data. A separate Tenzai review of 15 production apps built with major AI coding tools found that every single one lacked CSRF protection and had no security headers configured. Veracode's testing across more than 100 models found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability.

You don't need to become a security engineer this week. But you do need to do three cheap things before you take real user data:

Check that your API keys and database credentials aren't sitting in the frontend. This is the single most common failure and it takes ten minutes to check.
Turn on row-level security if you're on Supabase or anything similar. The default in a lot of AI-generated projects is a wide-open table.
Run a free scanner against your deployed URL. Even a basic pass will catch missing security headers.

Then set yourself a trigger: once you're at roughly $10K MRR, or the moment you store anything sensitive, pay someone to audit it properly. Not before. But not never.

How do you find out whether anyone actually wants this?

You go talk to people who have the problem, and you do it before you write another line of prompt. The uncomfortable truth is that a working demo makes this harder, not easier, because now you're tempted to show instead of ask.

Here's the sequence that works. Find 15 people who plausibly have the problem your app solves. Not friends. Not other founders. People in the actual situation. Ask them how they handle it today, what they've tried, what it costs them in time or money, and what they'd have to see to switch. Do not show them your app until the last five minutes of the call.

The signal you're listening for is specificity. "Yeah that sounds useful" means nothing. "I currently do this in a spreadsheet every Monday and it takes me two hours" means something. If you can't get anyone to describe a concrete, recurring, expensive version of the problem, you built a solution to a problem that only exists in your head. That's fixable, but only if you find out in week one instead of month six. Our guide to customer discovery interviews covers the question structure in more detail.

This is also the point where it helps to write down what you're actually claiming: who the customer is, what they're doing instead, and why your thing wins. You can do that in a Google Doc, in Notion, or in a structured planning workspace like Foundra that walks first-time founders through the positioning and competitive sections. The format matters less than the fact that it exists outside your head where you can be wrong about it in writing.

What's the fastest way to get your first 10 users?

Manually, one at a time, in places where the problem is already being discussed. Not a launch. Not a waitlist. Ten conversations that end with someone using the thing.

The instinct after building is to do a big reveal: Product Hunt, a launch tweet, maybe a Show HN. Resist that for now. A launch to an audience of zero converts to roughly zero, and you only get one first impression on those platforms. Save it until you have something people already like.

What works instead is unglamorous:

Answer questions in the subreddit, Discord, or Slack where your users already complain about this problem. Be useful ten times before you mention your product once.
DM people who have publicly described the problem. Reference the specific thing they said. Offer to set it up for them yourself.
Onboard your first users personally, over a call, while watching them use it. You will learn more in three of these than in three months of analytics.
Go where the incumbent is failing. Every tool has a support forum full of frustrated people.

Ten users you recruited by hand teach you more than a thousand who bounced off your landing page, and they're the only realistic path to knowing whether the thing works. We go deeper on this in how to find your first customers.

Should you rebuild the codebase or keep shipping?

Keep shipping, until one of three specific things happens. Rewriting a working prototype because it's "messy" is one of the most expensive mistakes a first-time founder can make, and messy code that has users beats clean code that doesn't.

That said, the debt is real and it compounds. A study of 8.1 million pull requests found technical debt rising 30% to 41% after teams adopted AI coding tools. The wall usually shows up in the last 20% of the build, where the app demos beautifully but falls over on edge cases and you're burning credits in debugging loops trying to close the gap.

Bring in real technical help when:

You're storing data whose loss or exposure would end the company.
You've spent more than two weeks unable to fix a bug you can't understand.
An investor or enterprise buyer is about to run technical diligence.

Until then, ship. And when you do bring someone in, bring them in as a reviewer and refactorer rather than a from-scratch rebuilder. Most vibe-coded MVPs need hardening, not replacement.

What does a sane 30-day plan look like after you've shipped?

Week one is conversations, not code. Weeks two and three are hand-recruited users and fixing what breaks in front of them. Week four is deciding whether the signal is real.

Here's roughly how I'd spend it:

Days	Focus	What "done" looks like
1 to 7	Customer discovery	15 interviews, written notes, a one-paragraph problem statement you'd defend
8 to 14	Security pass and first 5 users	Keys secured, RLS on, 5 people onboarded by you personally
15 to 21	Next 5 users and fast fixes	10 total users, every reported bug either fixed or explicitly ignored
22 to 30	Read the signal	Retention after 2 weeks, plus a keep/pivot/kill call you write down

Notice what isn't on there. No redesign. No new features unless a paying-adjacent user asked twice. No launch. The plan is deliberately boring because the failure mode you're guarding against is exciting: building more, faster, in the wrong direction.

At the end of 30 days you want an honest answer to one question. Of the ten people you personally onboarded, how many came back without you nudging them? If it's three or more, you have something worth pushing on. If it's zero, the app was never the problem, and no amount of additional prompting will fix it. A smoke test on a different angle costs you a day and might save you a year.

Key takeaways

Vibe coding removed the build constraint, not the demand constraint. iOS releases rose about 80% from 2024 to early 2026 while apps with real usage stayed flat.
Your MVP existing proves nothing to anyone, including you. A quarter of YC's W25 batch had codebases that were 95%+ AI-generated, so "I built it" is no longer a differentiator.
Do a cheap security pass before real users: no keys in the frontend, row-level security on, a free scanner run. 65% of scanned production vibe-coded apps had security issues.
Talk to 15 people who have the problem before writing another prompt, and don't show them the app until the last five minutes.
Recruit your first 10 users by hand, one at a time. Save your launch for when you have traction, not instead of it.
Don't rebuild a working prototype. Bring in technical help for hardening when you're storing sensitive data, stuck on a bug for two weeks, or facing diligence.
Judge the whole thing on one number at day 30: how many of your ten came back on their own.

FAQ

Is a vibe-coded MVP good enough to raise money on?

For pre-seed, usually yes, if it has users. Investors care much more about whether anyone is using the thing than about how it was built. What does hurt you is technical diligence at seed and later, where a codebase nobody on the team can explain becomes a real objection. The fix is having a technical person who has actually read the code, not rewriting it preemptively.

How long should I keep iterating before I decide the idea isn't working?

Give it 30 days of real distribution effort, not 30 days of building. The clock should start when you begin recruiting users, not when you start coding. If ten hand-onboarded users produce zero unprompted returns after two weeks, that's a signal worth acting on. Most founders get this backwards and spend six months building before they spend six days selling.

Do I need a technical co-founder if the AI built the whole thing?

Not immediately, and possibly not ever if you stay narrow. Founders who do fine without one tend to keep scope tight enough that the AI-generated code never has to handle the complexity where things break. You'll want technical help before you store sensitive data, before enterprise diligence, and any time you've been stuck on the same bug for weeks.

Should I launch on Product Hunt right after building?

No. Launch when you have users who like the product, because you get one good shot and a launch to nobody converts to nobody. The "just build an agent" launch stopped working on Product Hunt around April 2026 anyway; products that solve one specific job inside a workflow people already have are what get traction now.

What's the biggest mistake founders make after vibe-coding an MVP?

Building more. It's the only activity that feels like progress while requiring no exposure to rejection, so it's what people default to when they're scared the answer is no. If your instinct after reading this is to go add a feature, that instinct is the thing to be suspicious of.

How to Run a Cohort Analysis for Your Startup

Spencer Claydon — Wed, 02 Sep 2026 15:08:44 +0000

A founder I talked to last year was convinced his product had turned a corner. Retention had climbed from 41% to 46% over five months. He put it in his investor update. He raised on it.

Then someone asked him to break it out by signup month.

Turns out retention hadn't improved at all. His January cohort was still retaining at 38%. His May cohort was retaining at 37%. What changed was the mix: he'd been pouring money into a paid channel that brought in a small number of very sticky enterprise trials, and those users were dragging the blended average up while the core product got no better. He'd raised money on an accounting artifact.

That's what a cohort analysis is for. It's the difference between knowing your average and knowing whether the thing you built last quarter actually worked.

What is a cohort analysis, and why does the blended number lie?

A cohort analysis groups users by something they share, usually the month they signed up, then tracks each group separately over time instead of averaging them together. The blended number lies because it mixes users who joined last week with users who joined two years ago, so a change in acquisition volume looks identical to a change in product quality.

Picture two companies. Both report 60% monthly retention. Company A has held every cohort at 60% for eighteen months. Company B's oldest cohorts retain at 25% and its newest retain at 85%, and the newest cohorts are large enough to pull the average up. Same headline number, completely different businesses. One is stable and one is either fixing itself fast or about to get a nasty surprise when growth slows.

You can't tell those apart from a single percentage. You can tell instantly from a cohort table.

The general principle here: any metric that averages across time will hide the thing you most want to know, which is whether time is making you better.

What kinds of cohorts should a startup actually track?

Start with acquisition cohorts grouped by signup month, then add one behavioural cohort and one channel cohort. Three cuts is plenty for a company under 1,000 users, and more than three tends to produce cells with four people in them, which is noise wearing a suit.

Acquisition cohorts group by when someone joined. This is your default and the one that answers "is the product getting better."

Behavioural cohorts group by what someone did. Everyone who connected an integration in week one. Everyone who invited a teammate. Everyone who hit the aha moment, whatever yours is. These are how you find the action that predicts retention, which is the single most useful thing early analytics can give you.

Channel or source cohorts group by where someone came from. Product Hunt traffic, organic search, a specific newsletter sponsorship. This is what my founder friend needed and didn't have.

Plan or price cohorts matter once you have more than one tier. Free users and $99 users churn for different reasons and blending them tells you nothing actionable about either.

If you're pre-launch or in your first hundred users, just do signup month. Adding dimensions to a dataset that small is a way to feel busy.

How do you build a cohort analysis in a spreadsheet?

You need three columns to start: user ID, signup date, and a row for every month that user was active. From there it's a pivot table and about forty minutes.

Here's the actual sequence:

Label each activity row with the user's cohort month. If someone signed up on 14 March, every row for them gets tagged 2026-03, forever.
Add a period number. This is months elapsed between the cohort month and the activity month. Signup month is period 0, the next month is period 1, and so on.
Pivot. Cohort month down the rows, period number across the columns, count of distinct user IDs in the cells. You now have a triangle: older cohorts have more columns filled in than newer ones.
Divide by period 0. Every cell divided by the first cell in its row turns raw counts into retention percentages. Period 0 is always 100%.
Add a three-colour conditional format. Red through green. This is not decoration. The pattern is the finding, and your eye picks up a colour gradient about ten times faster than a grid of numbers.

That's it. You do not need a data warehouse for this. You need an export of your users table and an export of whatever event counts as "active," which for most early products is a login or a single core action.

If you're building financial projections off this, the cohort table is where your retention assumption should come from rather than a number you picked because it felt reasonable. Foundra's planning workspace and most decent financial modelling templates will ask you for a monthly retention rate; feeding it a cohort-derived number instead of a guess is the difference between a model and a wish. Same applies to any of the free calculators at foundra.ai/tools/ that take churn as an input.

How do you read a cohort retention curve?

Plot each cohort as a line, period on the x-axis and retention on the y-axis, and look at the shape rather than the level. There are three shapes and each one means something specific.

It declines forever. The line keeps sloping down and shows no sign of levelling. This means nobody has found lasting value yet. Not a subset, nobody. The honest read on a perpetually declining curve is that your foundational users haven't arrived, either because the product doesn't solve the problem yet or because you're acquiring the wrong people. Growth spend at this stage fills a bucket with a hole in it.

It flattens above zero. The line drops, then levels out and holds. This is the good one. A flattened curve means some meaningful slice of every cohort found enough value to stay indefinitely, and that slice is your real market. Most people who write seriously about product-market fit treat a flattened retention curve as the clearest behavioural evidence there is, more reliable than survey scores or revenue, because it's users voting with their time rather than their opinions.

It smiles. The line drops, flattens, then curves back up as churned users return and existing users expand. This is rare and it's the strongest signal in the set. A smiling curve is what eventually produces net revenue retention above 100%, because it means churn isn't permanent.

For rough calibration: top-quartile consumer apps see day-30 retention in the 25% to 40% range and flatten somewhere around day 60 to 90. Strong B2B SaaS holds annual logo retention above 90%. But be careful with benchmarks at your stage. Directional improvement across cohorts matters more than hitting somebody else's number, and an early-stage company comparing itself to a public SaaS benchmark is comparing a sapling to a forest.

What do you do when the curve never flattens?

Segment harder before you conclude the product is dead. A curve that declines in aggregate very often contains one segment that flattens beautifully, and finding that segment is the whole job.

Split your worst-looking cohort by anything you have: company size, use case, acquisition channel, whether they completed onboarding, what they did in the first 48 hours. You're looking for a subgroup whose line goes flat. If you find one, you've found your beachhead, and the strategic move is usually to narrow, not to add features.

If you segment six ways and every line still points at zero, that's real information too. It means the problem you picked isn't painful enough or your solution isn't better enough, and more features won't fix either. That's a pivot conversation, and cohort data is one of the few things that makes that conversation less about ego and more about evidence.

How do you run a cohort analysis on revenue instead of users?

Swap the count of users for the sum of revenue in each cell, keep everything else identical. The resulting table shows net revenue retention by cohort, and it can look wildly different from your user retention table.

This is where a lot of B2B startups find good news they didn't know they had. You can lose 40% of the logos in a cohort and still be at 110% revenue retention if the survivors expand. You can also find bad news: cohorts where revenue holds up only because two large accounts are carrying a hundred small ones.

A blended NRR figure is especially prone to hiding this. Your best cohorts can be expanding at 130% while your worst contract at 70%, and the two cancel into something that looks like flat stability. For context on where you'd be aiming eventually, 2026 benchmark data puts median NRR for private SaaS at roughly 101%, with SMB-focused companies near 97% and enterprise-focused ones around 118%. The segment differences are large enough that a single blended target is close to meaningless.

If you're already tracking churn rate and MRR, the revenue cohort table is the natural next artifact. It's the one that tells you whether your churn number is a product problem or a customer-selection problem.

Which mistakes make a cohort analysis useless?

The four that show up most: cohorts too small to mean anything, the wrong definition of "active," reading incomplete cohorts as if they were finished, and building the table without a decision attached to it.

Cohorts under about 30 users produce noise. One person churning moves the number by three points. If you're at 200 total users, use quarterly cohorts instead of monthly ones and accept the lower resolution.

"Active" needs to mean something. A login is a weak definition for most products. Pick the action that represents someone getting value: sent a message, created a document, ran the report. If you're not sure, run the table twice with two definitions and see which one produces a curve that separates good cohorts from bad ones.

Your newest cohorts are not underperforming. They just have fewer periods of data. Compare period 3 to period 3, never period 3 to period 12, and grey out the cells that haven't happened yet so nobody in the room reads the triangle wrong.

Decide what you'd change first. Before you build the table, write down the decision it's meant to inform. Should we keep spending on this channel. Did the onboarding rewrite work. Do enterprise trials retain better than self-serve. A cohort table built without a question becomes a slide, and slides don't change anything.

One more, less obvious: watch for the 2026 version of vanity signups. A lot of AI-adjacent products are pulling large volumes of curious users who try the thing once, and those users flood period 0, crush your retention percentages, and tell you nothing. If a chunk of your traffic is tourists, cohort them separately or your denominator will make a healthy product look broken.

Which tools should you use, and when?

Use a spreadsheet until it hurts, then use a free product analytics tier. Paying for analytics before you have a retention question you can't answer in Excel is a common early mistake.

Stage	What to use	Why
Pre-launch to ~500 users	Google Sheets or Excel	Forty minutes, full control, forces you to understand your own data
~500 to a few thousand	PostHog, Mixpanel, or Amplitude free tiers	Mixpanel's free tier covers 1M events a month; Amplitude's starter plan covers 10K monthly tracked users; PostHog can be self-hosted
Revenue cohorts, any stage	Stripe Sigma or your billing export plus a pivot table	Billing data is cleaner than event data and you already have it

Amplitude and Mixpanel both do behavioural cohorting well and will save you real time once you're asking more than two questions a week. PostHog suits engineering-led teams that want the data in their own infrastructure. Google Analytics 4 has cohort reports and they're serviceable for web funnels, less so for product usage.

The tool is not the hard part. Deciding what "active" means and being willing to look at an ugly curve is the hard part.

Key takeaways

A blended retention number can move purely because your acquisition mix changed. Cohorts separate product improvement from mix shift.
Start with acquisition cohorts by signup month. Add behavioural and channel cohorts once you have the volume to support them.
The shape matters more than the level: declining forever means no fit yet, flattening above zero means real fit, and a smiling curve is the strongest signal you can get.
Under about 30 users per cohort, switch to quarterly grouping or accept that you're reading noise.
Run the same table on revenue as well as users. The two often disagree, and the disagreement is usually the insight.
Write down the decision before you build the table. Otherwise you've made a slide.

FAQ

How many users do I need before a cohort analysis is worth doing?
Roughly 30 per cohort for the numbers to be stable. Below that, group by quarter instead of month, or just read the raw counts and skip the percentages. Percentages on small numbers create false precision.

How often should I run one?
Monthly is right for most early startups. Weekly cohorts are useful if your product has a daily-use pattern and you're actively iterating on onboarding, but monthly matches the cadence of most decisions you'll actually make.

What's the difference between a cohort analysis and a churn rate?
Churn rate is a single number for a period. A cohort analysis is churn broken out by group and tracked over time. Churn tells you how much you lost last month; cohorts tell you whether that number is improving and for whom.

Can I do a cohort analysis before launch?
Not on retention, since you need usage data. But you can cohort waitlist signups by source and track what percentage of each source converts when you open the doors, which is a useful early read on channel quality.

Does a flat retention curve prove product-market fit?
It's the strongest single piece of behavioural evidence, but it isn't proof on its own. A curve that flattens at 4% means a tiny group loves you. You need the curve to flatten and the flat portion to be large enough to build a business on, plus month-over-month growth in new cohorts of similar quality.

Should I include free users in my cohorts?
Track them separately. Free and paid users have different intent and different reasons to leave, and mixing them makes both curves harder to read. If you have a free tier, the interesting cohort question is usually what percentage of each free cohort converts by period 3.

How to Build a Startup Advisory Board That Works

Spencer Claydon — Tue, 01 Sep 2026 15:13:53 +0000

A founder I know spent four months assembling what he called a "killer advisory board." Six names, two of them recognisable. He put their headshots on the website and gave away 4.5% of his company.

Eighteen months later he'd had three conversations with any of them. One never replied after the paperwork was signed. The equity kept vesting anyway, because nobody had written down what the advisors were supposed to do or what happened if they didn't do it.

That's the default outcome. A startup advisory board is one of those things every first-time founder is told to build, with almost no guidance on how, so most end up with a logo wall instead of a working relationship. The equity is real. The advice usually isn't.

The version that works is worth a lot, though. A single introduction from the right person can compress six months of cold outreach into one call. This is a guide to getting that version: who to ask, what to pay, what to put in writing, and how to run it so it's still useful in year two.

What is a startup advisory board, and how is it different from a board of directors?

An advisory board is a group of people who give you advice and have no power over your company. A board of directors has legal authority: they vote on major decisions, they owe fiduciary duties, and they can fire you.

That difference is the whole point. Your advisory board members carry no fiduciary duty, no voting rights, and no personal legal liability for what the company does. They talk, you decide. Nobody at the table can override you.

Which cuts both ways. It makes an advisory board cheap and low-risk to set up, so you can do it pre-seed with a one-page document. It also means accountability runs entirely on goodwill. A director who ignores the company can be sued. An advisor who ignores you just stops answering. So everything useful about a startup advisory board has to be engineered in on purpose.

One more distinction. Advisors are not mentors. A mentor is informal, no equity and no obligations, and plenty of founders would be better served by three good mentors than a formal board. If you're unsure which you need, start with mentors. You can always formalise later. You can't un-grant equity.

Do first-time founders actually need advisors?

Sometimes. You need advisors when being wrong is expensive and slow to discover. You don't need them for decisions you can test yourself in a week.

Here's a rough filter. If the question is "will people want this," go talk to customers. That's a validation problem, and no amount of pedigree substitutes for twenty conversations with real users. But if the question is "how does enterprise procurement actually work at a hospital system," you won't figure that out by experimenting. Somebody's already paid that tuition. Buy it from them.

The research is split on whether advisors deliver. One industry survey found 83% of founders believed advisors added value, with the other 17% describing it as a waste of equity and time. That 17% isn't wrong about their own experience. They mostly built the logo wall.

Where advisors earn their equity:

Domain knowledge you can't buy. Regulatory paths, procurement cycles, how a specific industry buys.
Network access. Warm introductions to customers, hires, and investors. The highest-value thing most advisors provide.
Pattern recognition on stage-specific mistakes. Someone who has hired their first ten people knows which of your five hiring plans is the dumb one.
Credibility with a specific audience, where the advisor will vouch for you rather than just be listed.

Where they don't: general encouragement, opinions about your product your users could give you for free, and strategy advice from people whose experience comes from a company 400 times your size. Advice from a Fortune 500 executive to a 6-person startup is often actively harmful, because the constraints don't transfer.

How do you find the right advisors for your startup?

Start from a specific problem, not a wish list of impressive people. Write down the two or three questions currently blocking you, then find people who have answered exactly those questions before.

The Founder Institute, which has run this process with tens of thousands of founders, recommends a sequence worth copying almost exactly:

Build a target list of 10 to 15 people whose experience maps to your actual blockers. Not famous. Relevant.
Find a warm path through LinkedIn and Crunchbase. A shared connection converts far better than a cold message.
Send a five-sentence email asking for a call or coffee. Not a pitch. A specific question.
Make a small request before any conversation about equity. One introduction, or thirty minutes on a specific problem.
Watch what happens. Did they follow through? Did they do it well? Did they follow up unprompted?
Only then formalise. Their recommendation is at least one month and eight hours of interaction first.

That fourth step is where most founders skip ahead and regret it. Chemistry and reputation are different things. Some brilliant operators are terrible advisors because they can't context-switch down to your stage, and you only find that out by working together on something small.

A word on the person you actually want. The best advisor for a pre-seed company is usually someone three to five years ahead of you, not thirty. They remember the problem. Their contacts will take a meeting with a company your size. And they'll answer your text on a Sunday, which the famous person won't.

How much equity should you give a startup advisory board?

Between 0.1% and 1% per advisor, depending on your stage and how much they actually do. Total advisor pool: aim for 1% to 3%. Five percent is the outer edge, and if you're above it something has gone wrong.

The most widely used reference is the FAST Agreement, the Founder/Advisor Standard Template published free by the Founder Institute since 2011. Version 3 came out in July 2026 and simplified it to two levels of engagement across three stages:

Engagement level	Pre-seed	Seed	Series A
Standard: monthly meetings	0.50%	0.25%	0.10%
Expert: adds introductions and project work	1.00%	0.75%	0.50%

Read that table as a ceiling, not a starting bid. The numbers scale down as you raise because the equity is worth more and the risk is lower. An advisor who joins pre-seed is taking a real bet. One who joins after your Series A is not.

Now the arithmetic that kills companies. Ten advisors at 0.75% each is 7.5% of your company, gone, before you've hired a single employee. Add a standard 10% to 15% option pool for actual staff and a 20% seed round, and later financings get painful. Advisory equity feels free because it isn't cash. It isn't free. It's the most expensive currency you have.

Two rules keep this sane. Cap every advisor at or below 1% and apply the cap uniformly, so there's nothing to negotiate. And decide your total pool before you talk to anyone, write the number down, treat it as fixed. Three to five advisors is plenty for a company under ten people. Most founders who end up with twelve got there one flattering conversation at a time.

How do you structure the agreement so a bad fit costs you nothing?

Vesting and a cliff. Every advisor grant should vest monthly over two years with a three-month cliff, and none of it should be granted outright.

The cliff matters most and gets skipped most. If an advisor stops engaging in month two, a three-month cliff means they leave with nothing. Without it, somebody who took one call owns a piece of your company forever. FAST builds this in by default: two-year monthly vesting, three-month cliff, which lets you end an unproductive relationship in the first quarter at zero cost.

What the document should nail down, in plain language:

Time commitment. "Monthly hour-long call" is a commitment. "As needed" is not.
Deliverables, if any. Two customer introductions a quarter. One hiring interview per key role. Something countable.
Term and termination. Either party ends it with written notice, and unvested shares return to the pool.
Confidentiality and conflicts. They shouldn't be advising your direct competitor. Ask in writing, and ask again in a year.
What they get. Options or restricted stock, the exact percentage, and the vesting schedule.

You don't need a lawyer for a standard advisor grant. The FAST Agreement is free, is designed to be signed without legal review, and as of v3 can be localised to most jurisdictions that permit granting options or restricted stock. Use it, or use your law firm's template if you have one. What you should not do is invent terms in an email thread, because the informal version is exactly how founders end up with vested equity and no recourse.

How do you run advisor meetings that are worth the equity?

Come with a decision, not an update. The single biggest predictor of whether an advisory relationship stays alive is whether the founder shows up with something specific enough to be useful.

Most advisor calls die the same way. The founder spends forty minutes narrating the last month, the advisor says something encouraging, and both leave feeling the meeting was fine. Nothing happened. Do that four times and the advisor quietly stops prioritising the call, which is a rational response to being treated as an audience.

The format that works is boring and effective:

Send a one-page brief 48 hours ahead. Where you are on the numbers that matter, and the one or two decisions you're stuck on.
Spend the first five minutes on context, not thirty.
Ask a decision-shaped question. "Should we sell to hospitals or clinics first, and what would you need to see to be sure?" beats "what do you think about our go-to-market."
Ask for one specific thing. An introduction to a named person. A review of your pricing page. Concrete asks get answered.
Send a three-line follow-up saying what you decided and did. Almost nobody does this, and it's why advisors disengage. People stay invested in things they can see moving.

That brief is where the prep pays off. If you can't summarise your position and open questions on one page, the problem isn't the advisor, it's that you haven't done the thinking yet. Some founders do this in Notion, some in a doc template, some in a structured planning tool like Foundra that walks first-time founders through the same sections each month so the brief mostly writes itself. The tool matters less than doing it before the call rather than during it.

Keep individual monthly calls rather than convening everyone at once. Group advisory meetings sound official and usually produce worse advice, because people perform for each other and specific questions get sanded into consensus. Save the group format for once or twice a year, if at all.

And watch for the failure mode that gets more expensive the better your advisors are: handing them the decision. If you pivot on one advisor's opinion and un-pivot when a second disagrees, you don't have advisors, you have a steering committee you accidentally hired. They have context on their domain. You have context on your company. Weigh the input, then decide.

In 2006, when Yahoo offered around $1 billion for Facebook, most of the people around Mark Zuckerberg leaned toward taking it, reportedly including board members Peter Thiel and Jim Breyer. Marc Andreessen was among the few advising him not to sell. Zuckerberg didn't sell. Note the shape of that: the advisor supplied a dissenting view, the founder made the call. Nobody voted.

When and how do you fire an advisor?

When two quarters go by without them doing anything you asked for. End it in writing, thank them for the time, and return the unvested shares to the pool.

Founders avoid this conversation because it feels ungrateful, so they let dead grants keep vesting for two years. That's tens of thousands of dollars of future value paid for nothing, and it's unfair to the advisors who are showing up.

Signals it's over: three consecutive missed calls, advice that's a decade or a company-stage out of date, a promised introduction that never came, or you've started dreading the meeting. That last one is more reliable than it sounds.

The conversation is short. Tell them the company's needs have shifted, thank them for something specific they did, and confirm in writing that the agreement is ending and unvested equity is returning. Most advisors take this fine. They've usually noticed too.

Then run the annual audit: list every advisor, what they contributed in twelve months, what it cost in equity. Anyone scoring zero in the first column comes off. It's a fifteen-minute exercise most founders never do, and it's the difference between a startup advisory board that compounds and one that just dilutes.

Key takeaways

An advisory board has no voting rights, no fiduciary duty, and no legal power. Cheap to set up, entirely dependent on how you run it.
Recruit against specific blockers, not job titles. Someone three to five years ahead of you usually beats someone thirty years ahead.
Test with a small request before discussing equity. One month and eight hours of interaction is a reasonable minimum.
Per-advisor grants run 0.1% to 1% by stage and engagement. Total pool: 1% to 3%. Decide the number before you talk to anyone.
Always vest over two years with a three-month cliff. Never grant equity outright.
Show up with a decision and a one-page brief, ask for one concrete thing, follow up with what you did.
Audit annually and end the relationships that produced nothing.

More on the thinking you bring to these conversations, including cofounder equity splits and cap tables, is in the guides at foundra.ai/key-reads/.

FAQ

Do advisors get paid in cash or equity?

Almost always equity. The FAST framework is built for equity-only relationships. If someone wants cash, you're negotiating a consulting contract, not an advisory role, and it should be documented as one with a scope and a rate.

Should I list my advisors on my website?

Only with permission, and only if they'd take a call about you. Investors do check. An advisor who doesn't remember your company name when a VC calls does more damage than having no advisory page at all.

Can an advisor also be an investor?

Yes, and it's common. Keep the two grants separate on the cap table: shares they bought are shares they bought, advisory equity is compensation for work. Blending them makes diligence messier than it needs to be.

What if an advisor asks for more equity than the standard range?

Ask what they'll commit to that justifies it, in writing. Sometimes the answer is good, like an operating role or a guaranteed volume of introductions. More often it's a signal about how they see the relationship, and the answer should be no.

How many advisors should a pre-seed startup have?

Three to five. Beyond that you can't maintain real relationships with any of them, and the dilution starts to matter. One advisor you speak to monthly is worth more than eight names on a slide.

What happens to advisory shares if the company is acquired?

It depends on your grant terms. Vested shares usually participate like other common stock; unvested shares either accelerate or terminate depending on the agreement and the acquirer's terms. Read that clause before you sign, not after you have an offer.

Startup Customer Support: A Founder's Playbook

Spencer Claydon — Sun, 30 Aug 2026 18:41:34 +0000

A founder I talked to last year had 60 paying customers and a support inbox he checked twice a week. He described it the way you'd describe taking out the bins. Necessary, slightly unpleasant, definitely not the real work.

Six weeks later he churned eleven of those customers in a single month. When he finally read back through the inbox, the answer was sitting there in plain text. The same onboarding step had confused nine different people. Nobody had connected the dots because nobody was looking at the inbox as data. It was just a chore queue.

That's the mistake. Startup customer support looks like an operational cost, so founders treat it like one: minimize it, defer it, outsource it the second there's budget. But in the first two years, your support inbox is the highest-signal research channel you will ever have. It's the only place where real users, spending real money, tell you exactly where your product breaks, unprompted and for free.

This is a guide to running startup customer support as a product function rather than a chore. What to do yourself, what to automate, what to measure, and when to hand it off.

Why should founders do customer support themselves?

Because it's the cheapest customer research you will ever run. Every ticket is a user telling you where your product failed them, in their own words, at the exact moment it happened. You cannot buy that quality of signal.

Interviews are useful but they're artificial. You schedule a call, the person context-switches into "being helpful," and they tell you what they think about your product in the abstract. Support is the opposite. Somebody is stuck, right now, mid-task, and annoyed enough to type. That's raw behaviour, not recalled opinion.

The Airbnb founders answered support email personally in the early days, including long apologetic threads with a single unhappy guest who complained about everything from the smell of the house to ADA compliance. That sounds like a waste of three founders' time. It wasn't. Those threads are where the trust and safety product came from.

Stripe still does a version of this at scale. Patrick and John Collison have run Friday customer fireside chats, and more recently a customer joins the first 30 minutes of the management team meeting on a two-week rotation, in front of about 40 leaders. A company processing hundreds of billions of dollars still puts customers in the room.

There's a second reason, less obvious. Doing support yourself is the fastest way to find out whether you actually like your customers. Some founders discover, forty tickets in, that they've built something for people they can't stand talking to. Better to learn that in month four than year three.

When does customer support become a product function?

The moment you start tagging tickets. Support turns into a product function when you stop answering questions one at a time and start counting which questions repeat.

One person confused by your billing page is a person. Nine people confused by your billing page is a bug in your billing page. The only thing separating those two states is whether you wrote it down.

Here's the minimum viable version. Every ticket gets one tag from a short list you control:

Bug (it's broken)
Confusion (it works, they couldn't find it or understand it)
Missing (they wanted something you don't have)
Billing (money, invoices, plan changes)
Praise or other (everything else)

That's it. Five tags, no sub-categories, no taxonomy meetings. At the end of every week you count them. Confusion tickets are UX debt. Missing tickets are your roadmap backlog with demand attached. Bug tickets are self-explanatory. Billing tickets above about 10% of volume usually mean your pricing page is lying to somebody.

The counting is what makes it a product function. Without it you're doing customer service. With it you're doing continuous discovery that happens to also make people happy.

Groove learned this the hard way. In January 2013 they were churning 4.5% monthly with no idea why. When they dug in, users who stayed had first sessions averaging three minutes and 18 seconds, while users who left averaged 35 seconds. The product wasn't bad. It was invisible. They reached out offering to walk people through setup and got a 26% response rate, which is an extraordinary number for cold outreach to a churning user.

How do you set up startup customer support with no budget?

Use a shared inbox, one public email address, and a written response template file. Total cost: nothing. You do not need a help desk until you have a second person answering tickets.

Ranked by how I'd actually roll it out:

A real support address. support@yourdomain.com, not your personal email, not a contact form that dumps into a void. Forward it to whoever's answering. The address matters because it survives you hiring someone.
A snippets file. A plain document with your fifteen most repeated answers. Copy, paste, personalise the first line. This alone cuts your handling time in half.
An in-app way to reach you. A link in the nav, not a chat bubble. Chat bubbles set an expectation of instant response that a solo founder cannot keep.
A help desk, eventually. Help Scout is free for up to five users at 100 contacts a month. Intercom starts around $39 per seat with Fin resolutions billed separately at roughly $0.99 each. Crisp does flat per-workspace pricing, around $95 a month for ten seats, which is friendlier than per-seat once you have a team. Plain sits near $35 per seat with AI included.

Most of these vendors run startup programs worth checking before you pay list price. Help Scout gives six months free on Plus for companies under two years old and $1M ARR. Intercom's early stage program discounts year one heavily. Zendesk and Freshworks both do VC-backed startup deals. If you're bootstrapped, the free Help Scout tier or a plain shared inbox will carry you further than you expect.

The tooling is the easy part. The hard part is the writing, and no software fixes that. Structuring your thinking before you write is where most of the gain sits, whether you do that in a Notion doc, a Linear issue template, or something like Foundra where the customer and positioning work already lives alongside the plan. The tool matters less than the habit of turning what you heard into something written down.

What response time should an early startup actually target?

Under four hours during your working day, and be explicit that you have working hours. Speed is a real advantage for small companies, but consistency beats speed and honesty beats both.

The benchmark data is unflattering to most companies. Average email first response time across industries sits around 12 hours. About 89% of customers say they expect a reply within an hour, and only 37% of companies actually meet response expectations across their channels. SaaS live chat averages about 1 minute 22 seconds, but 60% of chat users expect an answer within two minutes.

Read those numbers as an opportunity rather than a standard. You are a founder with 40 customers. You can reply in 20 minutes and it will feel like magic, because the median experience your customer has elsewhere is a 12 hour wait for a templated non-answer.

But do not promise 20 minutes. Promise four hours, deliver in one, and put your hours on the page: "We answer support Monday to Friday, 9am to 6pm GMT, usually within a few hours." A customer who knows they'll hear back tomorrow morning is calm. A customer who was told "instant" and waited nine hours is writing a tweet.

One more thing on speed. A fast acknowledgement is not the same as a fast resolution, and customers mostly care about the first one. "I've seen this, I'm digging in, I'll have an answer by tomorrow lunchtime" resolves the anxiety even when it doesn't resolve the bug yet.

How do you turn support tickets into a product roadmap?

Run a weekly 30 minute pass over the tagged tickets and convert repeats into roadmap items with a number attached. The number is what makes support beat opinion in a prioritisation argument.

Here's the cadence that works:

When	What you do	Time
Daily	Answer, tag, note anything surprising	20 to 40 min
Weekly	Count tags, pull the top three repeats	30 min
Monthly	Compare this month's top repeats to last month's	45 min
Quarterly	Check which shipped fixes actually killed their ticket category	1 hour

The quarterly check is the one everyone skips and it's the most useful. You shipped a fix for the confusing billing page. Did billing tickets drop? If they didn't, you fixed the wrong thing, and the ticket count tells you within a month instead of never.

What this gives you in a planning session is a sentence like "this affected 14 of our 90 active accounts last month" instead of "I feel like this is a problem." Feature requests that arrive through support come with built-in demand evidence. Feature requests that arrive through your own head do not.

A caveat, because this can go wrong. Support volume over-weights your loudest and least technical users, and it never hears from the people who quietly gave up and left. So treat tickets as one input, not the roadmap itself. Pair it with churn interviews and usage data. If you want the wider picture of how these inputs fit together, the pieces on feature prioritisation and user retention over at foundra.ai/key-reads/ cover the other halves of this.

What should you never automate in the first year?

Anything where the customer is angry, confused about money, or about to leave. Automate the retrieval, never the judgement.

Safe to automate early:

Password resets and other self-serve account actions
Order and invoice confirmations
A searchable help centre with your fifteen most common answers
Auto-acknowledgement that a ticket arrived, if it's honest about timing

Do not automate:

Cancellation and refund conversations
Bug reports from paying customers
Anything from a customer who has already written twice
Feature requests, because that's the research you're supposedly collecting

AI support agents have gotten good at deflection. Some tools now claim to cut average live chat first response from six hours to under four minutes. That's a real gain for a company with 40,000 tickets a month. For a company with 40, deflection is the opposite of what you want. You're paying software to prevent the conversations you most need to have.

There's a version of this that's easy to miss. When you automate too early, you don't just lose the insight. You lose the moment where a frustrated customer becomes a loyal one, which happens more often than founders expect. Somebody who had a problem and got a fast, human, slightly over-generous response tends to stick around longer than somebody who never had a problem at all.

When should you hire your first support person?

When support consistently takes more than 90 minutes of your day, or when your response quality is dropping because you're rushing. Not at a customer count, at a time cost.

For most B2B SaaS startups that lands somewhere between 150 and 400 customers, but the range is wide because ticket rate per customer varies enormously by product complexity. A simple tool might generate one ticket per 20 customers per month. Anything with integrations, permissions, or billing complexity might generate five.

Two things to get right when you do hire:

Do not fully hand it off. Keep a founder in the inbox one day a week, permanently. The moment the founding team stops reading tickets, the product team starts building from summaries of summaries. Stripe's leaders still interview customers twice a month at their scale. Yours should still read tickets at yours.

Hire a writer, not a ticket closer. Your first support person writes the tone of your company into every reply, and they're the one who'll spot patterns before anybody else. Look at how they write, not how many tickets per hour they've handled. The metrics-optimised hire from a big support org is often the wrong fit, because they've been trained to close tickets fast rather than to notice what a ticket means.

Key takeaways

Startup customer support is your cheapest and highest-signal research channel. Every ticket is a user showing you where the product broke, in the moment, unprompted.
Support becomes a product function the second you start tagging and counting. Five tags is enough: bug, confusion, missing, billing, other.
You don't need a help desk until you have a second person answering. A shared inbox, a real support address, and a snippets file will take you to 150 customers.
Target under four hours during stated working hours. The industry average is around 12 hours, so reliable and honest beats theoretically instant.
Automate retrieval, never judgement. Cancellations, refunds, bug reports from paying customers, and feature requests all stay human in year one.
Hire when support costs you more than 90 minutes a day, and keep one founder in the inbox one day a week forever after that.
More founder playbooks on prioritisation, retention, and go-to-market are at foundra.ai/key-reads/.

FAQ

Should a solo founder do their own customer support?

Yes, for at least the first year. It's the fastest way to find out where your product breaks and whether you've built for customers you actually want. Budget 20 to 40 minutes a day and protect it like a standing meeting.

How many support tickets is normal for an early startup?

It varies hugely by product complexity, roughly one ticket per 20 customers per month for a simple tool and up to one per five for anything with integrations, billing tiers, or permissions. Track your own ratio for a quarter rather than benchmarking against someone else's.

What is support-driven growth?

It's the practice of treating support as a revenue and retention driver rather than a cost centre. Groove popularised the term after finding that proactive outreach to struggling users got a 26% response rate and cut churn substantially.

Do I need help desk software at 50 customers?

No. A shared inbox with a real support address handles 50 customers fine. Move to a help desk when a second person starts answering tickets and you need assignment, history, and no duplicate replies. Help Scout is free up to five users at 100 contacts a month if you want the training wheels early.

Should I use an AI chatbot for support as an early startup?

Not for anything beyond a searchable help centre. AI deflection is valuable at high ticket volume and actively harmful at low volume, because it prevents exactly the conversations you need to hear. Revisit it when you're past a few hundred tickets a month.

How do I stop support from eating my whole week?

Write a snippets file of your fifteen most repeated answers, batch support into two fixed windows a day instead of reacting all day, publish your working hours, and ship fixes for your top repeating ticket category every month. The last one is the only permanent solution: the fastest way to reduce support volume is to remove the reasons people write in.

How to Run a Two-Week Build Cycle at a Startup

Spencer Claydon — Sat, 29 Aug 2026 15:09:34 +0000

Ask a first-time founder what they shipped last month and you'll usually get a story instead of a list. The auth refactor is nearly done. The onboarding flow got started, then paused for a customer call that turned into a custom feature. The pricing page has been "one more day away" since the 6th.

Nothing's broken. Nothing's finished either.

A two-week build cycle fixes this by making time the fixed thing and scope the negotiable thing. Most founders do the reverse: they decide exactly what to build, then find out how long it takes. That's how you end up seven weeks into a three-week feature with no way to stop, because stopping would mean admitting the last five weeks produced nothing you can put in front of a user.

What is a two-week build cycle?

A two-week build cycle is a fixed ten-working-day block where you commit to a small set of outcomes, ship whatever is done at the end, and refuse to extend the deadline. The date doesn't move. The scope does.

That last part is the whole method. Everything else is logistics.

The idea comes out of the same tradition as agile sprints, but it borrows the important bit from Basecamp's Shape Up: the appetite. Instead of asking "how long will this take?", you ask "how much time is this worth?" A settings page might be worth three days. A billing migration might be worth the whole cycle. You decide the budget first, then you shape the work to fit inside it.

Basecamp runs six-week cycles because their teams are building things a startup at your stage has no business building yet. Their reasoning still applies at two weeks: six weeks is "long enough to build something meaningful start-to-finish and still short enough that everyone can feel the deadline looming from the start." Swap in your own numbers. Two weeks is long enough for one real thing and short enough that day one already feels urgent.

Why two weeks instead of six?

Two weeks is right for pre-product-market-fit startups because your learning rate matters more than your build rate. Six-week cycles assume you know what to build. You don't yet.

Here's the tradeoff in plain terms. Longer cycles reduce planning overhead and let people get into deep work. Shorter cycles get you feedback faster and cap how much you can be wrong about. Before product-market fit, being wrong is the expensive thing, so you want the tighter loop.

The delivery research backs this up from a different angle. Small batches are the most consistent predictor of both speed and stability in software delivery. Teams that ship in small increments don't just move faster, they break things less, because a small change is easier to test, easier to review, and easier to roll back. The CHAOS data on project size is blunt about it: small projects fail at roughly 7%, while big ambitious ones fail at over 40%. Your build cycle is a mechanism for making everything a small project.

And there's a founder-specific reason. Two weeks is short enough that you can actually remember what you decided on day one. Six weeks isn't. I've watched founders open their own cycle doc in week five and have no idea why past-them thought the referral system was the priority.

Once you have paying customers and a roadmap that survives contact with reality, stretch to three or four weeks. Not before.

How do you decide what goes in the cycle?

Pick one primary bet and at most two small items, then write down what "done" means for each before you start. If you can't describe done in a sentence a customer would understand, it's not shaped enough to build.

A useful filter: every item in the cycle should be something a user could notice. "Refactor the data layer" fails. "Search results load in under a second" passes. Internal work is real work, but if your cycle is all internal work, you're two weeks from being exactly where you started with a slightly nicer codebase.

Try this shape:

One primary bet. The thing this cycle is about. Roughly 60% of your capacity.
Two supporting items. Small, boring, ship-in-a-day things. Bug fixes, a copy rewrite, a broken email template.
Nothing else. No stretch goals. Stretch goals are how a two-week cycle becomes a three-week cycle.

Leave real slack. If you're a solo founder and you plan ten working days of work into a ten-day cycle, you will finish approximately none of it, because you also have to answer support emails, talk to customers, and do the thing where the payment provider changes an API without telling you. Plan six days of building into a ten-day cycle. That's not pessimism, that's arithmetic.

Writing the bet down matters more than it sounds. One paragraph: what problem, for whom, what changes when it works, what you're deliberately not doing. If staring at a blank doc for that is the part you keep avoiding, structured planning tools help. Notion templates, a Linear project brief, or a platform like Foundra that walks first-time founders through scoping and go-to-market decisions will all do the job. The format is less important than the fact that the decision exists somewhere outside your head.

What does a two-week build cycle actually look like?

Ten working days, with the first and last half-days reserved for planning and shipping. The middle eight days are for building and nothing else.

Here's a cadence that survives contact with reality:

Day	What happens
Day 1 (morning)	Cycle kickoff. Write the bet. Define done. Set the appetite for each item.
Days 1 to 4	Build the risky part of the primary bet first.
Day 5	Mid-cycle check. Honest read on whether the bet is going to land.
Days 6 to 9	Build the rest. Cut scope aggressively if day 5 went badly.
Day 10 (morning)	Ship what's done.
Day 10 (afternoon)	Cool-down. Review, write down what you learned, close the cycle.

Two things about this that people get wrong.

Build the scary part first. Not the fun part, not the easy part, the part you're least sure about. If the whole feature depends on an integration you've never used, spend day one on that integration. Finding out on day nine that it doesn't do what you assumed is the single most common way a cycle dies.

Day 5 is a decision, not a status update. You're answering one question: given what I now know, will this ship by day 10? If the answer is no, you cut scope right there. Not on day 9. Cutting on day 5 gives you five days to build a smaller version that actually works. Cutting on day 9 gives you nothing.

The cool-down at the end isn't optional slack you can skip when you're behind. It's where the learning gets captured. Skip it three cycles in a row and you'll be running fast in a direction nobody has checked recently.

How do you keep the cycle from getting hijacked?

Set a rule before the cycle starts about what's allowed to interrupt it, and make the bar high. Most interruptions feel urgent and aren't.

The default rule that works for early startups: only two things break a cycle. Production is down, or a paying customer is about to leave. That's it. Everything else goes into a list you look at during cool-down.

The hard case is the sales-driven feature request. A prospect says they'd sign if you had X. Your instinct is to build X immediately. Resist it for two weeks. If they'll still sign in two weeks, you lost nothing. If the request evaporates in two weeks, you just saved yourself from building something nobody wanted, which happens more often than founders like to admit.

Keep a "next cycle" list somewhere visible. Not a backlog, those rot. Just a running list of candidates you'll actually read on day 1 of the next cycle. Most items on it will look much less urgent by then, and that's the point. The list is a filter disguised as a queue.

One more trap: the cycle that never ends because you keep polishing. Shipping on day 10 means shipping something imperfect. If it's behind a feature flag for ten users, imperfect is fine. Ship it to those ten, watch what happens, fix it next cycle.

How do you know if the cycle worked?

Judge a cycle on two things: did you ship what you said you'd ship, and did shipping it teach you something. Velocity without learning is just expensive motion.

Track a handful of numbers across cycles, not within them:

Ship rate. How many cycles ended with the primary bet actually live? If it's below 60%, you're over-scoping. Cut your appetite in half next time.
Cycle days lost to interruptions. If it's more than one day in ten, your interruption rule isn't real.
Time from cycle end to first user feedback. If this is longer than three days, you're building for an audience you're not talking to.
How often the day 5 check changed the plan. Zero is a bad sign. It means you're not being honest at the midpoint, or you're only picking work you already know how to do.

You don't need a dashboard for this. A four-column note that you add one row to every two weeks will beat any tool you set up and abandon. What you're looking for is the trend across six or eight cycles, not the result of any one.

On the delivery side, deployment frequency is the cheapest proxy for whether your process is working. Elite teams in the DORA research deploy on demand with change failure rates around 5%, and they do it because their batches are small, not because their engineers are heroic. You're not competing with them at three people. But the direction is right: if your deploys are getting less frequent and more terrifying over time, your cycle is drifting back into big-batch territory.

What breaks first when you scale past two people?

Coordination overhead. The two-week cycle works beautifully for one or two people because everyone knows everything. At four or five, the daily context that used to happen by osmosis has to be written down.

The failure looks like this: two people are building against the same assumption, and it turns out they had different versions of it in their heads. You lose three days. Then someone suggests a daily standup, and now you have a daily standup, and standups have a way of multiplying into planning meetings.

What actually helps at that size:

A written bet everyone read, not a bet everyone heard.
One person who owns the scope-cutting decision. Committees don't cut.
An async end-of-day note per person. Two sentences. What moved, what's blocking.
Explicit interfaces between people's work so you're not blocked on each other mid-cycle.

If you're still solo, none of this applies and adding it will slow you down. Founders love importing process from companies fifty times their size. Don't. The two-week cycle is already most of the process you need, and the discipline is in what you leave out.

Key takeaways

A two-week build cycle fixes time and flexes scope. The date never moves.
Set an appetite before you plan the work. Ask what the problem is worth, not how long it takes.
One primary bet plus two small items. Plan roughly six days of work into ten days.
Build the riskiest part on day one, not the easiest.
Day 5 is a go or cut decision. Cutting late is the same as not cutting.
Only two things interrupt a cycle: production is down, or a paying customer is leaving.
Measure ship rate and time-to-feedback across cycles, not output within one.
Add process only when team size forces it, and add the smallest amount that works.

If you want the wider picture of how build cadence connects to validation, pricing, and go-to-market decisions, there's more in the Foundra key reads library.

FAQ

How long should a startup build cycle be?

Two weeks before product-market fit, three to four weeks after. Shorter cycles buy you feedback, longer cycles buy you focus. Early on, feedback is worth more because you're still finding out what to build.

Is a two-week build cycle the same as a scrum sprint?

They share a length but not a philosophy. Scrum sprints usually estimate work in points and commit to a scope. A build cycle commits to a date and a budget of effort, then cuts scope to fit. There's also far less ceremony: no daily standup requirement, no burndown chart, no retrospective template.

What if I don't finish the primary bet by day 10?

Ship the part that works and close the cycle anyway. Then ask why: was the scope too big, was the risky part left too late, or did interruptions eat the middle? Extending the cycle hides the answer. Closing it on time forces you to look at it.

Can a solo founder run build cycles?

Yes, and it's arguably more useful solo than on a team, because nobody else is going to notice you've been drifting. The one adjustment: plan far less work than you think you can do. Solo founders carry support, sales, and marketing inside the same ten days.

Should design and research happen inside the cycle?

Shaping work should happen before it, not during it. If you're still figuring out what the feature should do on day 3, you're doing discovery on build time and the cycle will overrun. Use the cool-down at the end of each cycle to shape the next one.

How do I handle bugs during a cycle?

Fix anything that blocks a user from doing the core thing, immediately. Everything else goes on the list and gets triaged during cool-down. Most bugs feel more urgent on the day they're reported than they do two weeks later, which tells you something.

How to Improve User Retention for Your Startup

Spencer Claydon — Fri, 28 Aug 2026 15:10:53 +0000

You launched. People signed up. Some of them even used the thing. And then, quietly, most of them stopped.

That's the moment most first-time founders discover acquisition was the easy part. You can buy signups. You can hustle your way to a thousand of them. What you can't buy is user retention, and until your retention curve stops falling toward zero, every dollar you spend on growth goes into a bucket with a hole in it.

Retention isn't a marketing problem you fix later with email. It's a product problem, and the mechanics that solve it are specific, well-documented, and mostly ignored because founders would rather ship features. This piece is about those mechanics: what actually makes people come back, what the numbers mean, and which famous retention statistics you've been quoting are wrong.

What does user retention actually mean for an early startup?

User retention is the percentage of a signup cohort still using your product after a given period. Not logged in. Using it, in a way that matches how your product is meant to create value.

That last part matters more than it sounds. If you're building a weekly planning tool, daily active users is a vanity number and a monthly measure hides people who've already drifted. Pick the natural frequency of the job your product does, then measure against that. Duolingo measures daily because language learning is a daily habit. A tax product measures annually because that's the actual cadence of the problem.

Then group users by when they joined. That's a cohort. Everyone who signed up in March is one cohort, April another. Track each group separately, because blending them lets a big acquisition month paper over the fact that nobody sticks around.

One more definition, because founders conflate these constantly. Activation is getting a new user to first value. Retention is getting them to come back on their own. Activation is a one-time event you can engineer with onboarding. Retention is a repeating loop you have to design into the product itself. If you haven't got activation working yet, retention work is premature, and there's a whole separate piece on that at foundra.ai/key-reads/user-activation-for-startups.

What does a healthy retention curve look like?

A healthy retention curve flattens. That's it. That's the whole test.

Plot the percentage of a cohort still active at week 1, week 2, week 4, week 8, and so on. Every product loses people early. What separates a real product from a leaky bucket is whether the line eventually goes horizontal, meaning a core group has settled in and stopped leaving. If your curve keeps sloping down toward zero, no amount of growth spend fixes it. You're renting users, not keeping them.

There's a rarer and better shape: the smile. The curve drops, flattens, and then starts climbing as churned users come back because the product got better. Andreessen Horowitz used ChatGPT's monthly web retention as the clearest public example of this in their September 2025 analysis. Smiles are rare. Don't plan for one. But if you see the tail tick up, that's a very strong signal.

For rough calibration, Lenny Rachitsky's benchmarks, gathered from surveys of growth practitioners, put good user retention at roughly 40% for consumer subscription and 70% for great, with SMB and mid-market SaaS around 60% good and 80% great, and enterprise at 70% and 90%. Treat those as bands, not targets. What you should actually compare against is your own earlier cohorts.

Are you even measuring retention from the right starting point?

Probably not, if you're an AI-adjacent product in 2026. This is the single most useful shift in retention measurement in the last two years and almost nobody outside a16z's portfolio is using it.

The traditional approach anchors retention to Month 0, the month someone signs up. That made sense when signing up meant a real decision. It makes much less sense now, when a large slice of any new cohort is what a16z partners Santiago Rodriguez and Alex Immerman call "AI tourists": people who will happily pay $20 to try almost anything for a month, then vanish. Anchoring to M0 means your headline retention number is mostly a measurement of how many tourists you attracted, which tells you very little about the product.

Their fix is to rebase. Measure from Month 3 instead. By M3 the tourists have churned out and you're left with the users who found a real use case. The metric they recommend is M12 divided by M3: how the people who survived the tourist wash-out behave over their first full year. Curves in their dataset of AI companies past $1M ARR typically start flattening around M3, and where they flatten from there is the number that predicts long-term retention.

Two practical consequences. First, don't panic about a steep M0 to M3 drop if the curve flattens after. That drop is the price of a generous free tier or a broad, cheap product. Second, track cost per retained customer at M3 rather than cost per signup, because the signups you paid for in month zero are not the customers you actually have.

Do you need a "magic number" like Facebook's seven friends?

No. And the magic numbers you've read about are more useful as stories than as science.

Facebook's "seven friends in 10 days" is the most quoted growth metric ever produced. Chamath Palihapitiya, who ran growth there, described it as the keystone the entire growth org rallied around. Slack has its 2,000 team messages. Twitter had 30 follows, which Josh Elman summarized as the point past which a user was "more or less active forever."

Here's what gets left out. Andrew Chen, who was closer to this than almost anyone, has pointed out that Facebook's number could plausibly have been "10 friends in 12 days" or "five friends in one day." The precision is invented. Mixpanel's own write-up is blunt about it: magic numbers are an illusion, a useful one, but an illusion. They're a memorable story that gets a company pointed at the same behavior, not a threshold you cross into permanent retention.

So when you go looking for yours and the data comes back messy, with Action A correlating a bit and Action B correlating a bit and no clean tipping point anywhere, that's normal. That's what real data looks like.

What you can do instead is find per-feature milestones. VSCO did this well. Rather than one company-wide number, they measured how many times someone had to use each feature before they kept coming back to it. Editing was stickiest at eight photos. Publishing took 10. Collecting, the least sticky, took 16. The goal became moving people from one milestone to the next. Same idea, less mythology, far more actionable when your product does more than one thing.

And watch the causation. Users who add seven friends retain better, but adding friends may be a symptom of already liking the product rather than the cause. Forcing a disengaged user through the motion rarely produces the same outcome as watching an engaged one do it naturally.

Which retention mechanics actually work?

Four mechanics do most of the work. They're not equally available to every product, and picking the wrong one for your category wastes months.

Mechanic	How it holds people	Works best for
Habit loop	An external trigger fires on the natural cadence of the job, the user acts, and gets a small reward	Products used daily or weekly
Accumulated value	The longer someone uses it, the more of their own data, history, or setup lives inside	Notes, CRMs, finance, analytics
Network pull	Other people are in there, so leaving costs you access to them	Anything multiplayer or team-based
Loss aversion	The user has built something they don't want to break	Streaks, levels, badges, saved progress

Accumulated value is the most underrated of the four and the most available to a small team. It costs nothing to make your product remember things. Every note saved, every template customized, every historical chart raises the cost of leaving without a single gamification feature. A founder six months into a planning tool has six months of their own thinking in it, and that alone beats a competitor's better feature list.

Network pull is strongest when you can get it and hardest to bootstrap. Slack's 2,000 messages isn't magic because of the number. It's magic because at 2,000 messages the team's conversation lives in the tool, and leaving means leaving the conversation.

Habit loops need honesty about frequency. If your product really solves a monthly problem, don't manufacture a daily loop. You'll just train people to ignore your notifications, which is worse than sending none.

Why do streaks work, and when do they backfire?

Streaks work because losing something you've built hurts more than gaining something new feels good, and because they convert a vague intention into a daily, visible commitment.

Duolingo is the reference implementation and worth studying properly rather than copying at a glance. Jackson Shuttleworth, who leads their retention team, told Lenny Rachitsky that the team has run over 600 experiments on the streak feature over roughly four years, testing on close to a daily basis, with most of the effort concentrated on the first seven days of a user's life. Over 9 million people hold streaks longer than a year. Lenny called it the single biggest driver of Duolingo's growth to a company worth around $14 billion.

Six hundred experiments. That's the number founders skip past when they add a streak counter in an afternoon and wonder why it did nothing.

The backfire mode is anxiety. A streak that can only be lost eventually becomes a source of dread, and when it breaks the user often quits entirely, because the thing they were protecting is gone and there's nothing left to protect. Duolingo's answer is leniency built into the mechanic: streak freezes and repair options that let a broken streak be recovered rather than reset to zero. If you build a streak, build the forgiveness at the same time. A streak without a safety valve is a churn trigger with a countdown on it.

The general principle, which applies well beyond streaks: any mechanic that makes users feel watched or judged will produce short-term engagement and long-term resentment.

How do you find your own retention lever without a data team?

Talk to the people who stayed. Not the ones who churned.

Churn interviews feel productive and mostly aren't. People who left will give you a polite, plausible reason that isn't the real one, usually price. The users who stuck around for three months and use the product every week are the ones holding the answer, because whatever they're doing is the behavior you need to engineer for everyone else.

A workable version of this for a pre-analytics startup:

Pull your list of users still active after 60 days. If that's 12 people, fine, 12 is enough to see a pattern.
Talk to eight of them. Ask what they'd use instead if you shut down tomorrow, and what specifically would be annoying about switching. The friction they describe is your retention mechanic, whether you built it deliberately or not.
Look at what those users did in their first week that the churned users didn't. You don't need a data warehouse for this. A CSV and an afternoon will do.
Write down one hypothesis in the form "users who do X in week one retain, so we will make X easier to reach." One. Not five.
Ship the change, then watch the next cohort's curve rather than the blended average.

That last step is where most teams fail. Blended numbers move slowly and hide everything. Cohorts tell you within a few weeks whether the change worked.

If you're at the stage of writing this down for the first time, a spreadsheet is fine, a Notion page is fine, and planning tools like Foundra or LivePlan will walk first-time founders through mapping the user journey and go-to-market assumptions in a more structured way. Foundra also has free calculators at foundra.ai/tools/ if you're sizing the revenue impact. The tool matters far less than actually having a written hypothesis you can be wrong about.

Which retention statistics should you ignore?

Start with the most quoted one in the category. "A 5% increase in customer retention increases profits by 25% to 95%" appears in roughly every retention article ever published, usually credited to Bain and Fred Reichheld. The 95% figure does not appear in Reichheld's original brief. The traceable source is a 1990 Harvard Business Review paper by Reichheld and W. Earl Sasser called "Zero Defections: Quality Comes to Services," which reported that cutting defections by 5% produced 85% more profit in one bank's branch system. One bank. In financial services. In 1990.

Retention obviously drives profit. The point is that a founder repeating a number they can't trace is borrowing confidence they haven't earned.

The second thing to discard is the wave of "2026 retention benchmarks by industry" content flooding search results. Day-1, day-7 and day-30 figures given to the decimal point, cited to nobody, contradicting each other across sites. Most of it is generated, not measured. If a benchmark doesn't name a sample size and a method, it's decoration.

Use practitioner-sourced bands for rough orientation, then benchmark against yourself. Your April cohort versus your March cohort is the only comparison where the methodology is guaranteed to be consistent.

Key takeaways

Retention is a product mechanic, not a marketing campaign. Email can catch drifting users; it cannot manufacture a reason to return.
The only pass-fail test is whether your cohort curve flattens. Falling to zero means no product-market fit, regardless of signup volume.
If you're an AI-era product with a generous free tier, rebase your retention measurement to Month 3 so tourist churn stops distorting the number.
Magic numbers are stories, not thresholds. Per-feature milestones, like VSCO's eight edits and 10 publishes, are more useful and more honest.
Four mechanics do the work: habit loops, accumulated value, network pull, and loss aversion. Accumulated value is the cheapest to build.
Build the forgiveness into any streak before you launch it. A streak with no repair path is a scheduled churn event.
Interview the users who stayed, not the ones who left. Then test one hypothesis and watch the next cohort, not the blended average.

FAQ

What is a good retention rate for an early-stage startup?

It depends on your category. Practitioner benchmarks put good consumer subscription retention around 40% and great around 70%, with SMB and mid-market SaaS closer to 60% and 80%. Early on, the shape of the curve matters far more than the level. A flat 20% beats a falling 45%.

How is retention different from churn?

They're two views of the same thing. Retention counts who stayed, churn counts who left. Churn is usually quoted monthly and applied to revenue or accounts, which makes it the more common metric in B2B reporting. Retention curves are more useful early because they show the shape over time rather than a single month's rate.

How long should I wait before judging my retention curve?

Long enough for the curve to have a chance to flatten, which usually means at least three to four months of cohort data. Judging a two-week-old cohort tells you about onboarding, not retention.

Should I build a streak feature?

Only if your product has a real daily use case and you're prepared to iterate on it. Duolingo ran over 600 experiments on theirs. A streak bolted onto a weekly product mostly generates notification fatigue.

Can better onboarding fix bad retention?

Onboarding fixes activation, which is a different problem. If users understand the product, get value in their first session, and still don't come back, the issue is that there's no reason to return. That's a product design problem and onboarding won't touch it.

What's the cheapest retention improvement for a small team?

Make the product remember more. Saved state, history, customized settings, and past work all accumulate value that raises the cost of leaving, and none of it requires a growth team or an analytics stack to build.

How to Build a Community for Your Startup

Spencer Claydon — Thu, 27 Aug 2026 15:09:44 +0000

Somebody told you to build a community. Probably a VC, probably on a podcast, probably right after they said "distribution is the moat." So you spun up a Slack workspace, invited 40 people from your waitlist, posted a welcome message, and then watched it turn into a room where you talk to yourself once a week.

That's the normal outcome. A Slack with 400 members and three messages a week isn't a growth channel. It's a ghost town with a logo on it.

But community building for startups does work, and when it works it compounds harder than any paid channel you'll ever run. The difference between the two outcomes isn't budget or headcount. It's whether the thing has a reason to exist that has nothing to do with your signup button.

Here's how to think about it.

What does "community" actually mean for a startup?

A startup community is a group of people who get value from each other, not just from you. That's the whole test. If every useful thing in the room comes from your team, you don't have a community. You have a support queue with extra steps.

This distinction matters more than it sounds. Most founders use "community" to mean one of four different things, and they need completely different work:

An audience. People who consume what you publish. A newsletter, a YouTube channel, a Twitter following. Valuable, but one-to-many.
A user group. Customers who talk to you about your product. Feature requests, bug reports, roadmap input. Useful, but it's really research.
A support forum. Users answering each other's product questions. This one has clear ROI and it's the easiest to justify internally.
An actual community. People who show up for each other, and your product happens to be the reason they met.

Only the last one is community-led growth. The other three are good things to build, and you should probably build them first, but don't confuse them. I've watched founders spend six months trying to force a support forum into being a movement, and it never works, because nobody wakes up wanting to hang out in a place designed to reduce your ticket volume.

Should you even build a community right now?

Probably not yet, and here's the test: can you name 20 people who would be disappointed if your community disappeared tomorrow? If not, you're too early.

Community is a retention and expansion channel dressed up as an acquisition channel. It works when you already have people who care. It does almost nothing when you're pre-product-market-fit and trying to manufacture demand out of an empty room.

Three signals that you're ready:

You have users who talk to each other already, in your DMs, in a group chat, in a Reddit thread you didn't start.
Your users have a shared problem that isn't your product. Founders share "how do I get my first customers." Notion users share "how do I build a CRM in this thing." That shared problem is the actual reason people show up.
Somebody on your team wants to do this. Not "has capacity." Wants to. Community work is unglamorous and relentless and it dies the second it becomes a chore assigned to whoever had a light week.

If you're missing all three, put the effort into customer acquisition channels that pay off faster and come back to this at a few hundred users.

Where do your first 100 members come from?

Your first members come from your existing users, hand-invited one at a time, over DM. Not a public link. Not a launch post. Individual invitations to specific people you already know are interested.

This feels absurdly slow. Do it anyway. The first 30 people set the culture permanently, and a community that opens to the public on day one gets its culture set by whoever wanders in.

Notion's ambassador program is the case study worth stealing from. They tweeted a call for people who wanted to get involved and got somewhere north of 600 applications in the first few weeks. They onboarded ten. Ten. That group went on to seed local chapters that now include a Vietnamese community with 200,000-plus members and a subreddit past 300,000. One Tokyo meetup pulled 300 attendees, and roughly 80% of them became paying users.

The lesson isn't "get 600 applications." It's that they treated the first cohort as a hiring decision rather than a signup form.

Practically, for your first 100:

Go through your last three months of support conversations and pick the 20 people who were most enthusiastic or most specific.
DM each one. Tell them what you're building and why you want them specifically. Name the thing they said or did that put them on the list.
Ask each of those 20 to bring one person. That gets you to 40 with zero strangers.
Run something in week one. A call, an AMA, a shared doc, a live teardown. Something with a time and a date, because an empty channel with no event is just a room.

Expect a 30% to 50% acceptance rate on personal DMs to warm users. If you're getting under 20%, the problem is the pitch, not the channel.

Slack, Discord, or something else?

Use Discord if your users are technical or under 35, use Slack if they're B2B professionals who already live in Slack all day, and don't agonize over it for more than an afternoon.

The practical differences that actually matter:

	Slack (free)	Discord (free)
Message history	Last 90 days visible, older content hidden	Unlimited
Cost to upgrade	Per member, around $7 to $9 per user monthly	Flat, Nitro is a per-user perk not a community fee
Search	Limited to the visible window on free	Full history
Culture	Feels like work	Feels like a hangout

That 90-day history limit is the one people underestimate. Slack's free plan hides messages past 90 days, which means every good answer your members write evaporates from search. For a community whose whole value is accumulated knowledge, that's a slow structural leak. Slack's paid plans price per member, so a community that grows to 2,000 people becomes a five-figure annual line item. Discord's economics don't break the same way.

There's a third option most founders skip: don't build a space at all. Run a recurring event instead. A monthly call, a cohort, a weekly office hours slot. Events create the same connections without requiring you to keep a room alive between them, and they're far easier to kill without embarrassment if the thing isn't working.

Why do most startup communities die within a year?

They die because the community was built as a marketing channel, so the moment it stops producing signups, it stops getting attention. Then engagement drops, then the founder posts less, then it's a ghost town, then nobody wants to be the one to admit it.

The specific failure patterns, in rough order of how often I see them:

Launching too wide. Public invite link, 500 members in a week, zero relationships. Big numbers, dead room. Portland Startups Slack is the well-documented version of this: over 6,500 members, and the people running it acknowledged most were lurkers or fully inactive.

Measuring member count. Member count is the community equivalent of registered users. It only goes up, it never tells you anything, and optimizing for it actively pushes you toward the wide-launch failure above.

No reason to return. If nothing happens on a schedule, people check once and forget. Recurring events are the heartbeat. Weekly, biweekly, monthly, pick one and never miss it.

Founder as the only node. If you're the answer to every question, the community collapses the week you get busy. Your job is to introduce people to each other and then get out of the way.

Treating it as free. It isn't. A functioning community needs somebody spending real hours on it every week. If nobody owns it, it will die, and it will take longer to admit than it should.

Here's the uncomfortable part. Commsor raised $16 million and then a $50 million Series B selling software for community-led growth, and later repositioned away from community entirely toward warm intros and networks. The company that most loudly sold the category concluded the category was harder to monetize than the pitch suggested. That's not a reason to skip community. It is a reason to be skeptical of anyone selling you a platform before you have ten people who care.

How do you measure whether a community is working?

Measure the percentage of members who did something in the last 30 days, and the percentage of conversations where the answer came from a member rather than your team. Those two numbers tell you almost everything.

The old rule of thumb is 90-9-1: 90% lurk, 9% react or reply occasionally, 1% create. It's a useful mental model and it's also contested. Higher Logic and others have published data arguing the split is outdated and that healthy communities beat it comfortably. Treat 90-9-1 as a floor rather than a law. If you're below it, something is broken.

A more useful scorecard for an early community:

30-day active rate. Members who posted, replied, or reacted in the last month, divided by total members. Under 10% and you have a list, not a community.
Member-answered ratio. Of questions asked this month, what share got a good answer from someone who doesn't work for you? This is the single best leading indicator that the thing will survive without you.
Time to first reply. How long does a new member's first post sit unanswered? Anything over a few hours in a small community is a culture problem, and it's fixable with three people whose explicit job is to reply fast.
Second-post rate. What percentage of members who post once post again within 30 days? This catches bad first experiences that member count hides.

Track these in a spreadsheet, a Notion doc, or a planning tool like Foundra that keeps your go-to-market metrics next to the rest of your plan. The tool matters much less than the fact that you're looking at the same four numbers every month.

One more thing on measurement: give it 12 months before you judge it. Community is the slowest channel you will ever run. Lenny Rachitsky's subscriber Slack took years to reach the point where it was running nearly 200 real-world meetups across 30 countries, and it's now past 30,000 members. That growth is what compounding looks like from the outside. From the inside, for the first year, it looks like nothing.

What does community look like at 10, 100, and 1,000 members?

The job changes completely at each stage, and most founders keep doing the 10-member job at 500 members and wonder why it stopped scaling.

At 10 members, you are the community. Every conversation is you and one other person. Your only job is to make introductions between members who should know each other, and to be the most useful person in the room. No structure, no channels, no rules. One space.

At 100 members, your job is to create the reasons to show up. A recurring event, a weekly prompt, a shared resource people contribute to. Start naming the regulars publicly. Give the three most active members something official, even if it's just a role and a thank you. This is also where you add structure, and where you stop being able to reply to everything.

At 1,000 members, your job is to build the layer of people who run it without you. Moderators, chapter leads, ambassadors, whatever you call them. Notion's ambassadors and campus leads now run roughly 30 in-person events a month, which is not a thing any internal team could staff. That only works because the program hands real ownership to people outside the company.

The trap between 100 and 1,000 is trying to stay personally reachable. You can't, and pretending otherwise means new members get a worse experience than the early ones did, which is exactly backwards from what you want.

Key takeaways

A community exists when members get value from each other. If all the value flows from you, it's a support channel.
Don't start until you can name 20 people who'd miss it. Pre-PMF community building is almost always wasted effort.
Hand-invite your first 30 members over DM. They set the culture permanently, and you only get one shot at it.
Discord for technical or consumer audiences, Slack for B2B professionals, and check Slack's 90-day free history limit before you commit.
Member count is a vanity metric. Track 30-day active rate and member-answered ratio instead.
Recurring events are the heartbeat. Something on a schedule beats a room that's always open and always empty.
Budget 12 months before you judge whether it's working, and budget real weekly hours from a named owner.

FAQ

How many members does a startup community need to be worth it?

Around 100 engaged members is where it starts generating value on its own. Below that you're the only source of activity. But engagement matters far more than size: 100 people where 30 post monthly beats 2,000 people where 20 do.

How much time does running a startup community take?

Plan for 5 to 10 hours a week at the 100-member stage, and expect it to be founder time early on. It drops per member as you promote moderators, but it never goes to zero. If nobody has those hours, don't start.

Should my community be free or paid?

Free, unless the community itself is the product. Paid communities filter for commitment and cut noise, but they also cap your growth and add an expectation of service delivery. Most startups are better off making the community a benefit of using the product.

What's the difference between community-led growth and just having a Discord?

Community-led growth means the community produces measurable outcomes: referrals, retention, support deflection, product feedback. Having a Discord means you have a Discord. The difference is whether anyone owns it and whether anyone measures it.

How do I restart a community that's already dead?

Archive it and start over with a different format, usually a recurring event instead of a room. Trying to resuscitate a dead channel rarely works, because new members judge activity by what they see in the scrollback, and the scrollback is the problem.

Can I build a community before I have a product?

Yes, and it's one of the few cases where community makes sense early. If you're building an audience around a problem rather than a product, the community becomes your validation channel and your first customer list. Just be clear with yourself that you're building an audience, and that audiences convert far worse than you expect.

User Activation: Why Your Signups Never Come Back

Spencer Claydon — Tue, 25 Aug 2026 15:43:21 +0000

Forty people signed up for your product last month. Six opened it twice. Nobody has come back since.

That gap has a name, and it isn't a marketing problem. It's user activation, and it's where most first-time founders lose the users they worked hardest to get. You can rewrite your landing page every week for a year and it won't help, because the people you're losing already said yes. They created an account. They got inside. Then something between the signup button and the thing your product actually does made them close the tab.

Here's the part that stings. User activation is usually the cheapest number in your funnel to move, and it's the last one founders look at. Traffic feels like progress. Signups feel like progress. Activation feels like admitting the product didn't land.

Let's fix that.

What is user activation and why does it matter more than signups?

User activation is the point where a new user experiences your product's core value for the first time. Not the point where they create an account. Signup is a transaction. Activation is the moment the person understands why they'd come back tomorrow.

Reforge splits the gap between those two things into three separate moments, and the distinction is the most useful thing you'll read on this topic:

The setup moment. The user has done the minimum work required to be able to receive value. Connected the bank account. Imported the contacts. Picked a template.
The aha moment. The user experiences the value for the first time. The invoice actually goes out. The report actually generates. The inbox actually hits zero.
The habit moment. The user comes back without being reminded, because the trigger fires and the loop closes on its own.

Most founders build onboarding for the first moment and assume the other two happen automatically. They don't.

Why does this matter more than signups? Because signups are a lagging indicator of your marketing and activation is a leading indicator of your revenue. A user who never activates is worse for you than one who never signed up at all. You paid to acquire them, they sit in your dashboard inflating the number, and their silence makes the product look healthier than it is. Five hundred dead accounts read as traction on a chart. They're not traction. They're evidence.

What's a good activation rate for an early-stage startup?

Most published benchmarks put median B2B SaaS activation somewhere between 30% and 40%. That number is close to useless for a startup with fewer than a few hundred signups, and it's worth understanding why before you go chasing it.

Userpilot's benchmark data puts the average activation rate at 37.5% and the median at 37%, drawn from 62 B2B companies. Read the sample carefully. Those are companies that had already installed an onboarding tool and configured an activation dashboard inside it. That's a self-selected group of teams who were already paying attention to this. Comparing your number to theirs is like comparing your 5K time to the people who showed up to a running club.

The more useful benchmark, because the sample is bigger and the definition is unambiguous, is free-to-paid conversion. Kyle Poyar analyzed 200 self-serve products in January 2026 with the teams at ProductLed and ChartMogul. Median conversion came out at 8%. But the distribution is bimodal, which is the actual finding: roughly 20% of free trial products convert below 2.5%, and roughly 23% convert above 25%. Almost nobody is at the median. There's about a 10x spread between the top and bottom of the range.

Their breakdown by model:

Model	Good	Great
Freemium	3-5%	8-12%
Free trial, no credit card	4-6%	10-15%
Free trial, credit card required	25-35%	50-60%
Reverse trial	4-6%	8-12%

Notice how much of the variance is explained by the model rather than the product. A credit-card-gated trial converts at five times the rate of an ungated one, and it isn't because the product got better. It's because you filtered the population before they walked in.

So what's a good activation rate for you? Your number from last month. That's the only benchmark that will change your behavior, and it's the only one you can actually verify.

How do you find your product's aha moment?

Compare what your retained users did in their first session against what your churned users did, then look for the behavior that separates the two groups. That's the method behind every famous example you've read about.

Facebook found that users who connected with seven friends in ten days stuck around. Slack found that teams who exchanged 2,000 messages almost never left. Both numbers came from looking backward at cohorts that had already retained and asking what they had in common.

You don't have Facebook's data. You have forty users. Do it anyway, by hand.

Open a spreadsheet. Column one: every user who has come back three or more times. Column two: every user who signed up and never returned. Now write down what the first group did in their first session that the second group didn't. Twelve people against twenty-eight isn't statistics. It's pattern recognition. And at this stage pattern recognition beats statistics, because you can call all twelve of those people and ask them directly, which is something no analytics tool will ever do for you.

Reforge has a rule worth stealing here: if you can't describe your aha moment in a single sentence, you haven't defined it. "The user sends their first invoice and it gets paid" is a definition. "The user engages meaningfully with the core workflow" is a sentence that means nothing and will let you avoid the question for another quarter.

Once you have the sentence, map the entire path from signup to that moment. Every screen, every field, every decision you force the user to make. You can do this in a spreadsheet, a Notion doc, or a planning tool like Foundra that walks first-time founders through the go-to-market and customer journey sections. The format matters far less than doing it before you start changing things, because you can't shorten a path you haven't written down.

Why do most activation metrics turn out to be wrong?

Because correlation gets mistaken for causation, and the mistake is invisible until you've spent three months acting on it.

Mixpanel put this bluntly: magic numbers are an illusion. A useful illusion, but an illusion. Facebook's number could just as easily have been ten friends in twelve days, or five friends in one day. The threshold was a rallying point for teams, not a discovered law of human behavior.

Here's the trap in practice. Users who were always going to stick around also happen to add friends, connect integrations, and invite teammates. Those behaviors might be symptoms of intent rather than causes of retention. So you build popups and nudges and progress bars to push new users toward the number, activation climbs, and four-week retention doesn't move at all. You optimized a symptom.

The test is simple even if running it isn't. Change the input and check whether the output moves. Cohort A gets the nudge, cohort B doesn't, and then you compare retention four weeks later, not the metric you just nudged. If retention is flat, your aha moment is a correlation and you need to go back to the spreadsheet.

There's a second failure mode, and it's more common in B2B. Founders define activation as something the user does for them rather than something the product does for the user. Completed profile. Verified email. Connected calendar. Invited a teammate. Those are all setup steps. Setup is not aha. When you confuse the two you end up shipping an onboarding checklist that feels like homework, and users are very good at recognizing homework.

What actually moves activation when you have no growth team?

Cut steps between signup and value, defer everything that can wait, and do as much of the setup work for the user as you can. That's most of it. The rest is copy.

Five things that reliably work, in rough order of effort:

1. Delete signup fields. HubSpot's data showed that dropping from four fields to three improved form completion by roughly 50%. MarketingExperiments found a five-field form beat a seven-field form, which in turn beat a ten-field form. But there's a real counterpoint from CXL: one team cut fields and lost 14% of conversions, because they removed the fields users actually wanted to fill in and kept the annoying ones. The rule isn't "fewer fields." It's "remove every field that asks the user to work for you, keep the ones that let you personalize what happens next."

2. Move the account wall behind the first value moment. Duolingo lets you complete a lesson before it asks you to create an account. Figma lets you open and look at a file. By the time the request arrives, the person has already invested effort and seen a result, and that's a completely different person from the one who landed on your homepage thirty seconds ago.

3. Pre-fill with sample data. The empty state is the single most common activation killer in B2B software. A blank dashboard asks a new user to imagine the value. A dashboard populated with realistic demo data shows it to them, and then they only have to decide whether they want their own version.

4. Do the setup for them. Import the data. Connect the accounts. Configure the defaults. If your setup moment costs the user twenty minutes of manual work, no amount of tooltip copy will save it. That's not an onboarding problem, it's a product decision you haven't made yet.

5. Write one email that does one job. Not a seven-email drip sequence. One email, sent within the hour, linking directly to the single action you identified as the aha moment. Founders love building sequences because sequences feel like systems. One good email outperforms most of them.

Should you onboard your first users by hand?

Yes, and for much longer than feels reasonable. Manual onboarding is the highest-signal, lowest-cost activation work available to a founder with fewer than a few hundred users, and almost nobody does enough of it.

Superhuman is the case study everyone cites, and for good reason. A $30-per-month email client in a market where email is free, built keyboard-first with a punishing learning curve. Users who never learned the shortcuts churned fast, and no self-serve flow could teach them fast enough. So every new user got a 30-minute one-on-one video call with an onboarding specialist who imported their email, configured the product around their actual workflow, taught them the shortcuts, and got them to inbox zero before the call ended. At its peak the company had around 20 people doing nothing else.

On a spreadsheet that looks like a terrible business. It worked because a user who reaches inbox zero once, with someone walking them through it, understands the product in a way no tooltip has ever achieved. Those users became the word-of-mouth engine.

The second benefit is the one founders underrate. When you personally walk thirty people through your product, you watch them get stuck in the same three places. That's not customer support. That's your roadmap, delivered in higher resolution than any analytics tool will ever give you.

When do you stop? When you can predict what the user is about to say before they say it. Until then, keep doing the calls.

How do you measure activation when you only have 40 users?

Define the event in one sentence, count it manually every week, and resist the urge to build a dashboard for it.

The whole process:

Write the definition. One sentence, one event, no compound conditions. If it needs an "and," you have two metrics.
Instrument the single event. PostHog's free tier and Amplitude's starter plan both handle this. So does a spreadsheet with one row per user, and at forty users the spreadsheet is faster.
Count weekly cohorts, never all-time. All-time activation rate blends your best week and your worst week into one number that can't move. Weekly cohorts show you whether last Tuesday's change did anything.
Track the absolute number next to the percentage. Six of fifteen is 40%, and 40% looks like a respectable benchmark, and it is six people. Keep both numbers visible so you don't mistake a rounding error for a trend.
Call the ones who didn't activate. At this size, five conversations tell you more than five hundred sessions of heatmap data. Ask what they expected, and where they stopped.

One caution before you spend a month on this. Activation sits downstream of product-market fit, not in place of it. If people activate cleanly, hit your aha moment, and still don't come back, onboarding isn't the problem. The value itself is. That's a different investigation, and it's covered in more depth in our guide to finding product-market fit.

Key takeaways

Activation is the first time a user gets value, not the moment they create an account. Setup, aha, and habit are three distinct moments and most onboarding only handles the first.
Published activation benchmarks around 37% come from small, self-selected samples. Your number from last month is the only benchmark that will change your behavior.
Find your aha moment by comparing what retained users did in session one against what churned users didn't. Forty users is enough to spot a pattern, and small enough to call every one of them.
Magic numbers are correlations until you prove otherwise. Nudge one cohort, leave another alone, and check four-week retention rather than the metric you nudged.
The fixes that work are structural, not cosmetic: fewer signup fields, the account wall moved behind the first value moment, sample data instead of empty states, and setup work done for the user.
Onboard your first hundred users by hand. It guarantees activation, and it hands you a roadmap built from watching people get stuck in the same three places.

Frequently asked questions

What's the difference between activation and onboarding?

Onboarding is the experience you design. Activation is the outcome you're measuring. You can have a beautifully built onboarding flow with a terrible activation rate, which usually means the flow is teaching people how to use the product instead of showing them why it's worth using.

How long should it take a user to activate?

As fast as your product allows, and the real range depends entirely on what you sell. A note-taking app should activate someone in under two minutes. A payroll platform might take a week because the setup really does require data you don't have yet. The question worth asking isn't "how fast is normal," it's "what in our path is slow for reasons that aren't real."

Should I require a credit card for my free trial?

It depends on which number you care about. Credit-card-gated trials convert at 25% to 35% versus 4% to 6% for ungated ones, but you get far fewer trials to begin with. Gating filters for intent, which is useful when your sales motion needs qualified conversations and expensive when you're still learning what people do with the product.

What's a reverse trial?

Everyone starts on the paid tier for a fixed window and then drops to a free plan when it expires, rather than losing access entirely. It combines the urgency of a trial with the user volume of freemium, and it converts around 4% to 6% typically and 8% to 12% at the top end. Only about 7% of self-serve products use it as their primary model, so it's still an underused option.

Can I improve activation without changing the product?

Partly. Copy, email timing, and the order of your onboarding steps are all cheap to test and can move the number a few points. But if your setup moment requires twenty minutes of manual data entry, no amount of copy will fix it. At some point activation work becomes product work, and the founders who accept that early save themselves a quarter.

How many users do I need before activation data means anything?

For statistical confidence, more than you have. For useful decisions, about thirty. Below that, skip the percentages entirely and just talk to people one at a time, because the qualitative signal at that scale is stronger and considerably faster than anything you can compute.

How to Prioritize Features When You Have No Data

Spencer Claydon — Sun, 23 Aug 2026 15:11:48 +0000

You've got a list of thirty things to build and enough time for four of them. Every framework you find online tells you to score each feature by how many users it reaches. You have nine users. Two of them are your friends.

That's the real problem with feature prioritization advice for first-time founders. The frameworks themselves are fine. They were just written by product managers at companies with analytics dashboards, support ticket volume, and someone whose full-time job is user research. You have a Notion board, a Slack channel with three customers in it, and a hunch.

So here's how to prioritize features when the inputs those frameworks want don't exist yet. We'll cover the four frameworks worth knowing, which one fits your stage, and the move that beats scoring anything at all.

Why is prioritizing features so hard before you have users?

Because prioritization frameworks are compression tools, and you have nothing to compress. They take a large pile of evidence and squeeze it into a ranked list. With no evidence, scoring just launders your existing opinion into a number that looks objective.

Here's the cost of getting it wrong. Pendo's 2019 Feature Adoption Report analysed usage across 615 SaaS products and found that 56% of features were never used at all, another 24% were rarely used, and only 12% were used frequently. That 12% drove roughly 80% of daily usage. The Standish Group's earlier research landed in similar territory: 45% never used, 19% rarely.

Read that again. Those are shipped features. Somebody scoped them, argued for them, built them, tested them, and launched them. Most of it was waste, at companies with far better information than you have.

The point isn't that prioritization is pointless. It's that being wrong is the default outcome, even with good data. Your job right now isn't to pick correctly. It's to pick cheaply and find out fast.

What are the main feature prioritization frameworks?

Four frameworks cover almost everything you'll run into: RICE, ICE, MoSCoW, and Kano. They answer different questions, which is why people argue about which one is "best" when they aren't actually substitutes for each other.

RICE came out of Intercom in 2018, written up by Sean McBride when he was a product manager on the growth team. The formula is (Reach × Impact × Confidence) / Effort. Reach is how many people the thing touches in a set period. Impact is how much it moves the needle per person. Confidence discounts the whole score by how much you're guessing. Effort is person-days or person-weeks. It was built to settle internal arguments about which experiment to run next.

ICE is RICE with Reach taken out: Impact × Confidence × Ease. Faster, rougher, and much better suited to a solo founder triaging a long list in an afternoon.

MoSCoW is older than both. Dai Clegg created it at Oracle in 1994 and it became a core technique in DSDM. You sort work into Must have, Should have, Could have, and Won't have this time. DSDM's guidance is that Musts should eat no more than 60% of your effort budget, with Coulds sitting around 20% as a contingency buffer. If everything is a Must, nobody has made a decision.

Kano doesn't rank anything. It classifies. Basics are expected and only noticed when they're broken. Performance features are the ones where more is better. Delighters are unexpected and create loyalty. It answers a different question: not "what next" but "what kind of thing is this".

Framework	Question it answers	Needs real data?	Best for
RICE	What returns most per unit of work?	Yes, especially Reach	Post-PMF teams with analytics
ICE	What should I look at first?	No	Solo founders, fast triage
MoSCoW	What gets cut when time runs out?	No	Fixed deadlines and launches
Kano	What kind of value is this?	Some, via user research	Deciding what to research next

Which prioritization framework should a first-time founder use?

Use ICE for triage and MoSCoW for scoping, and leave RICE alone until you have real usage numbers. RICE's entire advantage over ICE is the Reach term, and Reach is the one input you can't estimate before launch without simply inventing it.

Try it and the failure mode shows up in about four minutes. Two features, both reaching "all users", both scored Impact 3, both at 80% Confidence. The formula collapses down to Effort, and you've built an elaborate way of saying "do the easy one first". Which is often the right answer. It just doesn't need four variables and a spreadsheet.

Here's what I'd do under 100 users:

Dump everything into one list. No editing, no judgement, ten minutes.
ICE-score it fast. One minute per item, first instinct, no debate.
Take the top ten and force them through MoSCoW against your next real deadline.
Delete the bottom half of the list. Permanently.

That last step matters more than the scoring does. A backlog you never delete from turns into a guilt archive. You'll re-read the same forty dead ideas every planning session for a year and feel worse each time.

Where you keep the list matters less than keeping one at all. A spreadsheet is fine. So is a Linear backlog, a Notion database, or a planning tool like Foundra that walks first-time founders through the roadmap and go-to-market pieces in the same place. Pick whichever one you'll actually open on a Monday morning.

How do you score features when you don't have user data?

You substitute observed behaviour for measured behaviour. Not opinions. Not feature requests. Things people actually did.

Directional evidence you can collect this week without any analytics:

Repeat volume. Count how many separate people raised the same thing unprompted. Five different humans beats one loud customer, every time.
Workarounds. If someone built a spreadsheet, a Zapier chain, or a manual weekly ritual to route around your product, that's a feature request written in effort instead of words. It's the strongest signal you can get for free.
Lost deal reasons. Write down why each deal died, in the customer's language, not yours. Do it for a month and a ranked list falls out of it.
Churn exit answers. Even a single "why are you leaving" text field beats guessing.
Trials that came back. Someone who bounced and returned is telling you exactly what changed their mind. Go ask them.

Then be brutal on the Effort side. This is where founder plans quietly die. The research on software estimation is grim and remarkably consistent: developers estimate roughly 20% to 30% below actual, mean effort overrun sits near 30% and hasn't improved in decades, and when engineers report 90% confidence in an estimate, the real hit rate is closer to 60% to 70%.

So double whatever number you're given. If you're a non-technical founder estimating someone else's work, double it again. An ICE score built on an optimistic Effort figure will systematically rank the wrong things first, because that error sits in the denominator where it does the most damage.

Should you fix the scope or fix the time?

Fix the time. It's the highest-return change most small teams can make to how they plan, and it sidesteps the estimation problem instead of trying to solve it.

Basecamp's Shape Up, written by Ryan Singer and published free in 2019, calls this an appetite. Instead of asking how long a feature will take, you decide how much time it's worth: a small batch of one or two weeks, or a big batch of a full six-week cycle. Then you cut scope until it fits. Fixed time, variable scope.

Why does this work better than estimating when you're a team of three?

Estimates are predictions, and you've already seen how badly those perform. Appetites are decisions, and you can make a decision correctly today. "Search is worth two weeks to this business" is a claim about your priorities that you can defend. "Search will take two weeks" is a claim about the future that's wrong most of the time.

It also changes the conversation with whoever's building. "Can you get this done in two weeks?" invites a yes and a broken promise. "We have two weeks. What's the version that fits?" invites design work. Those are completely different meetings.

You don't need six-week cycles at your size. Two weeks is plenty. What matters is that the number comes first and the scope bends to meet it, not the other way around.

How do you turn customer feedback into a priority order?

Segment the feedback before you count it. All feedback is not equal, and averaging it is how products turn to mush.

Rahul Vohra's approach at Superhuman is the cleanest version of this I've seen. He used Sean Ellis's survey question: how would you feel if you could no longer use this product? Very disappointed, somewhat disappointed, or not disappointed. The common rule of thumb is that 40% "very disappointed" means you've found product-market fit.

The prioritization move is what he did with the three groups:

Very disappointed users are your fans. Their feedback tells you what to reinforce.
Somewhat disappointed users are on the fence. Their feedback tells you what's stopping them from becoming fans. This is your growth segment.
Not disappointed users get ignored. Not politely deprioritized. Ignored. They aren't your customer, and building for them will break the product for the people who are.

Superhuman then split the roadmap roughly 50/50 between reinforcing what the fans loved and clearing what held the fence-sitters back. Their score moved from 22% to 58% in under a year.

The uncomfortable part is that third bullet. Every founder I've watched run this survey wants to fix the complaints from the "not disappointed" group, because those complaints are the loudest, the most specific, and the easiest to act on. Resist it. And if you can't tell yet who your fans even are, that's your actual priority this month, not the feature list. Start with product-market fit before you write another line of code.

What makes feature prioritization go wrong?

Four failure modes account for most of the damage, and all four are behavioural rather than analytical.

Everything becomes a Must. MoSCoW only works if the Must bucket hurts. DSDM's 60% effort cap exists precisely because teams inflate that bucket until the exercise means nothing. If your Musts are 90% of the plan, you haven't prioritized, you've written a wish list with better formatting.

Scoring theatre. A number computed from three guesses is still a guess. It just feels harder to argue with, which is worse, because now the loudest person has arithmetic on their side. Keep the confidence multiplier honest and let low-confidence items score badly.

The customer with the biggest logo wins. One enterprise prospect asks for SSO and it jumps the queue on the strength of a deal that hasn't closed. Sometimes that's right. Usually it's a roadmap being written by someone who isn't paying you yet.

The backlog never expires. Ideas have a shelf life. A feature request from eleven months ago was made about a product that no longer exists and a market that has moved. Put a date on every item and delete anything untouched for a quarter. Nothing valuable is ever lost this way, because good ideas come back on their own.

Key takeaways

Roughly 80% of shipped software features are rarely or never used. Being wrong is the base rate, so optimise for finding out quickly rather than for picking perfectly.
RICE needs Reach, and Reach needs users. Under 100 users, use ICE for triage and MoSCoW for scoping.
Double every effort estimate. Developers run 20% to 30% low on average, and that error lands in the denominator of every score you calculate.
Set an appetite instead of taking an estimate. Decide what a feature is worth in weeks, then cut scope to fit.
Segment feedback before you count it. Build for the people who'd be very disappointed to lose you, and ignore the people who wouldn't care.
Delete aggressively. A backlog with no expiry date becomes a guilt archive that slows down every planning session.

FAQ

What is the best feature prioritization framework for a startup?

For pre-product-market-fit startups, ICE for quick triage plus MoSCoW for scoping a release. RICE is better once you have analytics good enough to estimate reach, which usually means a few hundred active users at minimum.

What's the difference between RICE and ICE?

RICE adds a Reach term and divides by Effort: (Reach × Impact × Confidence) / Effort. ICE is Impact × Confidence × Ease. RICE is more rigorous and slower. ICE takes about a minute per item and is usually enough when your feature list is under 30 items.

How many features should be in a Must have bucket?

DSDM's guidance is that Must haves should consume no more than 60% of your available effort, leaving roughly 20% for Could haves as a buffer. If your Musts exceed 60%, you've over-classified and no real trade-off has been made yet.

Should I build what customers ask for?

Build what they need, which is often different from what they ask for. Customers describe solutions; your job is to find the problem underneath. Watch for workarounds and repeated complaints from multiple people rather than acting on single feature requests.

How do I say no to a feature request without losing the customer?

Tell them what you're doing instead and why, with a date. "We're not building that this quarter because we're fixing onboarding, which three of you flagged. I'll come back to you in October." Most people accept a clear no with reasoning. What they hate is silence.

How often should I re-prioritize?

Every two to six weeks, tied to whatever cycle you build in. Any more often and you never finish anything. Any less and you're acting on stale information. Re-scoring mid-cycle is usually a sign the appetite was set wrong.

How to Run a Smoke Test for Your Startup Idea

Spencer Claydon — Sat, 22 Aug 2026 15:21:03 +0000

You can find out whether anyone wants your product in a weekend. Not whether they think it's a nice idea. Whether they'll take an action that costs them something.

That's a smoke test, and it's the cheapest way to kill a bad startup idea before it eats a year of your life. Most first-time founders skip it because building feels like progress and asking feels like stalling. Then twelve months later they launch to silence and call it a marketing problem.

It usually wasn't. CB Insights has been publishing startup post-mortems for over a decade and "no market need" sits at the top of the list nearly every year, showing up in roughly four out of ten failures. That's not a product quality problem. It's a demand problem. And demand problems are testable before you write a line of code.

Here's how to run the test properly, including the parts most guides skip: how much traffic you actually need, what a passing number looks like, and the four ways a smoke test will lie to you if you let it.

What is a smoke test for a startup idea?

A smoke test is a small public experiment that measures whether real people will take a costly action toward a product that doesn't exist yet. Costly means it costs them time, money, or social risk. Clicking a button, entering an email, or putting down a card are all costly in different amounts.

The term comes from hardware. You plug the board in, you see whether it catches fire. The startup version is the same logic. You put the smallest honest representation of your product in front of strangers and watch whether anything happens.

What makes it a test rather than marketing is the threshold. You decide before you launch what number means yes and what number means no. Without that, you're just collecting data you'll rationalize later. And you will rationalize it. Everyone does.

How is a smoke test different from an MVP?

A smoke test measures demand. An MVP delivers value. They answer different questions and they cost wildly different amounts.

An MVP is a working product, stripped down. Someone can use it and get something out of it. That takes weeks at minimum, usually months, and it commits you to a technical direction before you know whether the direction matters.

A smoke test delivers nothing. It's a page, a video, a button, a form. Nobody gets a product at the end. What you get is a number.

This distinction matters more in 2026 than it did five years ago, because AI coding tools have collapsed the cost of building a rough product. Plenty of founders will tell you it's faster to just vibe-code the thing than to test for it. Sometimes that's true. But shipping a working product creates gravity. Once it exists you'll defend it, iterate on it, and try to market your way out of a demand problem instead of walking away. A test you can throw out is worth more than a product you can't.

If you're not sure which stage you're at, our guide on how to validate a startup idea covers the sequence in more detail. Smoke tests belong near the front of it.

What does a good smoke test actually look like?

There are four formats worth knowing, and they measure progressively stronger signals.

The landing page test. One page describing the product, one call to action, one email capture. This is the default and it's the weakest of the four, because an email address is cheap to give away.

Joel Gascoigne's version of this for Buffer is the one everyone cites, and it's worth understanding why it worked. He didn't just build a landing page. He built two, then three. The first page described the product and had a "Plans and Pricing" button. Clicking it took you to a page that said the product wasn't built yet, and asked for your email. Then he added a middle page with actual prices, so visitors had to pick a plan before they could sign up. That last step is the whole trick. He wasn't measuring interest. He was measuring willingness to look at a price and keep walking.

He collected 120 emails over roughly seven weeks. That's a small number. But 50 of those people became users at launch, and he had a paying customer within three days.

The fake door test. You add a button or menu item for a feature inside a product you already have. Clicking it says the feature is coming soon and offers a waitlist. This is stronger than a landing page because the person wasn't recruited by an ad. They found the door on their own while trying to do something else.

The demo video test. You show the product working without building it. Drew Houston's Dropbox video is the canonical case: file sync across operating systems was brutally hard to build, so he made a four minute screencast of the experience instead and posted it to Digg and Hacker News. The beta waitlist went from around 5,000 to 75,000 close to overnight.

The reason that story gets misused is that the video wasn't the clever part. The audience was. He put it in front of people who were already living with the exact problem, every day, and who had the vocabulary to recognize the fix instantly.

The preorder or deposit test. You take money, or an explicit commitment to pay, before the product exists. This is the strongest signal available short of shipping, and it's the one almost nobody runs, because it's uncomfortable and because you have to be ready to refund everyone.

Run the weakest test you can get a clean answer from, then escalate. If a landing page can't clear its threshold, a preorder page definitely won't.

How much traffic does a smoke test need to mean anything?

Around 300 to 500 targeted visitors is the working floor for a directional read. Below that, normal variation swamps the signal and you're reading tea leaves.

Understand what that number is and isn't. Three hundred visitors will not give you statistical significance in the formal sense. Proper A/B testing usually wants closer to 1,000 visitors per variant before you can trust a p-value under 0.05, and if your site sees fewer than 10,000 visitors a month you'd need a conversion lift over 30 percent for a test to declare a winner at all.

But you're not A/B testing. You're asking a much blunter question: is this closer to 0 percent or closer to 10 percent? That question survives a small sample, as long as you treat the answer as a range rather than a decimal.

The word that matters most in "300 targeted visitors" is targeted. Three hundred clicks from a subreddit full of your actual users tells you something. Three hundred clicks from a cheap traffic source tells you what cheap traffic does. Traffic quality is the variable that ruins more smoke tests than sample size ever will.

What conversion rate counts as a pass?

Set your threshold before you launch, then use benchmarks only to sanity check it. Working ranges as of 2026:

Signal	Weak	Worth pursuing	Strong
Fake door click inside an existing product	under 2%	2 to 5%	above 5%
Landing page email capture, cold traffic	under 2%	2 to 5%	above 8%
Landing page email capture, warm traffic	under 3%	3 to 8%	above 10%
Preorder or deposit, any traffic	under 1%	1 to 3%	above 3%

For context, the median dedicated landing page across all industries converts at roughly 4 percent, and the top quartile clears 11 percent. So a 4 percent email capture on cold traffic isn't evidence of a great idea. It's evidence you built an average landing page.

Here's the part that separates a real test from theater. Your threshold shouldn't come from a benchmark table. It should come from your own math. Work backward: what does a customer need to be worth, and how many do you need in year one, and what conversion rate does that imply given what traffic costs you? If a 5 percent signup rate still leaves you with unprofitable unit economics, then 5 percent is a fail even though the table calls it strong.

That backward calculation is the actual work, and it's worth doing in something structured rather than in your head. A spreadsheet is fine. So is Causal, LivePlan, or a planning tool like Foundra that walks first-time founders through the financial model and the validation plan in the same place. The tool matters less than writing the number down somewhere you can't quietly move it later.

How do you run a smoke test in a weekend?

Six steps, and the first one is the one people skip.

Write the hypothesis and the threshold. One sentence each. "At least 5 percent of visitors from r/smallbusiness will enter an email to join the waitlist." If you can't write the threshold, you don't have a test.
Build the page. Carrd, Framer, Webflow, or plain HTML. Headline, the problem in the reader's words, three or four specifics about the solution, one call to action. Ninety minutes, not two days.
Add a price. This is the Buffer move. Even a fake price on a "plans" page filters browsers from buyers, and it costs you one extra screen.
Instrument it. Plausible, Fathom, or GA4. You need visitors, clicks on the CTA, and completions. Three numbers.
Drive targeted traffic. Communities where your users already are, direct outreach, or paid. Budget for this properly: Reddit CPCs run roughly $0.50 to $3.00, and B2B and startup subreddits sit at the higher end near $1.50 to $3.00. That's $450 to $900 for 300 clicks. Google Search is worse for B2B SaaS, averaging around $5.34 per click in 2026 and often much more, which puts 300 clicks north of $1,600. Organic and community traffic is free but slower and biased toward people who already like you.
Stop at your sample size and read the number. Not before. Not after you've had time to talk yourself into it.

What makes a smoke test lie to you?

Four failure modes, in rough order of how often they wreck a result.

Wrong traffic. You posted in a founder community and got founders, not customers. Founders sign up for everything. This is the most common way a smoke test produces a false positive.

Measuring the wrong thing. Email capture is a proxy for intent, and it's a weak one. If your threshold was built on emails and your business needs paying customers, you've validated a mailing list.

Moving the goalposts. You said 5 percent, you got 2.8 percent, and now you're explaining that the traffic was unusual and the copy was rushed. Sometimes that's true. Write it down as a new hypothesis and run the test again rather than editing the old one.

Burning trust. Fake doors involve real deception, and it's fair to be careful with them. The rule that holds up: the post-click message should be immediate, honest, and useful. Say the feature isn't built, say why you're testing, offer the waitlist. Don't run fake doors repeatedly on the same audience, and don't run them at all in flows touching pricing, eligibility, health, money, or someone's job. People are surprisingly generous about being told the truth. They're not generous about dead ends.

Key takeaways

A smoke test measures demand, not usability. Nobody gets a product at the end. You get a number.
Decide your pass threshold before you launch, and derive it from your own unit economics rather than a benchmark table.
Around 300 to 500 targeted visitors is the working floor. Targeted is the load-bearing word.
Add a price step. It's the cheapest way to separate curiosity from intent, and it's what made Buffer's test useful.
Escalate signal strength: landing page, then fake door, then preorder. Don't start with the hardest one.
Budget for traffic. Three hundred Reddit clicks in a startup subreddit costs $450 to $900. Free traffic isn't free, it's just slower and more biased.
A failed smoke test is a good outcome. It cost you a weekend instead of a year.

FAQ

How long should a smoke test run?
Until you hit your sample size, usually three days to three weeks depending on traffic source. Set the sample size in advance and stop there. Running longer to chase a better number is how you turn a test into a hope.

Is a fake door test dishonest?
It involves deception, so it depends entirely on execution. It's defensible when the post-click message is immediate and truthful, the test isn't repeated on the same users, and it stays out of sensitive flows like billing, health, and employment. It's not defensible when it dumps people into a dead end with no explanation.

Can I smoke test without spending money on ads?
Yes. Community posts, direct outreach, cold email, and existing audiences all work, and the traffic is often higher quality. The tradeoff is speed and bias: people who know you convert better than strangers, which inflates your result.

What if my smoke test fails?
Figure out whether the idea failed or the test did. Wrong audience, unclear copy, and a mismatched call to action all produce false negatives. If the test was clean and the number was well below threshold, that's your answer, and it's worth more than the year you didn't spend.

Do I need a real product name and brand?
No. A working name and a clean page are enough. Spending two weeks on a logo before you know if anyone wants the thing is the exact failure mode a smoke test exists to prevent.

Should I smoke test if I can build the product in a week with AI tools?
Often yes, because the cost of building isn't the only cost. A built product creates commitment, and commitment makes you market harder instead of walking away. If you can truly build and abandon without attachment, build. Most people can't.

How to Find Design Partners for Your Startup

Spencer Claydon — Fri, 21 Aug 2026 17:04:27 +0000

You've got a problem hypothesis, a rough sense of who has it, and no product. The advice you keep hearing is "go talk to customers." Fine. But talking to customers produces a folder of Zoom recordings and a vague feeling that you're onto something. Design partners produce a product somebody pays for.

That's the difference, and it's the reason design partners are worth more to a first-time founder than another round of discovery calls. A design partner is a target customer who agrees to help shape your product before it exists, in exchange for early access, real influence over what gets built, and usually a price they'll never see offered again.

Bessemer published a piece in May 2026 arguing that this is the pre-launch edge most AI founders ignore. I'd push that further. If you have no distribution, no brand, and no logo anyone recognizes, a design partner program is the only validation method that ends in revenue instead of a slide about "strong customer interest."

Here's how to find design partners, what to actually offer them, and how to structure the arrangement so it doesn't quietly turn into eight months of unpaid consulting.

What is a design partner, and how is it different from a beta user?

A beta user tests a product that already exists. A design partner shapes a product that doesn't. That's the whole distinction, and it changes everything about how you recruit, what you ask for, and what you get back.

Beta programs answer one question: does this work? Design partner programs answer three much better ones: what should we build, for whom, and at what price? The relationship is higher touch. You're not shipping them a signup link and watching a dashboard. You're on a call every other week, watching them work, arguing about what matters.

There's a third category people confuse with both: the advisor. Advisors give opinions and get equity. Design partners give access to their actual workflow, their actual budget, and their actual procurement process, and they get a discount. Those are very different trades. Don't mix them up, and don't hand out equity for something a discounted contract buys.

The tell that you have a real design partner and not a friendly stranger: they change their behavior. They put your half-built thing in front of their team. They complain when it breaks. Someone who only ever says nice things on calls is a fan, not a partner.

When should you start looking for design partners?

Before you build. The right moment is when you have a clear problem hypothesis and no solution, because every week you build without a partner is a week you might be building the wrong thing.

Founders get this backwards constantly. They spend four months on an MVP, then go looking for people to react to it. By then you've already made a hundred decisions a design partner could have made for you, and now you're emotionally attached to all of them.

The two examples Bessemer highlights both started absurdly early. Ada's cofounders, Mike Murchison and David Hariri, went and worked the support desks at seven different companies before writing a line of code. Those seven companies became Ada's first design partners. Strella's cofounders, Lydia Hylton and Priya Krishnan, recruited 12 design partners before their AI interviewer was fully built.

So the honest answer is: earlier than feels comfortable. Yes, you'll be selling something that doesn't exist. That's the point. If nobody will commit time to a described product, the built version won't fix that.

How many design partners do you actually need?

Between five and 12 is the range most practitioners land on, and there's decent reasoning behind it. You need enough partners to see a pattern rather than one loud opinion, and few enough that you can stay high touch with all of them.

Strella ran a cohort of 12. Ada worked with seven. Some write-ups push for as few as three deep, paid relationships in a single ICP over a hundred shallow ones, and that's defensible too if your sales cycle is long and your ACV is big.

What actually matters is whether they're the same kind of customer. Five partners in one narrow segment will teach you more than 15 scattered across three industries, because with the scattered group every piece of feedback is a special case and you can't tell signal from noise. Pick a segment first. Recruit inside it.

One more constraint nobody mentions: a design partner costs you real hours. Biweekly calls, feedback synthesis, custom hand-holding when your product breaks. Twelve partners at two hours a month each is a part-time job. If you're solo, start at five.

How do you find design partners when nobody knows who you are?

Cold outreach, and it's not a fallback. It's the better option. A stranger who says yes with no relationship and no social obligation is a far more honest signal than a friend doing you a favor.

Strella recruited all 12 of its design partners through cold LinkedIn outreach and deliberately skipped warm intros. Lydia Hylton's reasoning is worth stealing: it's much harder to convince a stranger on the internet than someone doing you a favor, so if you can get a stranger to become a design partner, you likely have something.

The channels that work, roughly in order of yield:

LinkedIn search by exact title and industry. Not "operations." "Head of Revenue Operations at a 50 to 200 person fintech." Specificity is what makes the message land.
Communities where your ICP complains. Slack groups, Discords, subreddits, industry newsletters. Read for a few weeks first. Then reach out to the people whose posts describe the exact problem you're solving, quoting their post back to them.
Job postings. A company hiring three people to do the thing you automate has just published its pain in public, with a budget attached.
Accelerator cohorts and alumni, if you're in a program. High trust, and half of them are either your ICP or one intro away from it.
Investor intros. Useful, but treat the yes with suspicion. Some of it is politeness toward your investor.

Your outreach message should ask for a 20 minute conversation, not a demo. You don't have a demo. Name the pain in the first line, say what you're trying to build, say you're looking for a small number of companies to shape it, and stop. Four sentences. The founders who get replies are the ones who sound like they already understand the job, not the ones who sound like a product launch.

Before you send anything, write down who you're targeting and why, because your outreach is only as good as your segment definition. You can do that in a spreadsheet, a Notion doc, or a planning tool like Foundra that walks first-time founders through ICP definition and go-to-market alongside the rest of the plan. The format matters less than actually writing it down, since an unwritten ICP quietly expands to "anyone who replies."

What do you offer a design partner, and should they pay?

Offer influence first, price second. The thing a good design partner wants most is a product built around their workflow instead of somebody else's, and that's something only you can give and no incumbent will.

The standard package looks something like this: free or heavily discounted access during the build phase, locked-in preferential pricing when you launch (commonly cited ranges land around 30% to 50% off list for the first 12 to 24 months), direct access to the founders, and a real seat at the roadmap table.

Should they pay something during the program? If you can get it, yes. Payment is the cleanest possible signal of intent, and practitioner write-ups tend to suggest that if you charge, charge at least 10% of expected contract value, because below that the commitment isn't real. But a paying design partner isn't mandatory. What is mandatory is a commitment that costs them something: guaranteed hours, workflow access, or a named executive sponsor who'll be on the calls.

What you don't offer is equity. Advisors cost equity. Design partners cost a discount and your time. Handing out warrants to your first five customers is a cap table problem you'll be explaining for years, and it buys you nothing you couldn't get with a better discount.

And the deal has to expire. Indefinite free access isn't a design partnership. It's a support contract you're paying for.

What goes into a design partner agreement?

One page, covering six things: what you're testing, what access they're giving you, the meeting rhythm, how long it runs, what happens to feedback and IP, and what the conversion conversation looks like when the term ends.

You don't need to draft this from scratch. Common Paper publishes a free standard Design Partner Agreement, currently at version 1.3, put together by a committee of attorneys from both vendor and procurement sides. It uses a short negotiated cover page plus standard terms hosted online, which means you're arguing about four fields instead of 14 pages.

The clause first-time founders miss is feedback ownership. Under the Common Paper standard, the provider retains all rights to the product, including features created in response to feedback, and the partner assigns their rights in that feedback to the provider. Get that in writing before someone's VP suggests a feature and then asks, six months later, whether they own it. Confidentiality matters too, in both directions, because they're showing you internal workflows and you're showing them something unfinished.

Two things worth adding that boilerplate usually skips. First, a hard end date, with a specific conversion date and price. Second, written success criteria: what has to be true at the end for both sides to call this a win. Without those, the program doesn't end. It just fades.

How do you run the program so it ends in revenue?

Set a hard deadline and a binary ask: go paid, or don't. Enthusiasm during the program means very little. Conversion at the end means almost everything.

The mechanics that work are boring. Biweekly calls on a fixed schedule. A shared doc of what changed since last time. A running list of requests with your actual priority order visible, so partners can see when they're outvoted and why. Strella met with each of its 12 partners biweekly across the whole program, and every one of them converted at the deadline. That's the outcome you're designing for.

Watch what the program teaches you about pricing, because that's the underrated output. Ada learned from real procurement conversations that enterprise buyers wanted predictable annual commitments rather than outcome-based billing tied to individual resolved tickets. Strella landed on seat-based pricing instead of per-project billing, specifically because per-project created budget approval friction every time someone wanted to use it. Neither of those came out of a spreadsheet. They came out of watching how customers actually buy.

Then hold the line at the deadline. "We love it, can we keep going free for another quarter" is a no. It's the most useful data point in the entire program, and founders routinely talk themselves out of hearing it.

If you want to go deeper on the interview mechanics behind these calls, we've written a separate walkthrough on customer discovery interviews, and the free tools cover the ICP and market sizing work that should happen before you start recruiting.

What kills design partner programs?

Four things, and they're all avoidable.

Building to one loud voice. Your most engaged partner is not your market. If a request only comes from one company, it's custom work, not a roadmap item.

No end date. Programs without deadlines don't fail, they just dissolve. Six months in you're doing free implementation for companies that were never going to buy.

Recruiting friends. A warm intro who says yes as a favor will also say nice things as a favor, and you'll believe them, because you want to.

Confusing usage with willingness to pay. A partner logging in daily for free tells you the product is useful. It tells you nothing about whether it's worth $2,000 a month. Only the invoice answers that.

Key takeaways

A design partner shapes a product that doesn't exist yet. A beta user tests one that does. Recruit for the first.
Start before you build. Ada's founders worked support desks at seven companies pre-code; Strella recruited 12 partners before the product was finished.
Five to 12 partners in a single ICP is the working range. Narrow beats numerous.
Cold outreach is the stronger signal, not the weaker one. A stranger's yes is worth more than a friend's.
Offer influence and preferential pricing. Never offer equity.
Use a one-page agreement (Common Paper's free template is at v1.3) and settle feedback ownership up front.
End with a hard deadline and a binary conversion ask. Enthusiasm is noise, conversion is signal.

FAQ

What is a design partner program?

A structured pre-launch arrangement between a startup and a small group of target customers who co-develop the product in exchange for early access, roadmap influence, and preferential pricing. It's expected to end with those partners converting to paying customers.

How many design partners should I recruit?

Most practitioners recommend five to 12. Enough to see patterns across your ICP, few enough to stay high touch with each one. If you're a solo founder, start closer to five, since each partner realistically costs you a couple of hours a month.

Should design partners pay during the program?

Ideally yes, even a token amount, because payment is the clearest proof of intent. Common guidance is at least 10% of expected contract value if you charge at all. If they don't pay, get a different form of real commitment: guaranteed hours, workflow access, or a named executive sponsor.

Do design partners get equity?

No. Equity is for advisors. Design partners are compensated with discounted pricing and founder access. Warrants for early customers create cap table complexity that buys you nothing a better discount wouldn't.

Where do I find design partners if I have no network?

Cold LinkedIn outreach targeted by exact job title and company profile, communities where your ICP discusses the problem, and companies posting job listings for the work you're automating. Strella recruited all 12 of its design partners cold, on purpose, because a stranger's yes is a more honest signal.

How long should a design partnership last?

Long enough to build and test the core workflow, typically one to two quarters, with a fixed end date set at the start. Open-ended programs stop being validation and start being free implementation work.

What if a design partner won't convert at the end?

That's useful, not a failure. Ask exactly what would have made it a yes, and whether the blocker was price, priority, or product. One non-conversion is data. Four out of five is a signal to revisit the segment or the problem.

Founder Salary: How Much Should You Pay Yourself?

Spencer Claydon — Wed, 19 Aug 2026 19:59:27 +0000

Nobody warns you that setting your own founder salary is one of the first real decisions you'll make. There's no HR department to ask. There's no offer letter. There's just you, a bank account with somebody else's money in it (or nobody's money), and a rent payment due on the first.

Most first-time founders handle this badly in one of two directions. They either take nothing for two years and quietly burn through their savings until resentment sets in, or they set their founder salary at whatever they made at their last job and wonder why runway evaporates. Both are avoidable. The number isn't a matter of taste. It falls out of arithmetic you can do in about fifteen minutes.

Here's what the data actually says, and how to work out your own number.

Should a founder pay themselves anything at all?

Yes, eventually, but almost certainly not on day one. Your real compensation as a founder is equity, and equity only pays when you exit. Salary exists for one reason: to keep you functional enough to do the work.

That distinction matters because it changes the question. You're not asking "what am I worth?" You're asking "what's the minimum that lets me stop thinking about money and start thinking about customers?"

Zero salary works for a while. It's a legitimate stage. Paul Graham called the end state of it ramen profitability: a company that covers the founders' minimal living costs from revenue, which means it never has to raise money just to survive. That's a real strategic advantage when you're negotiating with investors.

But zero has a shelf life. Founders who go unpaid for eighteen months don't become more committed. They become distracted, then broke, then gone. OpenVC put it well: running the company on your personal savings is a form of cheating, because you're keeping the business on life support with money that isn't on the books. At some point the true version of the P&L includes paying you.

What do founders actually pay themselves in 2026?

Venture-backed founder salaries rose again this year. Kruze Consulting's 2026 CEO Salary Report, which draws on real payroll data from its startup client base, puts the average startup CEO salary at $165,000 and the median at $159,000. Both are up from 2025 and well above the 2023 to 2024 trough in the low $140Ks.

By stage, the 2026 numbers look like this:

Stage	Typical range	Median	What justifies it
Pre-seed	$0 to $85,000	around $50,000	Small or no institutional round, runway measured in months, often part-time or freshly full-time
Seed	$130,000 to $170,000	$153,000	Priced round, early traction, 18+ months of runway, founder full-time on product and GTM
Series A	$180,000 to $230,000	$203,000	Clear product-market fit, real revenue, a team to manage
Series B	$200,000 to $260,000	$216,000	Material scale, investors watching burn multiple and path to exit

Two things jump out. First, seed-stage pay has moved a lot: $132,000 in 2024, $147,000 in 2025, $153,000 in 2026. Boards have gotten more comfortable letting founders off the subsistence diet once a priced round closes. Second, Series B pay is still nowhere near its 2022 peak of $262,000, which tells you later-stage investors are still enforcing discipline.

Pre-seed is the messy one, because there's no single authoritative dataset and the sample is full of people paying themselves nothing. The commonly cited figure is around $50,000, with most sources putting the realistic band somewhere between $40,000 and $85,000. Seedcamp's survey of 185 European founders had partner Reshma Sohoni describing the "safe" ranges an investor expects to see as under EUR 100k at pre-seed, right around EUR 100k at seed, and north of EUR 150k at Series A, with anything meaningfully above that reading as a red flag.

And if you're not venture-backed at all? None of these numbers apply to you. Which brings us to the group most first-time founders actually belong to.

What's a fair founder salary if you're bootstrapped?

Pay yourself out of profit, not revenue, and expect that number to be small for longer than you want. Bootstrapped founder compensation isn't a benchmark question. It's a cash flow question.

The uncomfortable data point: across surveys of independent SaaS founders, the median micro-SaaS business does roughly $24,000 a year in revenue, and the median founder is pulling around $500 a month in MRR. That's not a salary. That's a side project that hasn't turned the corner yet, which describes most bootstrapped companies at any given moment.

The math changes fast once you get past the hump. A bootstrapped software business with no employees typically runs 70 to 90 percent net margins, because the costs are hosting, a few API bills, and payment processing. At $10,000 MRR with 80 percent margins, there's about $96,000 a year available. Whether you take all of it depends on whether you're trying to grow or trying to eat.

A practical structure that works for solo and small bootstrapped teams:

Set a fixed owner's-pay percentage of monthly revenue, say 40 to 50 percent, and pay yourself that automatically.
Hold a fixed percentage back for taxes, because nobody is withholding for you.
Leave the rest in the business for tools, contractors, and ads.
Revisit the percentage every quarter, not every month. Monthly revisiting turns into monthly raises.

The percentage approach beats a fixed salary when revenue is lumpy, because it scales down automatically in a bad month instead of quietly draining the account.

How do you calculate a founder salary from your runway?

Work backwards from the runway you need, not forwards from what you'd like to earn. The calculation takes four inputs: cash in the bank, non-payroll monthly burn, the number of months of runway you need, and how many people you're paying.

Here's a worked example. Say you've raised $500,000 on a SAFE and you want 20 months of runway to get to a seed round.

Total monthly burn budget: $500,000 divided by 20 = $25,000 a month
Non-payroll costs (hosting, software, legal, accounting, a little ad spend): $4,000 a month
That leaves $21,000 a month for people
You have one contract engineer at $8,000 a month, so $13,000 is left for two cofounders
Employer payroll taxes and benefits add roughly 10 to 15 percent on top of gross salary, so $13,000 of loaded cost supports about $5,800 a month gross each, or $69,600 a year

That's your number. Not because $69,600 feels right, but because it's what 20 months of runway costs.

Now run the sensitivity, because this is the part founders skip. If you each bump to $82,000, total burn goes to about $27,300 a month and runway drops from 20 months to 18.3. A $12,400 raise costs you 1.7 months of runway. Sometimes that trade is worth it. But you should be making it on purpose, with the number in front of you.

This is exactly the kind of thing that belongs in a real financial model rather than a mental estimate. A spreadsheet works fine, and so does something like Causal, LivePlan, or a planning tool like Foundra that walks first-time founders through the projections section step by step. What matters is that salary is a line item you can flex and watch runway respond, not a number you set once and forget. If you haven't built the runway side of this yet, start with how to calculate startup runway and come back.

What will investors think about your founder salary?

They'll think about alignment, and they care more about the extremes than the middle. Too high reads as misaligned priorities. Too low reads as either a founder who'll burn out or one who's hiding the true cost of the business.

Peter Thiel's line on this is famous and mostly still quoted approvingly: "The lower the CEO salary, the more likely it is to succeed." His reasoning was that the CEO's salary sets the ceiling for everyone else's, so a high one compounds through the whole payroll. He said if you only get to ask one question in diligence, ask that one.

The modern view is softer. A founder who can't make rent isn't a focused founder, they're a founder with a second job coming. Most seed investors now expect a conversation about salary rather than a vow of poverty, and several will tell you directly what they consider normal for your stage and city. Ask them. It's a much less awkward conversation than founders expect, and getting it wrong quietly is worse than getting it right loudly.

Kruze's own self-check is a decent proxy for how a board will read your number:

More than 20 percent below the stage midpoint: possibly underpaying yourself, which is a risk if you've already raised at a healthy valuation
Within 20 percent of the midpoint: normal, nobody will ask
More than 20 percent above: your traction, round size, and valuation need to justify it

One extra filter I'd add: if a $25,000 change in your salary swings your runway by several months, you're at a stage where you should be at the bottom of the band regardless of what the benchmark says.

When should you give yourself a raise?

Tie raises to events, not to the calendar. Founders who review their own pay every six months end up negotiating with themselves. Founders who tie it to triggers don't.

The triggers that actually justify a change:

A priced round closes. New capital and a new runway calculation. This is the single most common moment for a founder salary reset, and the stage benchmarks above are the right starting point.
You cross a revenue threshold that changes the runway math, for example when revenue covers non-payroll burn entirely.
You go full-time. Obvious, and often forgotten in the paperwork.
Your life changes. A kid, a move to a higher-cost city, a partner who quits their job. These are legitimate inputs. Christoph Janz's founder salary calculator, which is still one of the more useful free tools out there, explicitly weights stage, location, and family situation, and produces wildly different numbers for a Berlin founder with no kids versus a San Francisco founder with two.

What doesn't justify a raise: a good quarter, a competitor's funding announcement, or having read this article.

What are the tax and legal mechanics of paying yourself?

The mechanics depend entirely on your entity type, and getting them wrong is expensive in a way that's hard to unwind later. This is the part where you should talk to an accountant rather than a blog post, but here's the shape of it.

If you're a Delaware C-corp (the default for venture-track startups), you're an employee of your own company. Salary means real payroll: a W-2, withholding, employer payroll taxes, the whole apparatus. You can't just wire yourself money from the business account and call it salary. Set up payroll properly the moment you start paying anyone, including yourself.

If you've elected S-corp treatment, the IRS requires "reasonable compensation" before you take distributions. Distributions avoid self-employment tax, which creates an obvious temptation to pay yourself $12,000 in salary and $90,000 in distributions. The IRS knows about this and will reclassify the difference as wages if audited. They look at your role, your hours, company revenue, and what comparable businesses pay. Document how you arrived at the number.

If you're a single-member LLC, there's no salary at all in the technical sense. You take owner's draws and pay self-employment tax on the business's profit whether you withdraw it or not.

One thing every version shares: whatever you decide, write it down. A short board consent or a founder agreement noting the salary and the date is enough. Undocumented compensation is one of the small messes that shows up during diligence and slows a round down for no good reason.

Key takeaways

Equity is your real compensation. Salary exists to keep you focused, not to make you whole.
2026 benchmarks for venture-backed founders: roughly $50,000 at pre-seed, $153,000 median at seed, $203,000 at Series A, $216,000 at Series B.
Bootstrapped founders should pay a percentage of revenue out of profit, not a fixed salary, until revenue is predictable.
Set your number by working backwards from required runway. Cash divided by months, minus non-payroll burn, minus other salaries, divided across founders, adjusted for about 10 to 15 percent employer costs.
Investors react to extremes. Inside 20 percent of your stage's median, nobody asks questions.
Raise your pay on triggers (a round closing, a revenue threshold, going full-time), never on a schedule.
Run it through actual payroll and document the decision. Undocumented founder comp creates diligence friction later.

FAQ

Is it normal for a founder to take no salary?
Yes, at the earliest stage. Most pre-seed founders take nothing or close to it, and roughly 80 percent of startups are self-funded at the start. It stops being normal once you've raised institutional money, at which point taking zero is usually hiding real costs rather than saving them.

How much should a pre-seed founder pay themselves?
Around $50,000 a year is the most commonly cited figure, with a realistic band of $40,000 to $85,000 depending on city and family situation. The better answer is whatever your runway math produces, since pre-seed rounds vary enormously in size.

Do investors decide my salary?
Not directly at pre-seed and seed, though some SAFEs and most priced-round documents give the board approval rights over executive compensation. In practice it's a conversation, and most seed investors will tell you their expected range if you ask.

Should cofounders be paid the same amount?
Usually yes, unless there's a real difference in role, time commitment, or personal circumstances. Unequal founder salaries without a documented reason are a reliable source of resentment. If one cofounder needs more because of family obligations, handle it explicitly rather than quietly.

Can I pay myself in equity instead of cash?
You already own equity, so there's nothing to pay. Issuing yourself additional shares to compensate for a low salary dilutes your cofounders and investors and creates tax complications. Fix the cash problem with cash or with a lower burn rate.

What if my salary would leave the company with less than 12 months of runway?
Then it's too high. Twelve months is roughly the floor for being able to run a fundraise without negotiating from desperation, and most investors want to see 18 or more after a round closes. Cut the salary, cut other costs, or raise more before you raise your pay.