“Should we launch with a free trial or a free plan?” sounds like a pricing question.

It is really a question about how your product proves value, what free usage costs, and why a satisfied user would ever pay.

A free trial lends the whole product for a decision. Freemium gives away a smaller product for as long as it remains useful.

Choose the wrong model and you do not merely lose revenue. You collect the wrong users, hide weak activation, create support work, and teach the market an offer you may later have to take away.

Start with the paid reason

Before deciding what is free, finish this sentence:

The customer pays when ______ because ______.

Useful answers name a change in the customer's job:

  • the team needs more people to collaborate;
  • the account reaches a real usage threshold;
  • the buyer needs control, audit history, or administration;
  • the product replaces enough labour to justify recurring spend;
  • the result becomes part of a commercial workflow;
  • the customer needs a guaranteed service or support boundary.

“The trial ends” is not a value reason. It is a deadline. A deadline can force a decision, but the product still has to make payment sensible.

“Advanced features” is not yet a reason either. Name the job those features unlock.

YC's guide to monetizing a freemium business begins with the relationship between free and paid: who the segments are, what they use, and how they should move toward a paid offer. That work belongs before the paywall code.

Choose a free trial when time can answer the buying question

A trial gives the user broad or complete access for a fixed period. It works best when:

  • the full product can be understood quickly;
  • a user can complete a real job inside the window;
  • value does not require months of accumulated data;
  • the buyer already has a recurring problem;
  • ongoing free usage would carry meaningful cost;
  • the product is useful to one user without a large network;
  • there is a clear moment to decide whether to continue.

The trial should be long enough to include the product's natural trigger. Seven days may be generous for a daily writing tool and useless for monthly reporting software.

Do not choose fourteen days because another pricing page did. Ask how long it takes a qualified user to gather input, complete setup, reach the first result, and experience the result again.

A trial clock that begins at signup can punish people who register on Friday, wait for a colleague, or discover they need a file from another system. Consider starting the meaningful window when setup is complete or when the first core action begins. If you keep the simpler signup clock, make it obvious.

Choose freemium when the free product can remain whole

Freemium offers a useful product with permanent limits. It works best when:

  • one person or small team can receive lasting value from the free tier;
  • each additional free user is cheap enough to serve;
  • usage spreads the product to potential buyers;
  • the paid need appears through scale, collaboration, control, or commercial use;
  • the user can understand the limit before hitting it;
  • a large free population improves distribution or learning without overwhelming support.

The free tier must be a product, not a collection of disabled buttons.

Good limits preserve the core job and charge when the job becomes larger or more consequential. They may cap active projects, stored history, runs per month, collaborators, automation, export, administration, or support.

Bad limits allow setup but block the promised result. The user does all the work, reaches the last screen, and learns that the only useful action requires payment. That is not a demonstration. It is an ambush.

a16z identifies three common freemium problems in its free-tier analysis: the free offer can be too generous, too restrictive, or paired with an entry plan that costs more than the perceived step up. The useful lesson for an early startup is not to copy a conversion benchmark. It is to diagnose which side of the boundary is broken.

Use a paid pilot when neither model fits

Some products cannot prove value through unattended use.

Choose a bounded paid pilot when setup requires migration, integrations, security review, expert configuration, workflow change, or meaningful founder labour. Write down:

  • the job and users in scope;
  • the access and data required;
  • what the founder will do manually;
  • the result to deliver;
  • success and stop conditions;
  • the start and decision dates;
  • the pilot price;
  • what continued use will cost.

A paid pilot tests whether the problem has budget and whether the customer will participate. It is often more honest than a “free trial” that cannot work until the founder spends twelve hours configuring it.

Do not disguise consulting as self-serve software. Manual help is sensible early. Record it so you know what must become repeatable.

Sometimes the right free plan is no free plan

Free access can be unsafe or economically false.

Be cautious when the product:

  • sends email, messages, payments, or public posts;
  • consumes expensive model, data, compute, or human-review capacity;
  • can be used for spam, fraud, scraping, impersonation, or harassment;
  • handles sensitive data before trust is established;
  • requires support on every successful job;
  • produces a result with high consequence or legal exposure.

You can still reduce buying risk with a guided demo, sample report, sandbox, public methodology, refundable deposit, small paid credit pack, or narrow passive check.

The goal of free access is to reduce uncertainty. It is not to remove every boundary.

Count the cost of a successful free user

Founders often calculate free cost from storage and forget the expensive parts.

For each completed free job, include:

  • model inference and retries;
  • third-party API or data fees;
  • email, SMS, rendering, and file processing;
  • database, storage, bandwidth, and logs;
  • moderation and abuse review;
  • founder onboarding and support time;
  • failed jobs that still consume resources;
  • fraudulent accounts and repeated signups;
  • account deletion and data-export obligations.

Now multiply by the number of free users you hope to attract, not the number you have today.

A Hacker News discussion about freemium versus trials offers a durable founder heuristic: perpetual free use is easier to justify when marginal usage cost is trivial, while a trial can better contain non-trivial service cost and abuse. Treat that as a question to test, not a law.

For an AI product, set limits at the server. A greyed-out button does not stop direct API requests. Apply rate limits, quotas, input-size boundaries, concurrency controls, and abuse checks before public launch.

