Trial length is one lever on free-to-paid conversion, not the cause of it. Set the length to how long it takes a merchant to reach a first real result. Simple apps do well on 7 days, most land on 14, and only setup-heavy apps need 30. The credit-card question moves the number more than the length does.
- 14 days is the most common SaaS trial length, with 7 and 30 days far less common. Shorter trials with urgency tend to convert a higher share of starters than long ones.
- Card-required trials convert roughly three to four times the rate of no-card trials, because asking for payment filters out casual browsers.
- A Shopify free trial just delays the billing cycle by the days you set, applies only to new subscriptions, and can be extended through the Admin API.
- Pick by app complexity and time to value, then test the length and judge it on paying customers per install, not on trial starts.
Here is the honest answer before the nuance: trial length is a real lever, but it is not the lever. It is one knob on the same machine as your onboarding, your pricing, and your first-run experience. Founders ask me whether they should run 7, 14, or 30 days as if the right number will fix conversion. It will not. What fixes conversion is how fast a merchant reaches a first real result. Trial length only sets how much room they have to get there, and how hard the deadline pushes them to decide.
That said, the room and the deadline matter, so the choice is worth making on purpose. I founded and sold a Shopify-ecosystem SaaS, so I have lived the trial-length decision from inside a real funnel, not from a benchmark deck. This post isolates one variable, the trial itself, and leaves the full funnel and the headline benchmarks to the free-to-paid conversion breakdown. Here we are only on the trial: its length, its structure, the Shopify mechanics underneath, and how to choose.
The framing that helps most is this. Your trial has one job, to move a merchant from installed to convinced before the clock runs out. Everything about the trial should serve that job. The length is downstream of how long convincing takes. So the first question is never "how many days," it is "how many days until a merchant sees the thing that makes your app worth paying for." Answer that, and the length almost picks itself.
Length sets the clock.
Activation decides
who actually converts.
The mistake I see most is treating trial length as the cause of conversion when it is closer to a setting. If your app delivers an obvious result on day one, a 30-day trial does not convert better than a 7-day trial. It just gives a casual merchant three more weeks to forget why they installed you. If your app needs real setup before it does anything useful, a 7-day trial can expire before the merchant ever sees value, and you lose people who would have paid.
So the trial is a container for activation, and the length should fit the activation. This is why two well-run apps in the same category can land on different lengths and both be right. One reaches value in a day, one needs two weeks of data to show its worth. The benchmark tables you find online flatten that difference into an average, which is exactly why they mislead. The right length is a property of your app, not of the category.
That is also why I keep pointing founders back to onboarding before trial length. If you fix the first-run experience so a merchant reaches value faster, you can often shorten the trial and convert more, not less. The activation work is covered in the app onboarding benchmarks post, and it is genuinely the higher-leverage place to spend your time. Trial length is the tuning. Activation is the engine.
"The first question is never how many days. It is how many days until a merchant sees the thing that makes your app worth paying for."
How a Shopify free
trial actually works
under the hood.
Before you pick a number, understand what a Shopify trial actually is, because the platform mechanics shape your options. A free trial on Shopify simply delays the start of your app's billing cycle by the number of days you set. It is not a separate plan or a feature gate. It is a delay on the charge, applied through the Billing API when a merchant agrees to a new subscription.
A few specifics matter in practice. The trial applies only to a new subscription, so you cannot bolt a trial onto a merchant who is already paying. Charges from the trial period roll into the merchant's next invoice rather than billing separately, which keeps the merchant's accounting clean and your billing predictable. And the trial is tied to the subscription, so the clock is the subscription clock, not the merchant's separate Shopify store trial.
That last point trips up new founders. A merchant on a Shopify store trial who installs your app on day one of their store trial will still hit your app's billing on the day your app trial ends, even while their store is still in its own promotional period. The two clocks are independent. Your app charges on your schedule. It is worth knowing so you are not surprised when a merchant is, and so your support team can answer the question cleanly.
One more lever lives in the mechanics. Shopify does not give merchants a self-serve way to extend a trial, but as a developer you can extend one through the Admin API using the appSubscriptionTrialExtend mutation. That is genuinely useful. You can offer a few extra days to a merchant who got stuck in onboarding, or as a save move when someone is about to churn before they ever activated. Used well, a trial extension is a targeted rescue, not a blanket giveaway. The broader pricing structure that the trial sits inside is in the app pricing strategy post.
What 7, 14, and 30
days each do to
your funnel.
Now the actual comparison. Across SaaS, 14 days is the dominant trial length, used by the clear majority of products, with 7-day and 30-day trials each far less common. That convergence is not an accident. Fourteen days tends to give enough room for setup while still keeping the deadline close enough to force a decision. But the default is a starting point, not your answer. Here is what each length does.
| Length | Best for | The trade-off |
|---|---|---|
7 days Short, high urgency | Simple apps that show value on day one, low-price tools, impulse installs | Tight deadline drives a fast decision, but expires before value if setup is slow |
14 days The common default | Most apps, the balanced middle, anything needing a little setup time | Enough room to activate and still keep urgency, the safe starting point |
30 days Long, low pressure | Setup-heavy apps, data-dependent tools, higher-price or sales-led products | Room for complex value, but a long runway lets casual users drift and forget |
The pattern underneath the table is consistent across the benchmark research: shorter trials with real urgency tend to convert a higher share of the merchants who start them than long, low-pressure trials do. The reason is behavioral. A close deadline forces a decision while intent is still fresh. A long one lets the install go cold. A 30-day trial is not "more generous" in any way that helps you, unless your app genuinely needs that long to prove itself. Most do not.
This is the counterintuitive part for founders who think a longer trial is a gift to the merchant. It often is not. The merchant who needs 30 days to decide is frequently the merchant who was never going to pay, and the extra weeks just delay the churn while inflating your active-trial numbers. If your app reaches value quickly, a shorter trial concentrates the decision and usually converts a better share of starters. The math behind trial economics, and why a small conversion change swings your whole model, is in the app economics post.
The credit-card question
moves conversion more
than the length does.
Here is the lever most trial-length debates skip. Whether you ask for a credit card up front matters more to your conversion rate than whether you run 7, 14, or 30 days. The two structures are not small variations on the same thing. They produce completely different funnels, and you have to decide which one you are running before the length question even makes sense.
| Structure | Trial-to-paid rate | What it does to the funnel |
|---|---|---|
Card required Opt-out, auto-converts | Roughly 3 to 4x the no-card rate | Far fewer starts, but most of them already intend to pay. Filters out browsers. |
No card Opt-in, manual upgrade | The lower headline rate | Many more starts, most never intended to pay. Volume up, rate down. |
The benchmark research is blunt on this. Card-required trials convert a far higher share of starters than no-card trials, commonly in the range of three to four times the rate. But read that carefully, because it is selection bias doing the work, not product magic. Asking for a card filters out the casual browser before they ever start. The people who enter payment details were already leaning toward paying. The card did not convince them, it screened them.
So the higher conversion rate is partly an illusion. What you actually care about is paying customers per visitor, not the conversion rate in isolation. A no-card trial can pull so many more starts that even at a lower rate it produces more customers, or it can flood your funnel with tire-kickers who cost you support and never pay. There is no universal winner. There is only the answer for your app, your price point, and your acquisition. Run the number on real customers per install, which is exactly what the free-to-paid conversion calculator is built to do.
My operator bias, for what it is worth: lower-priced impulse apps usually do better with a no-card trial and a short clock, because the friction of a card request kills the impulse. Higher-priced or sales-adjacent apps often do better asking for the card, because the merchants who clear that bar are the ones worth your activation effort. But treat that as a hypothesis to test, not a rule. The point of understanding the trade is that you stop arguing about days and start choosing a structure.
Pick the length by
how long your app
takes to prove itself.
Put the pieces together and the decision rule is simple. Find your time to first value, the number of days it realistically takes a merchant to reach a result they would pay for, then set the trial just past it. Not way past it, just enough room to activate plus a small buffer. The trial should end shortly after the merchant has seen what they came for, while the value is still fresh and the deadline still bites.
In concrete terms, that breaks into three rough buckets. A simple app that delivers on install, a popup, a badge, a quick automation, can run 7 days because the merchant sees value almost immediately and a tight clock just sharpens the yes. A standard app that needs a bit of configuration, a connected catalog, or a day or two of data lands on 14 days, the safe middle, which is why most apps live there. And a setup-heavy app, one that needs integrations wired up, history accumulated, or a team to adopt it, earns a 21 to 30 day window because the value genuinely takes that long to surface.
The trap is picking long because it feels safer. It rarely is. A longer trial is only justified when your activation genuinely takes longer, and if it does, your real problem may be the activation, not the trial. I would rather see a founder shorten time to value and run a 14-day trial than paper over slow onboarding with a 30-day runway that lets people drift. If you are watching trial users churn before they convert, that is usually a symptom, and churn as a symptom rather than the problem is the lens I would bring to it.
One more thing for early-stage apps. If you are still finding product-market fit on your way to your first meaningful revenue, do not over-engineer the trial. Pick a sane default, 14 days with or without a card based on your price point, and spend your energy on activation and the product itself. The trial-length optimization pays off later, once you have enough volume to read a test. The early road to that point is in the MVP to 1M ARR post.
Test the length,
change one thing,
judge it on the right number.
Trial length is one of the cleaner things to test, which is a gift, so use it. The change is small, the implementation is a single setting, and the effect shows up in your trial-to-paid rate within a cohort or two. There is no excuse for treating it as a permanent decision you made once at launch and never revisited. Pick a hypothesis, ship it, read it, keep or revert.
The metric discipline is the part founders get wrong most often. It is easy to celebrate a higher conversion rate after shortening the trial, then miss that total paying customers actually dropped because fewer people started. Or to add a card requirement, watch the rate jump, and not notice you cut your customer count in half. The headline rate is a vanity number on its own. Customers per install, and ultimately revenue per install net of churn, is the truth.
So, back to the question that started this. Seven, fourteen, or thirty days? The answer is whichever sits just past your app's time to first value, decided alongside the bigger card-versus-no-card choice, and confirmed by a clean test on real customers per install. Fourteen days is the sensible default to start from. Shorter if you deliver fast, longer only if your value genuinely takes longer to surface. The number matters, but it matters less than the activation it contains. Get the merchant to value sooner, and almost any reasonable trial length will work. That is the lesson from running the decision myself, on a real funnel, with my own money on the line.
What app founders ask me
about trial length
and structure.
Match the trial to how long it takes a merchant to reach a first real result. Simple apps that deliver value on day one do well on 7 days. Most apps land on 14 days, the most common length in SaaS, because it gives enough room to set up and still keeps urgency. Reserve 30 days for apps that need heavy setup. The longer you go, the more activation work the trial has to carry, which is the case I make in the onboarding benchmarks post.
Length alone does not set conversion, activation does, but the pattern is consistent. Shorter trials with real urgency tend to convert a higher share of starters than long, low-pressure ones, because the deadline forces a decision while intent is fresh. 14 days is the common default. A 30-day trial is not better by default, it just gives a casual user more time to forget why they installed. The full funnel math is in the free-to-paid conversion post.
It depends on what you are optimizing. Card-required trials convert a far higher share of starters to paid, often three to four times the rate of no-card trials, because asking for payment filters out casual browsers. No-card trials pull far more starts but most never intended to pay. The right call is whichever produces more paying customers per visitor for your funnel, not the higher headline rate. The pricing context is in the app pricing strategy post.
A Shopify app free trial delays the start of the billing cycle by the number of days you set. The trial only applies to a new subscription, and charges from the trial roll into the merchant's next invoice. Shopify does not offer a merchant-facing way to extend a trial, but developers can extend one through the Admin API using the appSubscriptionTrialExtend mutation, which is useful for save offers and onboarding rescues.
Yes, and you should test it rather than guess. Trial length is one of the cleaner levers to experiment with because the change is small and the effect shows up in your trial-to-paid rate within a cohort or two. Change one thing at a time, give it enough volume to read, and judge it on paying customers per install, not on trial starts or the conversion rate in isolation. If trial users churn before they convert, treat that as a symptom, as I argue in the churn post.
Tuning your trial, your pricing, or your free-to-paid funnel?
I founded and sold a Shopify-ecosystem SaaS, so trial design, activation, and the math behind free-to-paid are things I have run with my own money on the line, not theory from a benchmark deck. If you are weighing a trial-length or card-requirement decision, that is the view I bring.
Start a conversation See the case studies →A note on sources: SaaS trial-length distribution (14 days as the dominant length) and the pattern that shorter, urgency-led trials convert a higher share of starters draw on cross-industry benchmark analyses including ChartMogul's SaaS Conversion Report and Userpilot's free-trial benchmarks. The card-required vs no-card gap of roughly three to four times is from the same body of opt-in vs opt-out research. The Shopify trial mechanics, billing-cycle delay, new-subscription scope, and the appSubscriptionTrialExtend mutation, are from Shopify's developer docs on offering free trials. The read on activation as the real lever, the bucketing by app complexity, and the testing discipline are mine, from founding and selling a SaaS in this ecosystem.