AL+

RO EN

Email us

B2B SaaS free trial length: set it by time to first value

Fourteen or thirty days? For B2B software the trial should match the time a customer needs to reach first real value. Measure it before you pick a number.

. By . Software business

Citiți articolul în română

A fourteen-day free trial can expire before a B2B buyer has had time to evaluate the product. A business buyer often needs weeks to integrate, import data or get a purchase approved. The trial should last until the customer has reached first real value, and if your product cannot get a willing customer there in fourteen days, the first fix is usually onboarding work, not a longer timer. Where the delay is the customer's calendar rather than your product, a timer is the wrong tool altogether.

What Keygen found in 2024

On 3 May 2024, Zeke Gabrielse, the founder of the licensing API Keygen, published an account of his own trial numbers. He had started with a fourteen-day free trial. Customers struggled to integrate a licensing API into their stack in that time, so he began offering extensions. Over the next couple of years, he wrote, the majority of converting customers had asked for one, and conversion was higher when they did.

He first required a card on file before extending a trial, then dropped that step because the back-and-forth was a nuisance. By his account conversion did not suffer, which ruled out the card as the explanation.

The number that mattered was what he called time-to-convert: the days from sign-up to first payment. His median was 41 days. The 90th percentile was 130 days, the 95th 198 and the 99th 290. He had been giving customers fourteen days to reach a decision that, for the typical paying customer, arrived after six weeks. In his words, he was really asking them to wait: until they were ready to read the documentation, until a proof of concept was planned, until a developer was free. Many saw the deadline approach, decided they were not ready, left, and never came back.

His fix was the one bootstrappers are told to avoid: an unlimited trial, in effect a free tier. Gabrielse reported that sign-ups rose. Looking only at customers who went on to pay, he reported that paid sign-ups also increased, conversion stayed steady and the manual extension work disappeared.

The post drew a long Hacker News discussion on 6 May 2024. One commenter described an evaluation team whose rule is a minimum of thirty days, no payment and no crippled features, and who still found thirty days stressful for getting a system running with their own test data. Gabrielse added in the thread that his free tier is limited, with usage caps such as 100 active users and 2,000 API requests a day, so it cannot carry a production deployment. The pressure to pay arrives once the customer has actually integrated, not before.

Two years on, Keygen's pricing page still describes the Dev tier as a limited free tier meant for "the integration and development phase", with hard limits that return an error when reached, and offers a 30-day trial of its self-hosted Enterprise Edition on request. The arrangement has lasted.

The argument: the clock should measure value, not calendar

The usual debate about trial length compares aggregate conversion for 14-day and 30-day trials across many companies. That comparison hides the variable that decides the answer: how long it takes your customer to reach the point where "is this worth paying for?" can be answered at all. For a note-taking app that might be an afternoon. For an API that has to be wired into a release pipeline, or a back-office tool that needs a year of invoices imported, it can be weeks.

A trial that ends before that point does not test the product. It tests whether the buyer happened to have a free fortnight. The customers it filters out are not necessarily poor fits; many are busy companies with a real need and a queue of other work.

So the length of the trial is an output, not an input. You measure how long successful customers take to reach first value, and set the trial around that. Then you look at what fills those days.

Separate work time from waiting time

This is where the thesis needs care, because Keygen's own fix was not better onboarding. It was taking the timer away. Both responses are right, for different parts of the delay.

Work time is what the customer spends doing things with your product: reading the documentation, creating accounts, mapping fields, writing the first integration, importing data. This is your problem. Sample data, a working example in the customer's language, an importer that accepts the spreadsheet they already have, a setup call for the step everyone gets stuck on: each of these shortens the path, and a longer timer fixes none of them. If customers who start in earnest still need three weeks of work to see anything useful, extending the trial to thirty days only gives them more time to stall.

Waiting time is the gap between sign-up and the moment they can start: the developer is on another project, the budget holder is on holiday, security wants a questionnaire answered. You cannot onboard your way out of that. A calendar trial punishes it, which is the pattern Gabrielse described. A usage-limited free tier, or a trial whose clock starts at first real use, fits better.

Most products have some of both. The practical question is which one dominates for your customers.

How to measure it in a small product

You do not need an analytics platform. Gabrielse's post includes a Stripe Sigma query for time-to-convert. Time to first value is the more useful companion, and it needs only one decision: which event means the customer got something real. For a licensing API it might be the first license validated from a customer's own build; for an invoicing tool, the first invoice sent to a real client.

If you record events in PostgreSQL, a query along these lines gives the distribution (table and event names are examples):

SELECT
  percentile_cont(0.5) WITHIN GROUP (ORDER BY days) AS p50_days,
  percentile_cont(0.9) WITHIN GROUP (ORDER BY days) AS p90_days
FROM (
  SELECT a.id,
         EXTRACT(EPOCH FROM MIN(e.created_at) - a.created_at) / 86400 AS days
  FROM accounts a
  JOIN events e ON e.account_id = a.id
  WHERE e.name = 'first_production_use'
    AND a.created_at > now() - interval '1 year'
  GROUP BY a.id, a.created_at
) t;

Two cautions. The query includes only accounts that reached the event, so it describes successful customers, not those lost to the deadline. Also record the first meaningful action after sign-up. The gap from sign-up to that action and the gap from that action to first value are elapsed-time proxies for waiting and evaluation. Both can include idle time, weekends and further waits. Measuring active work requires session or activity data, or customer interviews; timestamps alone cannot separate it.

The strongest counterargument

Short trials exist for reasons. Kyle Poyar's guide to reverse trials on Growth Unhinged sets out the trade-off: free trial products often see two to three times the free-to-paid conversion of freemium ones, because a deadline forces a decision, and they convert faster, with a median time to purchase that "might be 14 days" against 60 or 90 for a freemium product. For a small company paying for acquisition, that cash timing matters.

There is also the sales-side objection, made in the Hacker News thread: prospects who need endless extensions are often window-shopping, and long trials let them consume support without intending to buy. Another commenter pointed out a selection effect in Gabrielse's first observation, since people who ask for an extension are already the interested ones. He answered that the claim was about total conversion going up when he offered extensions, which is fair, but it remains one company's account, not a controlled experiment.

Both objections are real. Neither defends an arbitrary fourteen days. A deadline creates urgency only if the customer could have reached a decision before it. The reverse trial Poyar describes, full features for a limited time and then a free tier, is itself a way of keeping urgency without discarding the slow buyer.

Where this does not hold

If your product delivers value in the first session, a short trial is fine and a free tier may just give away revenue. If your product's free usage costs you real money, such as heavy compute or human support, an unlimited tier needs firm limits or it becomes a subsidy. And for software sold to a handful of larger companies, a self-serve trial may be the wrong frame entirely. An assisted pilot with an agreed scope, a named contact on each side, success criteria written down before it starts, and an end date tied to those criteria often serves both sides better than any timer. That holds especially when setup involves the customer's data or another system, the kind of work that custom software development usually involves. If you are still deciding what the first release should even contain, MVP vs prototype covers that earlier choice.

The position

Do not pick fourteen or thirty days because a benchmark says so. Measure how long your paying customers take to reach first value, shorten the work part with onboarding, and stop the clock from punishing the waiting part. The trial is long enough when a willing customer can reach a real decision inside it.

Sources