Day 15 Matters Most: A Trial Expiry and Downgrade Guide for Vibe Projects

First, a note: every person, product name, and number in this guide is fictional, invented to explain the method. Nothing here is a real product or a real user case. The method is general; the numbers are illustrative scales, not measured results from any product.

The most embarrassing day for a vibe project is often the morning a trial ends. Not because the product is bad, but because the maker only planned how people start a trial, never how a trial ends. A user opens the app to find yesterday's features greyed out, no clear word on whether their data still exists, and no idea whether upgrading will restore anything. That experience damages trust more than never offering a trial at all. My view: the design of a trial is really decided on day 15, not in the first 14 days. Handle that morning gracefully and users will come back to pay; handle it brutally and they will leave without even exporting their data.

Decide three things before writing any code

Settle three questions on paper first. One, what does the trial measure: 14 days of time, or 100 records of usage? Time trials suit collaboration and reporting tools that need days to show value; usage trials suit tools whose value is obvious in one session. Never mix the two into "14 days or 100 records, whichever comes first" — users cannot do that maths, and neither can your support inbox. Two, do you require a card upfront? Card-upfront converts better but brings disputes and refunds; no-card converts a little worse but keeps your reputation clean. For a solo maker with no support team, I recommend no card: every "I forgot to cancel" complaint costs your own time. Three, what survives a downgrade? This is the most important decision in the whole guide, and it must be made before the trial starts, not improvised on expiry day.

Take the fictional example of Gu Xiao's "Mist Island Lists", a team task tool with a 14-day, no-card trial. From day one, the product says in plain sight: "After the trial, your tasks and files stay viewable and exportable for 30 days; you just cannot create premium projects." The value of that sentence is not copywriting, it is a promise: it turns downgrading from a punishment into a rule agreed in advance. Users dare to put real data in during the trial, because the worst case is a downgrade, not data held hostage. Products that only say "free for 14 days" and bury the expiry rules in a help doc will be assumed to lock everything — so users only test with fake data, and trial conversion stays low.

The expiry timeline: five touches, none skippable

Expiry is not a moment, it is a process that needs announcements. My recommended timeline: on day one, state the expiry date and what survives a downgrade; on day seven, say how many days remain and which premium features have been used; three days before expiry, repeat the reminder and offer a one-click export; one day before, remind one last time, stressing that "your data stays, it just becomes read-only"; on expiry day, show a calm banner at the top of the page, not a modal blocking the whole screen. Each message should carry exactly one thing: how long is left, what happens next, and what the user can do now. Stuffing an upgrade discount, a feature list, and a support link into one reminder means nobody reads any of it.

Two details are most often missed by vibe makers. First, timezones and the meaning of "that day": is expiry 23:59 on day 14 after signup, in whose timezone? Compute it server-side from a single timestamp, display it in the user's local time, and write the exact deadline in reminders — "before 23:59 Beijing time on 16 November", never just "tomorrow". Second, idempotency: if the expiry job runs twice, it must not flip the user's state twice or send two "your trial has ended" emails. Check state before changing it, change it, then send notifications, in that order. Reversing the order produces the classic ghost bug of an expiry email arriving before expiry.

The downgrade matrix: draw the table before writing permission checks

The worst downgrade failure is locking features one by one as you remember them, ending with contradictions. Before coding, draw a downgrade matrix: rows are features, columns are trial, free, and paid tiers, and every cell holds exactly one of three values — available, read-only, or unavailable. For example: viewing tasks is available in all three tiers; creating premium projects is available in trial and paid, unavailable in free; exporting data is available in all three tiers — yes, export must never be locked, that is the floor; inviting members is paid-only; automation rules are available in trial and paid, read-only in free (visible but not editable). Once the table exists, every server-side permission check consults it. Scattered if-statements across pages will inevitably produce "clickable in the list, error on the detail page" half-locked states.

Three edge cases deserve their own rules. First, collaborative data: user A downgrades, but the team project they joined is paid for by someone else. Rule: permissions follow the resource's owner, not the individual's tier — team projects follow the team's subscription, only personal projects follow the person. Second, public and shared links: links already sent out should stay readable after downgrade and stop being writable; cutting them dead hurts the person on the other end, a second audience you cannot afford to offend. Third, over-limit data: the user created 50 projects in trial but the free tier allows 5. Do not auto-delete, do not lock at random. Keep everything read-only and let the user choose which 5 become editable again — returning the choice to the user halves the complaints instantly.

