We rewrote the Applighter pricing page three times in eleven months. Here is what each version was, why it failed (or worked), and the structure we kept.

For context: we sell production-ready React Native templates. Each one is a full Expo app with a Supabase backend, NativeWind styling, AI integration where relevant, and a Stripe-powered license grant on purchase. Pricing is one-time, $79 per template, no subscription. That detail matters because two of our three rewrites pretended otherwise.

Version 1: the SaaS-tier menu

The first page was the one every founder builds in week one.

| Starter $79  | Pro $79      | Team $79     |
|--------------|--------------|--------------|
| ✓ Source     | ✓ Source     | ✓ Source     |
| ✓ Backend    | ✓ Backend    | ✓ Backend    |
|              | ✓ Most       |              |
|              |   Popular    |              |

Three columns. "Most Popular" badge. Monthly/annual toggle (we don't sell monthly anything). It looked professional. It looked familiar.

Conversion was bad. Support email volume was worse. The questions were:

• "Is the $79 per template or for the whole library?"
• "Do I have to pay every month?"
• "If I pay $79, do I get the source code or just access to a dashboard?"

The page was telling buyers a SaaS story. The product was a zip of TypeScript and a Supabase project. Mismatch.

Lesson: Don't borrow the pricing UX of a different business model.

Version 2: the comparison wall

When buyers are confused, every founder's reflex is give them more information. We built a 32-row feature matrix comparing Applighter to "DIY," "UI templates," and "marketplace bundles."

const featureMatrix = [
  { feature: "TypeScript",          applighter: true,  diy: "depends", ui: true,    bundle: true  },
  { feature: "Supabase backend",    applighter: true,  diy: false,     ui: false,   bundle: false },
  { feature: "Auth",                applighter: true,  diy: "build it", ui: false,  bundle: "mock" },
  { feature: "Commercial license",  applighter: true,  diy: "n/a",      ui: "ext",  bundle: "ext" },
  // ... 28 more rows
];

Session recordings: median scroll-past in under three seconds.

The table was answering questions nobody was asking. The questions buyers actually had — can I use this commercially, what happens after I pay, what if it doesn't work for my project — were buried in a footer FAQ link nobody clicked.

Worse, the comparison framed the product as defensive. Buyers don't pay $79 to validate your competitive position.

Lesson: Read your support inbox before you read CRO articles.

Version 3: one product, three license sizes

The current page is shorter than either previous version. Top to bottom:

1. Hero with the product, not the price. Screenshot of the template running on an iPhone. The price exists, but it isn't the headline.
2. License picker, not a tier ladder. Single / Multiple / Enterprise — described by who is buying, not by features unlocked. Every license includes the same source code.
3. What's included, plainly. Six bullets. No checkmarks. No comparisons.
4. Refund policy next to the buy button. Seven-day, no-questions. The single biggest move on V3.
5. FAQ above the fold of the second screen. Pulled directly from real support tickets, in the buyer's own words.
6. One soft secondary path: browse other templates.

The implementation:

// app/buy/page.tsx (sketch)
export default async function BuyPage() {
  const tiers = await getLicenseTiers();
  return (
    <>
      <Hero product={product} />
      <LicensePicker tiers={tiers} />
      <RefundLine policy="7-day money-back" />
      <BuyButton />
      <Faq source={faqJson} />
      <RelatedTemplates />
    </>
  );
}

License tiers are stored in Postgres and read at request time, so we can adjust per-template without a deploy. The FAQ is read from data/faq.json and used on both the homepage and the buy page so the messaging stays consistent.

What conversion actually moved

• V1 → V2 made things worse. More info to a confused buyer = more confusion.
• V2 → V3 was the largest jump. Refund line + license picker carried most of it.
• Refund rate dropped after V3, not V2. Refunds correlate with surprise.
• Support ticket volume on pricing questions fell roughly in half.

We did not run A/B tests. Traffic on a $79 product wasn't high enough for significance in a useful timeframe. We talked to buyers, watched email, and changed the page.

Five lessons that survived

1. Match the pricing UX to the business model. A one-time digital product is not a SaaS.
2. The buyer's questions are not your competitor's questions. Read the inbox.
3. The refund policy is part of the offer. Surface it.
4. Less ships faster than more. Every rewrite removed something.
5. Ship a page, don't ship an A/B test. At our volume, ten buyer conversations beat a multivariate framework.

What we would do differently

Skip V1 and V2. Start at V3. The shape of the right page was sitting in the support inbox the whole time.

If you want to see the structure in production, the Applighter template catalog is built on the V3 pattern — same hero-then-license-picker-then-refund-line shape on every product page.

For the React Native + Supabase + Expo stack underneath, the relevant docs are Expo, Supabase, and Stripe Checkout.

If you've rewritten your own pricing page and learned something the slow way — especially if you sell a one-time digital product — drop a comment with what moved the needle for you. Curious whether the "refund line next to CTA" pattern holds for other indie devs or whether it's specific to our buyer.