Turn free users into paying customers

The most useful fact for free-to-paid conversion is the action your paying customers took that most free users never did. Kite finds that action in your own data rather than in a list of best practices.

First, Kite matches your signups to their Stripe customer records, usually by email address. It reads each customer's subscriptions to see whether they're trialing, active, or canceled, which plan they chose, and how long they took to pay. That turns a signup count into a real free-to-paid rate, broken down by month and by plan.

Next, Kite compares what paying customers did in their first days with what free users did. Say you run an invoicing app for freelancers, and the free plan allows three invoices a month. Kite might find that nearly every paying customer sent an invoice to a second client within their first week, while most free users who never paid only ever invoiced one. That second client is your upgrade moment. It's the point where the free plan starts to feel small to the people most likely to pay.

Kite brings you the action it found and the numbers behind it, so you can agree on it before any copy changes.

Once Kite knows the action that leads to payment, it looks for the step where free users stop short of it. A free user who never reaches the moment where your product proves itself rarely sees a reason to pay, so this step often matters more than the upgrade prompt itself.

Kite builds a funnel from the events your product already records, running from signup to the action that predicts payment and on to checkout. It reads how many people complete each step and splits the drop by plan, device, or the campaign that brought them in. For the invoicing app, the funnel might run from signup, to the first invoice sent, to a second client added, to a paid plan. If most users send one invoice and never add a second client, Kite looks at what the app shows them after that first invoice.

When the funnel doesn't explain the drop on its own, Kite reads the paths people took instead and, in PostHog, the session recordings of users who stopped at that step. Sometimes the answer is a product problem, such as an error on the "add client" screen, and Kite says so. If getting new users to that first useful moment is the bigger problem, Kite's guide to getting new users to value faster covers that work.

A paywall turns readers into subscribers when it stops them right after they've seen what the paid version is worth and tells them exactly what they get by paying. A paywall that cuts off before the reader has learned anything feels like a trap. A paywall that tells them nothing specific about the paid version feels like a toll.

Kite designs three parts of the paywall:

• Where the free part ends. Kite places the cutoff after the section that proves the piece is worth finishing, such as the first worked example or the first finding, rather than after a fixed number of words.
• The teaser at the cutoff. It names what the rest of this particular piece covers, so the reader knows what they're about to miss, and then what subscribers get every week.
• The offer. It states the price plainly, shows the annual price beside the monthly one, and leads to a checkout with as few steps as possible.

Say you publish a paid newsletter on pricing strategy for software companies. A generic paywall says "Subscribe to keep reading." A teaser written for that issue says "The rest of this issue breaks down the three pricing changes that doubled annual signups at a 40-person company, with the before-and-after pricing pages. Paid subscribers get a teardown like this every Tuesday."

For a software product, the paywall is usually a usage limit, such as the invoicing app's three invoices a month. The same rules apply. Kite writes the prompt that appears at the limit about the job the user was in the middle of, and it leaves them a plain way to keep working on the free plan. Kite covers in-product prompts in more detail in its guide to writing in-app onboarding and upgrade copy Coming soon .

On a site Kite hosts, it builds the teaser and subscribe sections into the page and can test them against your current version. It also adds the structured data that tells Google which sections are behind the paywall, so search engines don't mistake the hidden content for a page that shows them something different from what readers see. If your paywall runs in your own product or publishing platform, Kite hands your team the copy for each state, ready to put in place.

Offer an annual plan discount at the moments a customer has shown they intend to stay. The most reliable ones are at first checkout, where the annual price sits beside the monthly one, and after a customer has paid monthly for a few months. An annual offer made to someone who hasn't seen the product's value yet mostly gets ignored. The same offer made to a customer in their fourth paid month often gets accepted.

Kite works out your timing from your own Stripe data. It reads your subscriptions, plans, and billing periods to see how many customers chose annual at first checkout, how many switched later, and how many months of monthly payments came first. It also reads when monthly customers cancel. If most monthly cancellations happen in the first two months, an annual offer in month three reaches the customers most likely to stay and gives them a reason to commit.

Kite also helps you decide how big the discount should be and how to describe it. Many companies frame the discount as months free, such as "12 months for the price of 10," because it's easier to picture than a percentage. Kite reads your current prices in Stripe, checks how competitors in your market present their annual plans, and proposes the offer and the wording.

Then Kite builds the offer where it belongs. It can add the annual option to your pricing page on a site it hosts, set up the annual plan in Stripe as a payment link, and write the email that makes the offer to customers who have reached the right month. If you want to test the pricing page itself, Kite's guide to testing your pricing and pricing page covers that work.

Free trial users pay when they've reached the moment your product proves itself before the trial runs out. So the emails during a trial should get each user to that moment, and the email at the end should ask for payment in terms of what they've already done.

Kite builds the trial audience from your product data. With Supabase connected, it queries your tables for trial users and what each one has done. In PostHog, it builds a cohort, which is a saved group of users defined by what they did. In both cases, Kite separates the users who have reached the action that predicts payment from the ones who haven't.

Then it writes for each group. A trial user of the invoicing app who has invoiced two clients gets an email near the end of the trial that names what they've built and what keeps working when they pay. A trial user who has only sent one invoice gets an email earlier in the trial that shows them how to add their next client. Kite sends the emails from your Kite team address or a connected email product, or builds them as a PostHog workflow if that's where your team sends lifecycle email. You approve the audience and the emails before anything goes out.

A week or two later, Kite reads Stripe to see how many people in each group started paying. For a full sequence that starts at signup, see Kite's guide to setting up lifecycle email for new signups.

Kite tests one upgrade moment at a time and judges each test by whether more people paid. Changing the paywall, the trial emails, and the pricing page in the same week makes it impossible to tell which change worked.

On a site Kite hosts, it runs the change as an A/B test, which shows the current version to some visitors and the new version to others. Kite writes a hypothesis, such as "Because readers who reach the second section are three times as likely to subscribe, moving the paywall after that section will raise subscriptions from article pages." It builds the new version in its own draft, sets the goal and the traffic split, and asks for your approval before the test starts. While the test runs, Kite reads how many visitors saw each version, how many converted, and how likely each version is to win. It asks again before making the winner permanent.

For changes inside your product, Kite can set up the test as a PostHog or Mixpanel experiment, which your product shows through a feature flag. When a true split isn't possible, such as a change to a trial email everyone receives, Kite compares the same number of weeks before and after the change.

A version that wins on clicks can still lose on revenue. So after a test ends, Kite checks Stripe to see whether the people who converted went on to pay and whether they kept paying. Every result, whether it won, lost, or was inconclusive, goes into your team's knowledge base with the numbers behind it, so the next round starts from what already worked for you.