What Should Your App Do on the Day a Trial Ends?
What Should Your App Do on the Day a Trial Ends?
Keep the person's work visible, make paying obvious, and never delete anything on day one. The best trial endings leave the account read-only: everything they built is still there, still viewable, and one click from being usable again.
Most products get this wrong in one of two directions. Either the account slams shut and the work vanishes behind a paywall, or nothing happens at all and the trial quietly continues forever.
Both are design failures with commercial consequences, and the fix is a small set of deliberate decisions rather than a big build.
Why Does the Last Day Matter More Than the First?
Because it is the only moment when the user has both invested effort and faced a decision. On day one they have nothing at stake. On the last day they have a workspace, some data, and a half-formed opinion.
That combination is the entire buying decision, compressed. Whatever the interface does at that moment either shows them what they would lose or makes them feel trapped, and those produce opposite outcomes.
It is also the cheapest moment to influence. You do not need to change the product to change what the last day feels like. You need to decide what happens to their work.
What Are the Three Possible End States?
Read-only, restricted, or locked. Choosing between them is the main decision, and most products should choose the first.
Read-only means everything is visible and nothing can be changed. They can see their dashboard, open their records, and export. They cannot create, edit or invite.
Restricted means the product keeps working at a reduced level, usually a free tier. Locked means the account is inaccessible until payment.
Locked is the only one we would argue against in almost every case. It converts a hesitant evaluator into someone who feels their own data is being held hostage, and that feeling is remembered long after the discount expires.
Why Is Read-Only the Strong Default?
Because it makes the value concrete at exactly the moment the person is deciding. A dashboard they can still see, full of their own data, is a far better argument than any upgrade page.
It also removes the worst objection to paying, which is uncertainty about whether the work survived. Someone who can see their thirty configured records knows precisely what they are buying back.
And it keeps the door open for the most common conversion path, which is not the last day at all. It is three weeks later, when the project that prompted the trial actually gets budget. Read-only accounts convert then. Deleted ones do not.
What Should the Interface Actually Say?
What changed, what is safe, and what to do next, in that order and without euphemism. Three sentences is usually enough.
State plainly that the trial ended and editing is off. State that their data is intact and will be kept. State what reactivating costs and how long it takes. Then put the payment route in the obvious place rather than behind a "contact us" link.
What to avoid is the tone of an error. A trial ending is not a fault, and styling it like a failure state makes the user feel they did something wrong. It is a normal transition and should look like one, which is a different job from the messages covered in designing error messages.
How Long Should You Keep Their Data?
Long enough to be useful, short enough to be defensible, and stated in advance. This is a legal question as well as a product one.
The GDPR's storage limitation principle in Article 5(1)(e) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." An expired trial account held indefinitely, for no articulated purpose, is difficult to justify against that.
So pick a period and say it. Our usual recommendation is ninety days of full retention in read-only state, then deletion, with a warning email before it happens. Ninety days covers the realistic budget cycle. Indefinite retention creates a liability and a growing database of people who are never coming back.
The important part is that the user knows the number. A deadline they can see is fair. A deletion they did not expect is a complaint, whatever your policy says.
Must You Let Them Export Everything?
Yes, and it should work on the last day rather than requiring an upgrade. This is not generosity, it is a legal right for personal data.
GDPR Article 20 gives a data subject the right to receive their personal data "in a structured, commonly used and machine-readable format" and to transmit it to another controller "without hindrance from the controller to which the personal data have been provided." Article 20(2) goes further, giving them the right "to have the personal data transmitted directly from one controller to another, where technically feasible."
Gating export behind payment is therefore a bad idea on two counts. It may not be lawful for the personal data involved, and it is precisely the behaviour that makes an evaluator warn their network about you.
Build the export properly instead. A real CSV or JSON file with the actual fields, not a PDF summary. Our notes on import and export UX cover what makes an export genuinely usable.
Is the Countdown Before the End Worth It?
A little of it, placed carefully. Persistent countdown banners from day two are noise, and people stop seeing them long before they matter.
What works is fewer, better moments. One notice a few days out, in the product and by email. One on the final day. Both naming what will change rather than just the number of days remaining.
The detail that makes these useful is specificity about their own account. "Your 14 dashboards and 3 integrations will become read-only on Thursday" is a different message from "your trial expires soon." The first one describes something they would miss.
What About the Person Who Never Started?
Treat them differently, because a trial that was never used is not a lost sale, it is a failed onboarding. Sending them a payment prompt is pointless.
The useful response is a single message asking what got in the way, with a genuine offer of help and a way to restart later. Some of those replies are the most valuable product feedback you will get, because these are the people who normally leave without a word.
It also protects your data. Empty accounts should be cleared faster than active ones, since there is even less justification for holding them.
Where Does Deceptive Design Creep In?
At exactly this transition, which is why it deserves a deliberate check. The pressure to convert makes the end of a trial the most tempting place in the product to be slightly dishonest.
Regulators have taken an interest in interface design of this kind. The European Data Protection Board published Guidelines 03/2022, "on deceptive design patterns in social media platform interfaces: how to recognise and avoid them," adopting version 2.0 on 24 February 2023. Its scope is social media platforms rather than SaaS trials, but it is the clearest official articulation of the idea that an interface can lead someone into a choice they did not want.
The patterns to keep out of your trial ending are familiar ones. A cancel path buried several clicks deeper than the upgrade path. A pre-ticked annual plan. A countdown that resets. Wording that implies data will be deleted immediately when it will not. Each of those converts slightly better in the short term and costs you the recommendation.
What Would We Build, in Order?
Read-only mode first, because it is the decision everything else follows from. Then a clear, honest expiry screen with the payment route on it. Then a working export. Then the two-message warning sequence. Then a stated retention period with an automated warning before deletion.
That is a week or two of work for most products, and it replaces the thing that usually exists, which is a hard paywall added in a hurry and never revisited.
The test we would apply at the end is simple. Imagine a user who genuinely liked the product but has no budget until next quarter. Does your trial ending make it easy for them to come back and buy, or does it make them start again somewhere else? Every decision above follows from answering that honestly. If you want a second pair of eyes on your own trial ending, we are happy to look at it with you at phoenix.studio.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.