Trial-to-paid mechanics worth building first

Trial-to-paid mechanics worth building first

A client's project management SaaS launched with a 14-day trial and a 6% conversion rate. They asked us to add in-trial email sequences, a usage dashboard, a countdown widget, and an exit-intent discount modal. We shipped two of those, declined the other two, and the conversion rate moved to 11% within two billing cycles.

The mechanics worth building first are the ones that let you learn what is preventing conversion. The premature ones are the ones that assume you already know.

Build the usage tracker

You need to know what trial users actually do. Not page views — those tell you someone logged in. You need feature-level events: workspace created, first document uploaded, second collaborator invited, export triggered. Store these against the trial account, not the individual user, so you can see team-level adoption patterns.

// POST /api/events
async function logFeatureEvent(tenantId, event) {
  await db.query(
    `INSERT INTO usage_events (tenant_id, event_name, occurred_at)
     VALUES ($1, $2, NOW())`,
    [tenantId, event]
  );
}

This is a flat table with no joins at write time. You can query it later to find the correlation between reaching a certain feature depth and conversion. That correlation is what drives every other decision about the trial.

In the client's data, accounts that invited a second team member within 48 hours converted at 38%. Accounts that did not invited anyone converted at 2%. That single fact changed what we built next.

Build the billing handoff

The trial-to-paid transition is a billing problem, not a marketing problem. Get the Stripe customer record, subscription, and plan-tier logic working before anything else. This includes the proration logic when someone upgrades mid-cycle, the grace period for failed payments, and the webhook handling that suspends access cleanly.

A common mistake is building the trial wall as a separate check from the billing state. It is not separate. The trial is a subscription with a `trial_end` date. When that date passes without a payment method, the subscription moves to `incomplete` or `canceled`, and your authorization middleware checks that status. One source of truth.

function hasActiveAccess(subscription) {
  const now = Math.floor(Date.now() / 1000);
  if (subscription.status === 'trialing' && subscription.trial_end > now) {
    return true;
  }
  return ['active', 'past_due'].includes(subscription.status);
}

The `past_due` inclusion is a choice. Stripe treats it as active for a configurable grace period. We prefer to mirror that so a failed renewal does not immediately lock a paying customer out.

Defer the nudges

In-trial email sequences are where most teams overbuild. Three emails — welcome on day 1, a usage prompt on day 4, a trial-ending notice on day 11 — are enough. Eight emails with conditional branches based on feature usage is premature until you have enough trials running to make the branching meaningful.

The exit-intent discount modal is the clearest example of premature. It addresses a specific objection — price sensitivity at the moment of leaving — but you do not know if price is the objection. If your trial users are not reaching the point where the product's value becomes clear, a discount does not fix that. You need the usage data first.

What to build instead of the premature things

After the usage tracker shows you the gap, build toward it. The client's gap was collaborator invitation. We added a prompt on the dashboard after the first document was created: a single button to invite a teammate, with the email prefilled from the invitee's domain if the account was a work email. That was it. No multi-step onboarding flow, no progress bar, no checklist.

The billing mechanics and the usage tracker are infrastructure. Everything else is a hypothesis. Build the infrastructure first, run the hypothesis against data, and ship the specific thing the data points to.