Put the limit after the first useful result

A user must experience enough value to make the paid step intelligible.

Map the journey:

  1. Arrive with a real problem.
  2. Understand the offer.
  3. Provide the required input.
  4. Receive a useful result.
  5. Use that result in the real workflow.
  6. Encounter a larger, repeated, collaborative, or commercial need.
  7. See the paid offer at that moment.

If the limit appears at step three, the user is buying a promise. That can work when trust is already high or the problem is urgent. It is weak self-serve evaluation.

If the limit never appears, the free product may satisfy the intended buyer completely. Do not blame the upgrade copy for a missing paid reason.

Context matters. An upgrade prompt after a team adds another collaborator explains itself. A generic daily banner shown before the first result trains users to close banners.

Decide whether to require a card

A card at trial start reduces casual signups and creates a cleaner path to payment. It also creates fear of accidental billing and excludes users who cannot use a company card before evaluation.

Require a card when the ongoing intent is already clear, the product carries real trial cost, and the buyer can reasonably approve payment before trying. Consider a cardless trial when the product is unfamiliar, evaluation is the purpose, or the evaluator is not yet the buyer.

Whichever path you choose, state:

  • whether a card is required;
  • when and how much it will be charged;
  • whether the trial converts automatically;
  • how to cancel;
  • what happens to work and data at expiry;
  • whether the user can export first.

Do not hide automatic conversion in small print. Surprise revenue creates refunds, disputes, support, and distrust.

Design the ending before the beginning

Trial expiry and free-tier limits are product states. Build them before launch.

Test these paths from a clean account:

  • the user approaches the limit;
  • the user hits the limit during a job;
  • payment succeeds;
  • payment fails;
  • the user upgrades twice;
  • the user downgrades;
  • the trial expires while a job is running;
  • the plan ends with stored customer data;
  • the customer returns after expiry;
  • support inspects the correct plan state;
  • cancellation and deletion work.

Preserve work where possible. Explain what becomes read-only, what stops, what remains exportable, and when data will be removed. Never let a failed payment silently destroy the user's only copy.

The pricing-before-launch guide treats checkout, receipts, limits, cancellation, and refunds as one promise. Use it alongside the production checklist for AI-built apps before sending public traffic into the offer.

Make the public facts agree

Pricing page, signup screen, checkout, product limits, terms, help articles, receipts, and sales emails should describe the same model.

Publish the facts directly in accessible text:

  • what is free;
  • what is limited;
  • how long a trial lasts;
  • when it begins;
  • whether payment starts automatically;
  • the paid price and billing period;
  • cancellation and data behavior;
  • material usage or fair-use limits.

This clarity helps buyers. It also gives search engines and agents one stable account of the offer instead of forcing them to reconcile a stale help article with a new pricing card.

If limits or prices change, update the canonical pricing page first, then every dependent page. Show a meaningful effective date where existing customers are affected.

Measure the model below signup

Free signups are an input, not the result.

Track one cohort from arrival through:

  1. Qualified signup.
  2. Setup started.
  3. First useful result.
  4. Result used in a real workflow.
  5. Paid need encountered.
  6. Upgrade viewed.
  7. Payment attempted.
  8. Payment completed.
  9. Meaningful use after payment.
  10. Renewal, expansion, downgrade, or churn.

Add cost per successful free user and founder minutes per account. A model that converts but requires personal rescue for every user is not yet self-serve.

Interview people at three points: those who never reached value, those who use free repeatedly without upgrading, and those who paid. Ask about the job, what happened, and what alternative they chose. Do not ask only whether the price felt fair.

Use the retention diagnosis if the free population signs up once and disappears. The pricing model cannot repair a result users do not want twice.

Run the smallest honest experiment

Do not build permanent entitlements for a theory.

For the first ten qualified users, you can operate the model manually:

  • issue a fixed amount of usage;
  • record when the first value arrives;
  • explain the paid boundary personally;
  • invoice or send a checkout link;
  • extend access only for a stated reason;
  • log objections and support cost;
  • review who continues after payment.

Choose in advance what would change your mind.

A trial hypothesis might be: qualified users can reach the full result within seven working days, and ongoing usage costs enough that permanent free access is unsound.

A freemium hypothesis might be: a small account receives durable value cheaply, exposes the product to more intended users, and develops a clear paid need at collaboration or capacity.

A paid-pilot hypothesis might be: the customer needs founder help to reach value but will commit money, access, and a decision date because the problem is important.

After the first cohort, inspect behavior rather than defending the label.

Use the decision in one page

Write down:

Intended free user: Job they can complete: First useful result: Time to that result: Natural usage cadence: Cost per successful free user: Abuse or safety exposure: Paid reason: Limit that reveals the paid reason: What happens at the limit or expiry: Data and export behavior: Evidence that would change the model:

If you cannot fill in the paid reason, do not spend another week polishing the plan names.

A free trial compresses a buying decision. Freemium grows a smaller useful product until a larger need appears. A paid pilot shares the cost of learning when the product still needs human work.

Pick the model that tells the truth about how value arrives and what it costs to deliver. Free is a boundary. Design it with the same care as payment.