“We are in beta” can mean six users on a call with the founder. It can mean anybody may sign up. It can mean the product has been public for three years and the company still wants an excuse.

The label tells users little. Access, risk, and support tell them what matters.

Choose the smallest launch that can answer the next important question.

Stop treating launch as a switch

A product can move through several widths of exposure.

Founder test: The team performs the whole job with controlled data. Alpha: A few trusted users try unstable paths with the team nearby. Closed beta: Selected external users get access under clear limits. Invite-only beta: Existing users can bring others, but growth remains bounded. Open beta: Anyone in the intended market may join, while known limits remain. General availability: The product makes a stable public promise and supports ordinary demand.

These are working definitions, not laws. State what your stage means instead of assuming everybody shares the vocabulary.

Launches can also be narrow by audience, geography, workflow, plan, or data sensitivity. An app may be public for individual projects while team billing remains closed. A marketplace may begin in one neighborhood. A developer product may open one integration before the rest.

The eight-launch startup guide shows how controlled exposure can test different parts of the business without waiting for one grand reveal.

Name the question before the audience

Every release should answer one question that the team cannot answer alone.

Examples:

  • Can the intended user reach the first useful result without help?
  • Does the result matter enough for them to return next week?
  • Can the product survive ten simultaneous jobs?
  • Will a buyer give real data, time, or money for this workflow?
  • Does an invitation make sense without the founder explaining it?
  • Can support recover an account without unsafe shortcuts?

Now choose the smallest audience that can produce that evidence.

If the question is whether three finance teams can complete a monthly close workflow, a closed beta is enough. If the question is whether strangers understand a self-serve homepage, the product must be publicly reachable. If the question concerns load, accessibility, or discovery, six friendly testers cannot answer it.

The audience follows the question. Not the other way around.

Choose a closed beta when consequence is high

Use a small, selected group when failure can cost more than attention.

Typical reasons include:

  • the product can move money;
  • users will store important or private data;
  • the workflow can publish, delete, or send something externally;
  • results may influence health, legal, hiring, or financial decisions;
  • integration setup is still partly manual;
  • support does not yet know how to recover common failures;
  • the team needs to observe the job closely.

A closed beta is not permission to be careless. It is a way to bound the number of people exposed while you prove the important paths.

Select testers who actually perform the job. Friends who like the founder but do not need the product produce soft feedback and strange feature requests.

For a B2B product, early test customers or design partners can help shape the workflow. Elad Gil describes this approach in YC’s discussion of finding the first enterprise customers. The useful feature is not exclusivity. It is close contact with people who feel the problem.

Choose an open beta when reach is part of the test

Open the door when a stranger can receive value safely and the unanswered question requires broader exposure.

This is often true when:

  • discovery or sharing is part of the product;
  • users have varied devices, browsers, data, or use cases;
  • the product is low-cost to try and easy to leave;
  • the main risk is confusion rather than irreversible harm;
  • the team can detect and support failures;
  • a public URL is needed for search, communities, or integrations;
  • there is already evidence that the core result works for a few users.

An open beta can still limit expensive features, queue access, cap uploads, restrict regions, or require verification. Open does not mean unlimited.

YC’s essential startup advice argues for launching a product once it contains enough real utility to outweigh its rough edges. That is different from exposing every unfinished system to unlimited use.

Use invite-only access for a real constraint

Invitations are useful when they protect something specific:

  • support capacity;
  • scarce compute or inventory;
  • community density;
  • geographic operations;
  • careful handling of sensitive workflows;
  • a staged technical migration.

Write the constraint down. Decide what condition will let more people in.

Do not use a waiting list to imitate demand. A large queue of email addresses can hide the absence of active users. Do not ask people to perform referral tricks for a product they have never used.

If existing users may invite others, monitor whether the invited people resemble the intended segment and reach value. A referral mechanism can widen good evidence or multiply confusion.

Make the agreement plain

Tell beta users what they are joining.

State:

  • what works today;
  • what is missing or unstable;
  • whether data may be reset or migrated;
  • what data is collected and why;
  • whether payment is real, discounted, or absent;
  • how support works and when it is available;
  • how to report a defect;
  • how to export work or leave;
  • when access may end;
  • whether feedback or usage may be quoted publicly.

Do not place serious limits only in a long terms page. Put the important ones near the decision.

“Beta” does not cancel privacy, security, payment, or consumer obligations. Nor does it excuse a product from keeping the promises it explicitly makes.

Use the website trust guide to make the operator, price, support route, data treatment, and exit visible before asking a tester for commitment.

Recruit a cohort, not an audience

For the first closed group, recruit ten to twenty people who share the condition that makes the problem urgent.

Invite them one at a time. Explain why you thought of them. Ask for a specific test:

We are testing whether independent agencies can turn one client site into a useful launch report without setup help. The product is rough, and we may reset test data. Would you run one real site through it this week and let us watch where the report fails you?

This request contains a user, job, time, risk, and observation.