Copywriting: say "kept", not "locked"; say "restore", not "buy"

Downgrade copy decides whether users feel pushed out or kept. The bad version: "Your trial has ended. Upgrade now or features will be restricted." That is all threat, no information. The good version: "Your trial has ended. Your 128 tasks and 36 files are still here, viewable and exportable for 30 days. Upgrading restores premium projects and automations immediately, with no reconfiguration." Notice what it contains: data present, deadline clear, exit open, restoration costless. The upgrade button should not say "Buy now" either; "Restore premium features" fits better, because users are not buying something new, they are getting back something they already know how to use.

Equally, do not run a fake countdown "limited-time offer" on downgrade day. A solo project playing hunger marketing only signals desperation. If you want to offer a discount, offer a calm "welcome-back price" with a plain start and end date, reverting automatically afterwards, no popups. Trust is worth more than one conversion, especially for a vibe project still building its reputation.

Expiry and failed payment are two different flows

Many makers merge "trial ended" and "payment failed" into one flow. That is a serious mistake. Trial expiry is expected; the user did nothing wrong, so the flow should be calm, with an exit and a deadline. Payment failure is an accident — the card may simply have expired — so the flow should be remind, retry, and grace, not instant downgrade. After a failed payment, give a 3 to 7 day grace period with features unchanged, only reminding the user to update payment details; downgrade only after grace ends, using the same matrix but different copy. "Payment failed" is not "trial ended"; a mismatched email confuses everyone. Draw both flows as two diagrams before coding, so you never accidentally reuse the wrong branch.

Re-upgrading must be one click, not a rebuild

Even the kindest downgrade is wasted if upgrading forces users to reconfigure everything. At the moment of upgrade, the system should do three things: restore permissions from the matrix; automatically make editable the projects the user chose to keep during downgrade; and unlock read-only data exactly as it was, losing nothing and reordering nothing. Test the full loop — trial, downgrade, 10 read-only days, upgrade — and check that automations, member permissions, and shared links all come back. One more trap: if users exported during downgrade and re-import after upgrading, will duplicates appear? Deduplicate on a stable identifier at import, or warn clearly that duplicates will be skipped — never silently copy everything twice.

Personal and team trials need separate downgrade rules

A personal trial downgrade affects one person; a team trial downgrade affects a group and the permissions between them, so it needs its own table. The core rule: data follows the workspace, not the person. When a team workspace downgrades, all its members become read-only together; if one member upgrades individually, only their personal workspace is restored, not the team workspace — restoring the team workspace requires the admin to upgrade the team plan. It sounds convoluted, but it leaves no ambiguity and saves support explanations. External collaborators invited during the trial should keep read-only access for the same 30-day retention window, with a reminder to the admin before removal, so the decision to remove someone stays a human decision, never an automatic one.

After the retention period: deletion should be graceful too

When the 30-day retention period ends, say so in advance and act on schedule. Remind users 3 days before it ends that export is still available; on the day itself, mark data as pending deletion and add a 7-day cooling-off period during which upgrading still restores it; only then delete for real, with an auditable log of what was deleted, when, and what triggered it. Do not delete early to save storage, and do not keep data forever "just in case" — that is both storage cost and privacy liability. Keep downgrade, end-of-retention, and account deletion as three separate explanations: downgrading without upgrading removes over-limit and trial-temporary data, while the account and basic data stay, so users can always return on the free tier.

Pre-launch checklist

Here is a checklist you can test against directly. Expiry is computed from a server-side timestamp and displayed in local time; at least three expiry reminders go out, each covering deadline, consequence, and exit; the downgrade matrix covers every feature with no scattered page-level checks; export is never locked in any tier; over-limit data stays read-only and the user picks what to restore; shared links stay readable but not writable after downgrade; collaborative projects follow the resource owner's subscription; failed payments have their own grace flow; upgrading restores everything in one click with no lost configuration; the expiry job is idempotent and never double-sends; downgrade copy contains no threats and no countdown pressure. Pass all ten and the trial is truly finished. Remember: the goal of a trial's end is not "did the user pay", but "if the user leaves, would they come back". Get the morning of day 15 right, and the previous 14 days will not have been wasted.