Building a SaaS Free Trial That Converts to Paid
Free trials are the single highest-stakes moment in your SaaS funnel. Get the design right and you're compounding revenue. Get it wrong and you're running an expensive demo service for people who were never going to pay.
I've wired trial billing flows into a few products now — most directly in BookBed, a property management SaaS on Flutter and Firebase, where the Stripe trial lifecycle sits inside a live production system. This post is what I'd tell a founder before they touch a line of billing code.
Does Requiring a Credit Card at Signup Actually Work?
Yes, by a lot — and most products still won't do it.
ChartMogul's January 2026 analysis of 200 B2B SaaS products found that products requiring a credit card at trial signup convert at more than 5x the rate of those that don't. The exact figure for card-required trials was above 30% free-to-paid, compared to a median of 8% for the broader market. Only 20% of SaaS companies require a card upfront, which means the other 80% are leaving that conversion lift on the table.
The mechanism is straightforward: requiring a card is a commitment signal. People who hand over payment details have skin in the game. The friction filters for intent. You trade signup volume for signup quality, and for most B2B products, quality wins.
That said, opt-in trials (no card required) convert at 18–22% on average and have a place: early-stage products that need volume to discover who their real users are. If you don't know your ideal customer profile yet, the card barrier costs you signal you can't afford to miss. Once you know who converts, add the card requirement.
| Model | Avg. Conversion | Signup Volume | |---|---|---| | Opt-in (no card) | 18–22% | High | | Opt-out (card required) | 48–55% | Lower | | Freemium | 2–5% | Very high |
How Long Should Your Free Trial Be?
Fourteen days. For almost every product.
Most founders default to 30 days because it feels generous. The data says the opposite. Ordwaylabs' research on trial length shows 14-day trials convert at a 19% median versus 14% for 30-day trials. The counterintuitive part: 90% of users make their decision within the first five days, regardless of how long the trial runs. Give someone 30 days and they'll procrastinate for 25 of them.
Shorter trials with urgency cues consistently outperform 30-day trials when users reach their activation moment before the clock runs out.
That last clause is the catch. Shorter is better only if you've already solved the time-to-value problem. If your product takes three days to set up and your core value reveals itself on day five, a 7-day trial will fail regardless of urgency. Map your actual time-to-value before picking a number. Complex products with integration dependencies (ERP, multi-seat tools requiring IT sign-off) legitimately need 21–30 days. Most don't.
What Should Happen Inside the Trial?
This is where most products fail. They pick a trial length and credit card model, then do nothing with the user for 14 days. Then they wonder why 90% churn.
Your job during the trial is to manufacture the activation moment as early as possible — the specific point where the user feels the product's value viscerally, not conceptually.
Day 1 email: not a welcome, a first action. Most onboarding welcome emails tell the user what the product does. They already know. Send one clear instruction: "Do this one thing right now." For BookBed, that moment is watching the calendar populate from an iCal link. I built the configuration wizard to drive straight there. No product tour, no feature checklist. One thing.
Day 3: behavioral trigger, not calendar. Segment your trial users by what they've done (or haven't). Users who completed setup but haven't invited a teammate get a different email than users who haven't opened the product since signup. Customer.io or Loops will fire these off based on event data; don't send calendar-based blasts to everyone.
Days 7–11: in-trial dunning. Sunday at 9am — that's when these emails land best for most B2B tools, based on open-rate data from Resend. The message changes from "here's what you can do" to "here's what you've already done." Usage summaries, data they've created, integrations they've connected. Concrete.
Day 11 (or 3 days before expiry): the Stripe wire fires.
Stripe's customer.subscription.trial_will_end webhook fires exactly 3 days before a trial ends. If your trial is 14 days, that's day 11. This is your wire for the final conversion push. Handle the event server-side; send the most direct upgrade email in the sequence. Not "trial ending soon" — "your trial ends in 3 days. Click here to keep access." You can also surface an in-app banner from this same webhook. In BookBed, the webhook fires, a flag writes to Firestore, the app reads it and shows a persistent upgrade prompt.
The glossary has a full breakdown of how Stripe webhooks work if you need the event lifecycle explained.
The Silent Trial Extension Trap
Here's a mistake I see operators make: someone logs in on day 12 and hasn't converted, so support grants them a 7-day extension. Then another. Then another. Four weeks later they're running a 42-day trial for someone who showed up three times.
Trial extensions are only useful for one type of user: someone who engaged heavily with the product but hit a blocker — a broken integration, a permission issue, a question that didn't get answered. Those users have demonstrated intent. An extension can tip them.
For everyone else, more time isn't the answer. If someone hasn't logged in since day 2, giving them 7 more days gives you 7 more days of anxiety with the same outcome. The extension makes you feel like you did something. It changes nothing.
The rule I follow: only offer an extension to users who've triggered at least 3 core events (actual feature usage, clicks on real features, data created) and haven't yet added a payment method. Everyone else gets the standard expiry and a re-engagement email at 30 days post-expiry.
How to Wire This in Stripe
The Supabase + Stripe integration guide covers the full billing setup, but here's the trial-specific layer.
When creating a subscription with Stripe Billing, you have two approaches. The legacy path uses trial_end as a Unix timestamp:
trial_end: Math.floor(Date.now() / 1000) + 14 * 86400
The newer Trial Offer API (launched in preview during 2025) is cleaner but requires a Stripe-Version: 2026-03-25.preview header and flexible billing mode. Most Checkout-based implementations still use the legacy path — Stripe's documentation confirms the Trial Offer API doesn't support Checkout sessions yet.
For opt-in trials (no card required at signup), create the subscription with payment_method_collection: 'if_required'. Users start the trial without a card. When the trial_will_end webhook fires, you surface the upgrade prompt and collect payment then.
For opt-out trials (card at signup), the subscription creates with the card on file. Stripe auto-charges when the trial ends unless the user cancels. Your job is to handle the customer.subscription.trial_will_end event and send a transparent "you'll be charged X on Y date" email — both ethically required and legally required in most jurisdictions.
One gotcha worth knowing: when a trial ends, the billing_cycle_anchor resets to trial end by default. The first billing cycle starts from trial end, not from signup date. Usually fine — but if you've communicated "your card will be charged on the 15th" and the trial ends on the 12th, the first charge happens on the 12th. Align your messaging to what Stripe will actually do, or your first chargeback arrives before your first paying month is over.
What a Good Trial Dashboard Looks Like
If you're running trials at any volume, watch four numbers daily:
- Trial activation rate — percentage of signups who reach the activation moment within 72 hours. This is your primary leading indicator. Below 40% means your onboarding is the problem, not your pricing.
- Trial-to-paid conversion rate: the headline metric. Aim for 15% with no-card opt-in; 35%+ with card required.
- Day-0 to Day-3 churn: people who sign up and never return. High early churn usually means landing page promise doesn't match product reality.
- Extension rate: if you're granting a lot of extensions, your trial length is wrong or your activation moment is too late.
A well-designed B2B SaaS product makes these numbers visible from day one, instrumented into your analytics from the first deploy. Trying to reconstruct them from raw event logs six months in is genuinely painful.
Pricing Transparency at Trial Signup
This one bites products at trial expiry more than anywhere else.
If you require a credit card at signup for an opt-out trial, the pricing must be visible before the card field. Not a modal after. Not a small link that says "see plans." The monthly cost, the billing date, the cancellation policy — all on the signup page. This is a chargeback reduction measure as much as an ethics one. Chargebacks spike when users feel tricked at first charge. That spike affects your Stripe account health in ways that compound badly.
The SaaS MVP stack guide covers building the billing flow in a way that avoids these edge cases from the first deploy.
The conversion math on free trials is mostly solved. Credit card at signup, 14-day trial, heavy instrumentation for the first 5 days, trial_will_end webhook handled server-side. What's hard is the activation moment — that's specific to your product, and no framework hands it to you.
What's your current trial-to-paid conversion rate? And which part of the trial lifecycle is the actual bottleneck?