Do not promise permanent free access merely to obtain a session. If the eventual product will be paid, test willingness to pay before the beta audience becomes trained to expect otherwise.

Paul Graham’s Do Things that Don’t Scale argues for deliberate manual recruitment and unusually close attention to early users. That work is particularly valuable in a closed beta because every tester should teach the product something a random signup could not.

Instrument the beta before inviting people

Track the path that corresponds to the question.

At minimum:

  • invited;
  • accepted;
  • signup started;
  • signup completed;
  • core job started;
  • first useful result reached;
  • failure or support needed;
  • returned within the expected interval;
  • paid, referred, expanded, or left.

Keep the denominator. Eight active users means something different after ten invitations than after two hundred.

Add a direct feedback route inside the product or beside the result. Still watch real sessions. Feedback forms capture what users noticed. Observation captures what they worked around without mentioning.

The week-one analytics guide provides a small event model built around completed jobs, failures, and returns.

Hold back harm, not embarrassment

Founders often delay because the interface is plain, onboarding contains manual help, or the feature list looks small beside an incumbent.

Those may be acceptable beta conditions.

Do not delay merely because:

  • the logo may change;
  • the settings page is ugly;
  • one report needs founder review;
  • an edge feature is missing;
  • the product serves only one narrow workflow;
  • the founder must personally onboard each user.

Delay or narrow access when:

  • one user can see another user’s records;
  • payment and entitlement can disagree;
  • destructive actions have no clear confirmation or recovery;
  • critical email does not arrive;
  • the team cannot detect serious failure;
  • users can lose irreplaceable work;
  • claims exceed what the product can prove;
  • support recovery depends on unsafe identity guesses.

The vibe-coded app launch guide makes the same distinction: harmless roughness can buy learning; failures involving identity, money, data, or control spend trust.

Give the beta a cadence

An endless beta becomes storage for unresolved decisions.

Run in short cycles:

  1. State the question.
  2. Invite one coherent cohort.
  3. Watch the core job.
  4. Fix consequential failures.
  5. Review behavior and interviews.
  6. Decide whether to deepen, widen, change, or stop.

Keep a weekly note with the cohort, numbers, failures, surprises, and next decision. Share relevant changes with testers. Close the loop when somebody’s report led to a fix.

YC’s account of shipping early and often describes working toward a minimal v0 and repeatedly releasing in order to escape perfectionism and unsupported assumptions. A beta should create that rhythm, not suspend the launch indefinitely.

Widen access with gates, not feelings

Before the beta begins, define the evidence required for the next stage.

A closed beta might become invite-only when:

  • the core job succeeds for eight of ten intended users;
  • no unresolved failure risks money, privacy, or data loss;
  • common recovery paths have been tested;
  • a founder can support ten more accounts;
  • at least several users return without chasing;
  • the public explanation matches what users experienced.

Invite-only might become open when:

  • activation works without live founder explanation;
  • cost and abuse limits are in place;
  • errors reach an owner;
  • transactional email and account recovery work;
  • pricing and limits are consistent;
  • the support route can absorb ordinary failures;
  • the team knows which segment it is opening to.

Choose thresholds that fit the product. Do not pretend that eight of ten is a universal law. The point is to replace “it feels ready” with evidence tied to the promise.

The Hacker News discussion When to release? contains a durable distinction: a startup can launch rough software earlier than a large company, but the acceptable roughness depends on how much users rely on the product and what failure costs them.

Open the beta before announcing it

There is a useful difference between making the product available and promoting it widely.

Open the path quietly first. Use a new account, a different device, and the public hostname. Complete signup, verification, the core job, payment if applicable, sign-out, and recovery. Ask two people outside the team to do the same without help.

Then run the website launch readiness checklist. Check the public promise, trust pages, metadata, indexing controls, mobile experience, and support route before distribution creates more chances to discover the same defect.

Availability lets reality enter. Promotion controls how quickly.

End the beta deliberately

A beta should end in one of four decisions:

  • Widen: the product promise survives a broader audience.
  • Deepen: the right users care, but a core job still fails.
  • Narrow: one segment shows stronger pull or lower risk.
  • Stop: the evidence does not support more investment in this version.

Tell users what changes. Preserve exports and notice periods where their work depends on the product. Do not erase the word “beta” from the header while leaving every operating assumption untouched.

General availability is not a claim of perfection. It is a claim that the product’s ordinary promise, support, recovery, and limits are understood well enough to offer without a founder standing beside every user.

The decision in one minute

Choose a closed beta when you need close observation, the workflow is consequential, or support and recovery remain manual.

Choose invite-only access when a real capacity, safety, geography, or community constraint requires controlled growth.

Choose an open beta when strangers can receive value safely and broader variation, discovery, or sharing is part of the test.

Choose a public launch when the core journey, public promise, operations, and support can survive ordinary demand.

Do not wait for confidence. Choose the width that lets you learn without making a promise you cannot yet keep.