Your first 100 users: a 60-day experiment plan

Most founders get to ten paying customers by force of will. They get to a hundred by building a system. Your first 100 users is the stretch where instinct stops being enough and your week starts to need a shape. This guide is one such shape: a 60-day plan you can run alone, structured as experiments, designed for the bootstrapped founder who has a real product, a few real customers, and no marketing team.

The plan is opinionated on purpose. Most growth advice on the internet is written for companies past Series A, with channels you cannot afford and team sizes you do not have. What follows is what the next sixty days look like when you are still doing everything yourself, when the answer to “who handles this” is “you, after dinner, on a Wednesday.” The aim is to leave day 60 with a hundred users, a repeatable loop that produced most of them, and a written sense of why the loop works.

One framing note before the plan. If you have not yet read the playbook for your first ten customers, start there. The first ten is a different job: hand-built, qualitative, slow. This guide picks up the day after you wake up with ten paying customers and realize you have no plan for getting to eleven.

// 01Why 100 is the threshold, not 10

Founders ask the wrong question at this stage. They ask, “how do I scale.” The right question is, “what changes between user 10 and user 100, and what do I have to learn that I do not know yet.”

Three things change. They are quiet, they happen at the same time, and most founders miss all three.

• Numbers start to mean things: Conversion rates and channel costs are nonsense at ten. They are still noisy at a hundred, but they begin to point. You can finally tell, for the first time, whether a thing works because it works or because you charmed three friends into trying it.
• Your time stops being elastic: At ten customers you can personally email all of them on a Sunday. At a hundred, the same instinct becomes a part-time job you cannot afford. The work that got you here becomes the work that prevents you from getting further.
• The product gets seen by strangers: Early users were generous. They overlooked things. Users 30 through 100 are colder, will not give you the benefit of the doubt, and will be the first honest test of whether the product can stand on its own.

The plan below is a way to make that shift on a schedule. Sixty days, four fortnights, five experiments per fortnight, one weekly review. It is small enough that you can hold it in your head and big enough that it produces real evidence by the end.

// 02The 60-day shape

Sixty days is not a magic number. It is a working window: long enough to run real experiments, short enough that you cannot afford to drift. Two months sits in the sweet spot where most founders can sustain weekly discipline without burning out and where the results are still fresh enough to act on.

The plan divides the time into four fortnights, each with a clear job:

• Weeks 1 and 2. Narrow.: Pick one ICP, one channel, and one hypothesis you actually believe. Throw out the other twelve ideas in your notebook for now. The biggest mistake at this stage is breadth, not depth.
• Weeks 3 and 4. Run five experiments.: Inside the narrow you just chose, fire five small experiments in parallel. Five is enough to learn from. More than five and you will not have the attention to read any of them properly.
• Weeks 5 and 6. Double down or kill.: Review what happened with brutal honesty. Two of the five will be interesting. Pour what you have into those. Stop everything else.
• Weeks 7 and 8. Turn behavior into a loop.: What you learned was an event. The job of the last fortnight is to convert the event into something repeatable. A loop is not a campaign; it is a system you could leave running.

On top of the fortnight cadence there is one weekly ritual: a sixty-minute review every Friday where you read the numbers, write down what surprised you, and decide what changes next week. Sixty days is eight reviews. The reviews are not optional. They are where the plan thinks.

// 03Weeks 1 and 2: narrow to one ICP, one channel, one hypothesis

The first fortnight is mostly subtraction. By the end of week 2 you should have a single page of writing that says: this is the customer, this is the channel, this is what I believe will work and why. Everything else gets postponed.

• One ICP, written in one paragraph: Use your actual paying customers as the source. Find the three who most resemble each other and write the paragraph that fits all three. Resist the temptation to widen. The narrower this paragraph, the easier the next 50 days become.
• One channel, picked by access not size: You do not need the best channel; you need the one you can actually run. If you can show up daily in a community where your ICP already hangs out, that beats a paid channel you can barely afford. Pick the channel where you have a personal foothold.
• One hypothesis you actually believe: Write it down in this shape: "If I do X in Y channel, then Z type of user will respond at A rate." If reading it back makes you uncomfortable because it is too specific, you have it right.

