A&A INSIGHTS
Before you ship a free trial for your solo AI product: define the job and the usage ceiling
A fourteen-day free trial suspends the customer's invoice, not your inference bill. For solo developers shipping an AI product, this article separates the period, the execution ceiling and the end-of-trial behaviour into three controls, using Stripe and Cloudflare AI Gateway documentation.
日本語で読む
THE STARTING POINT
Written for the solo founder of an AI product about to open the same generation pipeline to people who have not paid. Reading Stripe's free trial specification alongside Cloudflare AI Gateway's rate limiting specification exposes two boundaries: a trial suspends billing rather than usage, and a rate limit caps speed rather than cumulative volume. From there the article sets the ceiling in units of one finished job, chooses deliberately between cancel, pause and invoice at the end of the trial, and gives six settings to lock down before launch. Source statements, A&A interpretation and hypothetical settings stay distinct; no recommended day counts or adoption outcomes are claimed.
“14 days free” is not a ceiling on your inference bill
A&A perspective
This is for the solo developer building an AI product who is about to open the same generation pipeline to people who have not paid. When you sit down to design a free trial, the first question that comes to mind is usually how many days it should run. But a number of days is a control that lives inside your billing system. The control over how many times the model may actually run is not there. If you try to cover both with a single setting, the promise you make to the user and the API invoice that arrives in your own inbox will drift apart. This article separates three decisions - the period, the execution volume and what happens the moment the trial ends - using vendor primary documentation from Stripe and Cloudflare, and closes with six settings that include your signup flow.
From the sources
The legacy free trial document states that if you’re building a new integration, Stripe recommends that you configure trial offers on subscriptions instead. That trial offers document states that trial offers enable you to qualify high-intent leads, reduce trial abuse, and provide discounted rates to your customers for a limited duration. The page is in public preview: it says your integration must specify the 2026-03-25.preview version in the request header, and that subscriptions must use the flexible billing mode. It also lists the integrations that do not support trial offers - Checkout, Payment Links, and Elements with Checkout Sessions - and for Checkout it directs you to legacy free trials with the trial_end parameter instead.
From the sources
The document describing that legacy path explains that you can start a subscription with a free trial by passing trial_end, a timestamp for the exact moment the trial ends, or trial_period_days, an integer number of days from now. It states that the trial period must be 730 days (2 years) or less. It also notes that when you create a subscription with a trial period you do not need to add a payment method, and that an immediate invoice is still created with an amount of 0.
From the sources
The usage-based billing section of the same document states that Stripe does not bill for usage recorded during the trial period, but that you can view the usage in the meter event summary for the trial period. After the trial period ends, billing resumes for recorded usage.
A&A perspective
Read those two statements together and the boundary becomes visible: a free trial suspends billing to the customer, not usage itself. In our reading this is the line solo developers miss most often. The usage is still being recorded, and if it is being recorded then inference is genuinely running behind it. A customer invoice of zero and an API statement of zero are two completely different things.
Put the execution ceiling outside the billing system
From the sources
The Cloudflare AI Gateway rate limiting document describes rate limiting as something that controls the traffic that reaches your application, which prevents expensive bills and suspicious activity. It states that you can define rate limits as the number of requests that get sent in a specific time frame, and gives the example of limiting an application to 100 requests per 60 seconds.
From the sources
The same document distinguishes fixed from sliding windows. With a limit of ten requests per ten minutes starting at 12:00, the fixed windows are 12:00-12:10, 12:10-12:20 and so on, so ten requests at 12:09 and ten more at 12:11 would all succeed; under a sliding window they would fail, because more than ten requests were sent in the last ten minutes. When requests exceed the allowed rate, the document states that the server responds with a 429 Too Many Requests status code and the request is not processed. To set the default configuration through the API, it says to send a POST request that creates a new gateway and to include values for rate_limiting_interval, rate_limiting_limit and rate_limiting_technique.
A&A perspective
What this specification tells you is that a rate limit governs speed, not cumulative volume. When the window rolls over, the allowance comes back. A free trial, however, usually needs a cumulative ceiling - a total number of jobs, ever. A setting of five requests per sixty seconds does nothing to stop someone who keeps using the product all day. If you want to stop the total, you need a consumption counter inside your own application, separate from the gateway's rate limit. That is our design reading, not a claim made by the source.
A&A perspective
There is a second boundary: a gateway rate limit only applies to calls that actually go through the gateway. If an admin batch job or an internal script calls the model API directly, that traffic is not being counted. Before you design a trial ceiling, write down which code paths are inside the measured perimeter and which are not.
| Decision | Where the control lives | What happens if you skip it |
|---|---|---|
| Definition of one job that can be tried free | Your own application - neither billing nor the gateway | Users cannot tell what they are allowed to try, and sign-ups never complete a first job |
| Total number of free jobs | A consumption counter in your own application | The allowance returns every time the window rolls over, so per-person cost has no ceiling |
| Requests allowed per time window | Gateway rate limiting (time frame and request count) | Bursts and automated access spike a single day's bill |
| Trial length and end behaviour | Billing trial settings - cancel, pause or invoice | The trial does not stop, or it disappears silently and the path back is cut |
| Timing and channel of the pre-end notice | Billing trial messaging settings - separate what the billing platform sends automatically from what you build | The charge reads as a surprise, producing a refund request and a cancellation at once |
| Effort needed to create one account | The signup flow - verification or captcha | Per-person ceilings stop binding and cost is multiplied across duplicate accounts |
Make the unit one finished job, not one request
A&A perspective
A ceiling expressed in requests means nothing to the person reading it. Nobody who is told “up to 20 requests free” can work out what they are actually allowed to try. Worse, a single valuable experience is usually made of several requests - preprocessing, the main call, a retry, a rewrite. The internal call count changes whenever you refactor, so if you make it the unit of your promise, your promise moves every time you touch the implementation.
A&A perspective
Our proposal is to set the ceiling in units of one finished job, and keep the request count inside as a cost metric only. A job is the whole chain of processing needed to produce one artifact the user would call done. Then decide separately how many retries you allow per job. If retries are unlimited, the cost of a single job has no ceiling at all.
Hypothetical example
A hypothetical example. Suppose you are building a service on your own that turns meeting recordings into minutes. Define one job as: from a single audio file of up to sixty minutes, produce one set of minutes. Internally that runs one transcription, one summarisation and one formatting pass, and the user-facing “regenerate” button is capped at two uses per job. The free trial allows three jobs in total. If a regeneration re-runs only the summarisation and formatting passes and not the transcription, your worst case per person is three hours of transcription and nine summarisation calls. If regeneration restarts from transcription, the same settings cost three times as much transcription. Write that assumption down, or the ceiling does not mean what you think it means. Every number here is invented to make the structure concrete; none of it is an A&A measurement.
Choose one of three behaviours for the moment the trial ends
From the sources
For trials started without collecting payment details, the Stripe document explains that you set the end behaviour with the trial_settings end_behavior missing_payment_method parameter. With cancel, a free trial subscription that ends without a payment method cancels immediately. With pause, it pauses and does not cycle until it is resumed; while paused it does not generate invoices, and when the customer adds a payment method afterwards you can resume the same subscription. The document states that the subscription can remain paused indefinitely. With create_invoice, Stripe invoices at the end of the trial, and if no payment method is present when the invoice finalizes the subscription moves into past_due.
From the sources
The same document notes that a few days before a trial ends and the subscription moves from trialing to active you receive a customer.subscription.trial_will_end event, and advises that on receiving it you make sure a payment method is on the customer account so you can bill them, optionally giving the customer advance notice of the upcoming charge. The same document adds that you can configure reminder emails to collect customer payment details in your free trial messaging settings, and configure your subscription to automatically send a reminder email when the customer’s trial is about to expire.
A&A perspective
These three options are also a choice about what you leave the user. Cancelling severs the relationship; pausing stops the meter while keeping their settings and history. In our reading, pause is likely to fit AI products more often, because the context a user built during the trial - a glossary, tone preferences, saved prompts - is precisely their switching cost. Delete it and a returning user starts from zero. But if you choose pause, you have to decide for yourself how long a paused account survives and write that into your terms. The fact that the platform lets you pause indefinitely is not an argument that you should.
Drop the card requirement and your ceiling gets multiplied by account count
From the sources
Stripe attaches a security note to starting free trials without collecting payment details. It says that while starting a free trial without a payment method lets your potential customers try your product or service faster, it can also allow spammers to create lots of fake customers, usage, and subscriptions. It recommends carefully considering the signup flow to balance making it easy for real customers and difficult for spam bots to abuse, giving the example of requiring customers to create a user account and complete a captcha before starting their free trial subscription.
A&A perspective
This is where a per-person execution ceiling quietly fails. Three jobs per person becomes thirty if someone opens ten accounts, and gateway rate limits are diluted the same way because they too are scoped to an account or a key. In our framing there are two numbers to set, not one: the ceiling per person, and the effort required to create one more account. Push only the first down and you starve genuine users; push the second up too far and nobody tries the product at all. Which lever you move depends on what one job actually costs you.
Six settings to lock down before you ship
A&A perspective
Here is the whole argument as six settings to lock down before the trial goes live, one for each row of the table above. First, the definition of one job that can be tried for free, and the retry cap per job. Second, the total number of free jobs. Third, the per-window ceiling and the exact wording shown on screen when it is hit. Fourth, the length of the free period, what happens when it ends - cancel, pause or invoice - and, if you chose pause, how long paused data is retained. Fifth, how many days before the end you notify and through which channel, separating what the billing platform can send automatically from what you have to build. Sixth, how much friction you put in front of creating one more account - identity checks, a captcha, or nothing. The first two live in your own application, the third in the gateway, the fourth and fifth in billing, and the sixth in your signup flow. With those six settled, the pricing page and the terms of service can be written straight from them. If one is still open, it is safer to hold the launch until it is decided.
Hypothetical example
A hypothetical filled-in version. One job is one set of minutes from one audio file of up to sixty minutes, with two regenerations per job. Three free jobs in total. At most one job per hour, and when that is exceeded the screen shows how many minutes remain until the next job can start. The period is fourteen days; at the end the subscription pauses, paused data is retained for ninety days and deleted after that. The reminder three days before the end is left to the billing platform's own setting, and only the in-app notice on the day is built by hand. Creating an account requires email confirmation and a captcha, with a delay between repeated sign-ups from the same domain. Every value here is a placeholder for the sake of the example - not a recommendation and not a measurement. Work out your own cost per job first, then settle the same six with your own numbers.
What this article does not guarantee, and the next step
A&A perspective
Four limits. First, both the Stripe and the Cloudflare statements quoted here are vendor technical documentation, not an independent audit and not a measurement of results; a specification working as described says nothing about whether the design fits your business. Second, the Stripe trial offers page is in public preview, so its supported versions and eligible UI integrations can change - reread the current document immediately before you implement. Third, the Cloudflare rate limit only applies to calls that traverse the gateway, and it does not constrain token consumption within a single request. Note that the same documentation set lists a separate spend limits feature, marked beta, alongside rate limiting. It may bear on cumulative spend, but we did not read that page and make no claim about how it behaves. Fourth, every number in the worked examples is an invented setting, not an A&A observation of cost, conversion or retention.
A&A perspective
The next step is to count how many of the six settings are still open. If only the third and fifth are missing, what remains is implementation work. If the first is open - the definition of one job - go back to product design rather than trial design. A service that has not decided what counts as one job cannot write its paid plan description either. Ceiling design only starts to mean something once the shape of the product is settled. If you are already assembling the paid plan that sits behind the trial, “How to explain credits in an AI SaaS plan: show the usable amount and the extra spend” covers grants, expiry and how to display the remaining balance. For the whole arc from acquisition through retention, see “AI-native GTM: a practical guide for solo founders and small teams”.
Free trial design does not start with a number of days. The period suspends billing and the rate limit caps speed, but neither one decides how many jobs a non-paying user may run. The unit of the job they can try, the total number of free jobs, the per-window ceiling, the period and its end behaviour, the notice before it ends, and the friction on creating an account: settle those six in your own words before launch and users can read what they are allowed to try, while you know your worst-case cost per person in advance. Whatever you leave undecided comes back next month as an API invoice and a support thread.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Use free trial periods on subscriptions | Stripe Documentation
Stripe · n.d.
Accessed 2026-09-24 - Configure trial offers on subscriptions | Stripe Documentation
Stripe · n.d. (public preview)
Accessed 2026-09-24 - Rate limiting · Cloudflare AI Gateway docs
Cloudflare · Last updated Jun 5, 2026
Accessed 2026-09-24
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-09-24