How Long Should Your Free Trial Be?

How long should your free trial be?

Long enough for a real user to reach the moment your product becomes obviously useful, and not one day longer. For most B2B software that lands between seven and thirty days. The number itself matters far less than whether your onboarding can get someone to value inside it.

Trial length is one of those decisions founders agonise over and then never revisit. It gets picked in week one, usually by copying whatever a competitor does, and then it sits in the billing config for three years while the product changes underneath it.

I want to give you a way to pick it deliberately, and to show you the implementation constraints that should shape the decision before you commit to a number.

Why is trial length the wrong first question?

Because length is a symptom of something else: how fast your product delivers a result the buyer cares about. If that takes an afternoon, thirty days is dead air. If it needs data imported and a team invited, fourteen days is a countdown clock running while your user waits on their own colleagues.

Ask instead what has to happen for the trial to be a fair test. Write those steps down. Connect a data source. Invite two teammates. Ship one real piece of work. Now ask how long that realistically takes a busy person who has a day job, and whose organisation may need a security review before they can connect anything.

That last part is what breaks most B2B trial maths. Consumer products get evaluated in one sitting. B2B products get evaluated in the gaps between meetings, and the evaluator frequently needs someone else to do something before they can proceed.

What actually determines the right length?

Three things. Time to first meaningful result, measured from signup rather than from a demo. The number of other people who must participate before the trial proves anything. And how long your buyer's internal process takes, including any procurement or security step that runs on its own schedule.

Measure the first from your own product analytics. Find the users who converted and look at how many days elapsed before they hit the action you consider the aha moment. Then look at the users who did not convert and see where they stalled. The gap between those two distributions is your real trial length, not an industry benchmark.

The second factor is the one people underweight. A single-player tool can be evaluated by one person in an evening. A tool that only proves its value when three people use it together, the way Slack, Figma and Notion do, needs enough runway for a calendar invite to be accepted. Every additional required participant adds days, not hours.

The third is invisible until it bites. If your buyer needs a security questionnaire answered before they can upload real data, your fourteen day trial is effectively a four day trial. This is the same problem I described when writing about buyers who never talk to sales: the process is happening whether you can see it or not.

Should you ask for a card up front?

It depends on whether you would rather have fewer, better trials or more, noisier ones. A card gate raises trial quality and lowers trial volume. No card raises volume and fills your funnel with people who were curious rather than shopping. Neither is wrong, but pick on purpose.

Stripe's documentation is clear about how the no-card path works. When a subscription contains only trial offers priced at zero, the status is trialing, which Stripe describes as ideal for no-card-required or standard free trial flows. So the mechanics are well supported. The question is strategic, not technical.

My bias for early-stage B2B is no card, because at that stage you need conversations more than you need conversion rate. Talking to fifty curious trialists teaches you more about positioning than talking to eight serious ones. Later, once you know who your buyer is, the card gate starts earning its keep by protecting support capacity.

What does your billing system let you change later?

Less than you would hope. Stripe's trial offers documentation states plainly that you cannot modify the trial length after you create the subscription, and you cannot schedule trial extensions and reductions. That single limitation should influence your choice more than any benchmark article.

There are other constraints worth knowing before you design around this. Trial offers are only supported when creating subscriptions directly through the Subscriptions API. Checkout, Payment Links, and Elements with Checkout Sessions do not support them, and Stripe points Checkout users to legacy free trials using the trial_end parameter instead. Trial offers also require the 2026-03-25 preview API version and flexible billing mode.

One more that will surprise whoever owns your reporting: Stripe's docs say trial offers revenue is not available in Billing Analytics. If your team plans to measure paid or discounted trials inside the dashboard, check that assumption now rather than during a board prep.

None of this means Stripe is the wrong choice. It means your trial design has a shape imposed by your billing stack, and discovering that shape after launch is expensive. If you run on Paddle, Chargebee, Recurly or your own billing code, the specific constraints differ, so read the vendor docs for whatever you use. These details change, and mine are current as of this writing rather than permanent.

What happens in the last few days of a trial?

Most of the real trial activity clusters near the deadline, because deadlines create action. Stripe sends a customer.subscription.trial_will_end event three days before the trial period ends, and if the trial is shorter than three days it triggers that event immediately.

That three day window is a gift and most teams waste it on a single automated email saying the trial is ending. A better use is a message, sent from Customer.io or HubSpot or whatever runs your lifecycle email, that references what the person actually did or did not do and offers the specific help that would unblock them. If they never connected a data source, that is the email. If they connected one and stopped, that is a different email.

You also need to decide what happens at the moment of expiry, and Stripe makes this explicit. When a free trial ends without a payment method, the subscription's missing payment method end behavior determines the outcome. Set to cancel, the subscription moves to canceled. Set to pause, it moves to paused, invoicing stops, and the subscription stays paused until it is explicitly resumed.

Pause is underrated. A paused account keeps the door open for the buyer who genuinely liked the product but hit a budget freeze, and it lets them come back without redoing setup. Cancelling wipes the relationship for the sake of a tidier database.

When is a reverse trial better than a free trial?

When your product has a usable free tier underneath the paid one. A reverse trial gives every new signup full access to premium features for a fixed window, then drops them to the free plan instead of cutting them off. Nobody hits a wall, and you learn who misses which feature.

The mechanic is well supported in modern billing systems. Stripe's trial offers include an upgrade trial pattern, where a customer on a basic plan gets a short trial of premium features at the basic rate and then automatically converts to the premium rate when the trial ends.

The reason I like reverse trials for B2B is that they change what expiry feels like. A standard trial ending is a loss event, and loss events make people defensive. A reverse trial ending is a downgrade the user can live with, which means they stay in your product, keep generating usage signals, and can convert later when a real need arrives. If you are still deciding which growth loop to build, my note on which product-led growth loop to build first covers where this sits in the sequence.

How would I pick a length for a product I had never seen?

I would start at fourteen days, instrument time to first value, and then move in one direction based on evidence rather than opinion. Fourteen is a reasonable default because it spans two working weeks, which covers the person who signs up on a Friday and forgets until Tuesday.

Then I would look for two specific signals. If a large share of converting users reach their first real result within the first two days, the trial is longer than it needs to be and shortening it will concentrate urgency without losing anyone. If most trials expire with the user still in setup, the problem is almost never length. It is onboarding, and extending the trial just gives people more time to stay stuck.

That second point is the one I will argue with anyone about. Extending a trial to fix poor conversion is treating a symptom. I have watched teams go from fourteen to thirty days, watch conversion stay flat, and conclude that trials do not work for their product. What did not work was an onboarding flow that never got anyone to a result.

The other thing I would do on day one is make the trial length visible and consistent everywhere. Your pricing page, your signup form, your emails, and your in-app banner should agree. Inconsistency here reads as carelessness on the exact page where the buyer is deciding whether to trust you, which is the same argument I made about the order you answer objections in on a pricing page.

What should you do next?

Open Amplitude, Mixpanel, PostHog, or whatever you use, and find the median number of days between signup and first real result for the users who converted last quarter. Compare it to your current trial length. If the two are far apart in either direction, you have your answer. If you cannot measure it, that instrumentation is the actual first job.

Then read your billing provider's own documentation on trials before you change anything, because the constraints there will decide what is cheap to run and what will quietly become a support burden. Strategy that ignores the implementation is just a preference.

If you want a second opinion on your trial design, or help instrumenting the part that tells you whether it is working, reach out. This is the kind of problem I enjoy, and it usually takes one conversation to see where the leak is. Let's chat.