Two warnings for this fortnight. First, do not start running experiments yet. The job of weeks 1 and 2 is to set up clean ground. Founders who skip the setup and start firing attempts on day three end up with ten half-tracked things and zero learning by week 4.

Second, your hypothesis will probably be wrong. That is fine. You are not trying to be right; you are trying to be specific enough that being wrong teaches you something.

// 04Weeks 3 and 4: run five experiments, only five

Inside your narrow, the next fortnight is five small bets in parallel. Five is the largest number a solo founder can run without losing track. Each experiment uses the same template (see section 07): a hypothesis, a leading metric, a success threshold, kill criteria, and a time-box.

The five do not have to be radically different. Often the best set is one obvious bet, three sensible variations of it, and one weirder bet at the edge of what feels reasonable. The weird one is there because the obvious bet almost never wins on its own at this stage, and the variations on it tend to tell you something only when the weird one anchors the comparison.

• Each experiment runs for the full fortnight: You cannot read a signal in three days. Two weeks is the minimum window where the numbers begin to settle. Resist the urge to declare a winner on day 4 because you got a good email reply.
• You watch leading metrics, not lagging ones: Replies, click-throughs, qualified conversations, time on the key screen. The lagging metric, paying users, will come later. If you only watch revenue, you will get no signal in two weeks.
• Nothing escapes the spreadsheet: A simple grid: experiment name, hypothesis, what you did, the numbers, what you learned. One row per experiment. You will reread this row for the rest of the year.

Why not ten? Because ten is the number you reach for when you are afraid to commit. Five forces a real choice. It also fits the cognitive budget of a single human who is also shipping code, doing support, and answering invoices. Past five, the experiments interfere with each other and with your attention. You stop running experiments and start running a circus.

The Friday review at the end of week 4 is the most important sixty minutes in the plan. You will arrive with five rows of evidence and a strong urge to keep all of them alive. Resist that urge. The next fortnight depends on you choosing.

// 05Weeks 5 and 6: double down or kill

By the end of week 4 you will have a roughly predictable pattern: one experiment is clearly working, one is clearly not, two are ambiguous, and one is interesting in a way you did not expect. This is not pessimism; it is the shape of running five things at once as a solo founder. The job of weeks 5 and 6 is to act on the pattern instead of debating it.

• Double down on the winner: Move the time, money, and attention you had spread across five experiments into one. If the winning experiment was a content piece, write three more in the same shape. If it was a community thread, run a similar thread in three other communities. Concentration is the goal.
• Kill the obvious losers without ceremony: The clearly-not-working experiment should be turned off the day after the review. Do not keep it running because you put effort into it. Sunk cost is the single most expensive habit at this stage.
• Investigate the surprise: The interesting unexpected one is often where the real loop hides. Spend a week looking at it carefully. Talk to anyone it produced. Ask what they thought you were offering and why they responded.
• Hold the ambiguous experiments still: Do not kill them, do not pour effort into them. Let them keep running on autopilot and decide in week 7 based on a longer window of data.

This fortnight is also where you should start noticing how your users behave once they arrive. A hundred users is the smallest number that lets you honestly ask whether the product is doing its job after sign-up. Do new users stay? Do they invite anyone? Do they upgrade? If the answer is no, the plan needs a sub-plan for activation that we will not solve here, but you need to know that you are not solving it yet.

// 06Weeks 7 and 8: turn behavior into a repeatable loop

The last fortnight is about extraction. You found one thing that works. The job now is to describe it precisely enough that you could hand it to someone else, and then to remove yourself from the parts of it that do not need you.

• Write the loop as a sequence: A loop is not a campaign. A campaign starts and ends; a loop produces outputs that become its own inputs. Write yours as a sequence of steps that begins with an action and ends with a new user, where the new user produces something that fuels step one again.
• Find what you can take yourself out of: Look at each step and ask what would break if you stopped doing it. Some steps will need you forever at this stage. Others can be replaced by a template, a saved reply, a recurring calendar block, or a tiny piece of automation that you build in an afternoon.
• Decide the inputs and outputs in numbers: How many of input X produces one user? How many users does each cycle of the loop produce? You do not need precision; you need the order of magnitude. If you do not know, the loop is not a loop yet.
• Set the rhythm for the next sixty days: A loop has a frequency. Daily, weekly, biweekly. Pick the rhythm you can actually maintain and put it on the calendar like a meeting.

At the end of week 8, do one thing before declaring the plan complete: spend an afternoon writing what is now true that was not true on day one. Customer description, channel, message, price, what works, what does not, what surprised you. This document is the single most valuable artefact of the sixty days. It is also the bridge into the next plan, because the next plan starts with the new version of these answers.

// 07The experiment template

Every experiment in this plan uses the same five-line template. Keep it boring. Keeping it boring is what makes the comparison between experiments possible.

• Hypothesis: A single sentence in the shape "If I do X in channel Y, type-Z users will respond at rate A within time T." If you cannot write this sentence cleanly, the experiment is not ready to run.
• Leading metric: The thing you actually watch. Replies. Clicks. Qualified conversations. Sign-ups that complete onboarding. Pick one that moves in days, not months.
• Success threshold: The number that, if hit, makes you say "this worked." Write it down before you start. Founders who decide afterward what counts as success will always find a reason to declare success.
• Kill criteria: The number or behavior that, if seen, makes you stop. Specific and stricter than you would like. The point is to prevent the experiment from becoming a habit nobody is willing to end.
• Time-box: A fixed end date. Two weeks for this plan. Reading the result on the time-box date is non-negotiable; pushing the date because you want more time is the most common failure mode.

Save the template somewhere you can copy it: a Notion page, a text snippet, the back of a notebook. You will run dozens of these over the next year. The marginal cost of formalising the template now is small; the marginal benefit of being able to compare experiments six months from now is large.

If you want a clean printable version of the plan, the template, and the week-by-week layout, the companion plan page is built to fit on two sheets of paper. Print it, scribble on it, tape it to the wall.

// 08What to ignore between 10 and 100

The internet is generous with advice for this stage and most of it is for a different company than yours. The list below is what you can safely defer until you are well past user 100. None of these are wrong forever; they are wrong for now.

• Paid acquisition at micro budgets: A hundred dollars a week of ads at this stage produces no signal you can read. If you cannot put a meaningful budget against a channel, the right answer is to not test it yet. Run unpaid first.
• Channel hopping: Every founder at this stage gets tempted to chase the channel of the week because their last experiment was ambiguous. This is how you end up six months in with no system and one user per channel.
• Dashboard building: A dashboard is for reading numbers you cannot read by hand. At 50 users you can read your numbers by hand. Build the dashboard after week 8, not before.
• Hiring: A first hire too early loses you more time than it saves. The first 100 users is the founder learning the shape of the work, not delegating it.
• Rebranding or redesigning the site: Visual polish at this stage almost never moves conversion enough to be worth the week it costs. If the site is intelligible, leave it. Polish ships after the loop is repeatable.
• Building an entirely new feature for a single prospect: You will be tempted. The right answer is almost always to put the prospect on a list, finish the 60 days, and decide later whether the feature serves five users or just the one.

The common thread in the list is that each one of these activities can feel productive in the moment while producing no learning. Productivity without learning is the most seductive failure mode at this stage. The plan above is deliberately small. The goal is to know more on day 60 than you did on day 1, not to be busy in between.

// 09Five things to carry to user 101

• 01: The job from 10 to 100 is to find one loop that works and a way of running it that does not depend on heroics. Everything else is a distraction wearing the costume of progress.
• 02: Narrow first, then run five. Solo founders who try to keep ten experiments alive end up with no learning and an empty Friday. Five is the right number; pick the smallest weird one and run it alongside the obvious four.
• 03: Decide success thresholds and kill criteria before you start. Founders who decide afterward will always rationalise. The template exists to take that decision out of your hands when you most want it back.
• 04: A loop is not a campaign. The deliverable of week 8 is something repeatable, not something finished. If you can describe it as a sequence whose output becomes its own input, you have one.
• 05: Write down what is now true. The single page of writing at the end of the plan is the most valuable thing you produce in the sixty days. It is the input to the next plan and the receipt for this one.

At user 101 the work changes again. The next question is not how to get a hundred; it is how to make the loop stop needing you. That is a different conversation, and most of it sits one lesson over, in why experimentation is the only honest way to grow. The first time you run this plan it will feel slow and bureaucratic. The second time it will feel obvious. By the third time, it will feel like the thing you wish you had been doing all along.