DEV Community: Sophie F A

We Killed Our Yearly Plan. The Lifetime License Converted 2.4x Better.

Sophie F A — Mon, 17 Aug 2026 08:38:15 +0000

TL;DR

We A/B tested a yearly subscription against a one-time lifetime license on three React Native templates for a full quarter.
Lifetime converted at 2.4x the yearly plan, cut the 7-day refund rate from 6.8% to 3.1%, and dropped support tickets per 100 sales from 41 to 17.
Repeat purchase went up under lifetime (~2% to ~11%). Every advisor we asked predicted the opposite.
Root cause is product shape, not pricing fashion. Our marginal cost per buyer after delivery is ~0, so recurring billing had no cost curve to match.
The actual code change was two lines in the Stripe session and one column in Postgres. The comms rewrite took a week.

The setup

We sell downloadable React Native templates. Full Expo + Supabase codebases you clone, rebrand, and ship. There is no server we keep alive for you, no per-seat metering, no proxy in front of your OpenAI key.

We still launched with a yearly plan, because that is what every pricing-page template on the internet says to do.

Two variants, three products (a $49, a $79, and an $89 control), traffic split ~50/50 by product page visit, swapped weekly to kill weekday effects:

Variant A: yearly subscription at roughly one-third the lifetime price. Source access revoked on cancel.
Variant B: one payment, lifetime updates, keep the code forever.

Identical code, identical Supabase migrations, identical Expo config. The only difference was what happened to your access when you stopped paying.

The numbers

Metric	Yearly	Lifetime	Delta
Product-page to paid conversion	1.0x	2.4x	+140%
Refund rate (7-day window)	6.8%	3.1%	-54%
Support tickets per 100 sales	41	17	-59%
Cart abandonment at pricing	68%	44%	-24 pts
Repeat customer rate (60 days)	~2%	~11%	+9 pts

Three things stood out.

Repeat purchase went up. The "if they own it they'll never come back" prediction was just wrong. A happy lifetime buyer came back for a second template. A subscription buyer treated the whole category as expensive rented software and never returned.

Refunds halved. A big share of "refund me" tickets were not dissatisfaction. They were anxiety about the next bill. Remove the next bill, remove the reason to hedge.

Support load collapsed. Subscription tickets were dominated by four questions that literally cannot exist under lifetime: how do I cancel, will you charge me if I don't ship, what happens to my code if I stop paying, can I export before renewal.

Why it broke: the economics didn't line up

The subscription playbook assumes the vendor keeps paying an ongoing cost to keep your use of the product alive. Check what we actually pay for after checkout:

// Our per-buyer ongoing cost, honestly enumerated
const ongoingCostPerBuyer = {
  hosting:        0, // you deploy it
  database:       0, // you connect your own Supabase project
  llmInference:   0, // you drop in your own API key
  appleDeveloper: 0, // your account, your $99/yr
  bandwidth:      0, // one tarball at purchase time
};

// => sum is 0. There is no recurring cost to fund with recurring revenue.

You connect your own Supabase instance with the migrations we ship. You drop your own key into Expo's env config:

# .env.local: your keys, your quota, your bill
EXPO_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
EXPO_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
OPENAI_API_KEY=sk-your-own-key

When the buyer's cost is recurring and the vendor's cost is not, buyers hedge. They cancel early, they refund, and they open tickets about the next bill instead of the current build.

The actual code change

This is the part people assume is hard. It isn't. The Stripe side is a mode swap:

// Before: subscription
const session = await stripe.checkout.sessions.create({
  mode: 'subscription',
  line_items: [{ price: 'price_yearly_fitness', quantity: 1 }],
  subscription_data: {
    metadata: { template: 'fitness-app', revoke_on_cancel: 'true' },
  },
  success_url: `${SITE}/download?session_id={CHECKOUT_SESSION_ID}`,
});

// After: one-time payment
const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [{ price: 'price_lifetime_fitness', quantity: 1 }],
  payment_intent_data: {
    metadata: { template: 'fitness-app', license_type: 'single' },
  },
  success_url: `${SITE}/download?session_id={CHECKOUT_SESSION_ID}`,
});

Read the Stripe billing modes doc before you pick one. payment versus subscription is not a small config toggle, it reshapes the entire buyer relationship.

The schema side is one column:

-- supabase/migrations/20260114_product_licenses.sql
create type license_type as enum ('single', 'multiple', 'team', 'enterprise');
-- note: no 'monthly_recurring'. it does not exist anymore.

alter table public.product_licenses
  add column license_type license_type not null default 'single',
  add column purchased_at timestamptz not null default now();

-- entitlement check, post-switch
create or replace function public.has_template_access(
  p_user_id uuid,
  p_template text
) returns boolean language sql stable as $$
  select exists (
    select 1 from public.product_licenses
    where user_id = p_user_id
      and template_slug = p_template
  );
  -- no expiry comparison. that clause is what we deleted.
$$;

That deleted and expires_at > now() clause is the whole post in one line of SQL.

What buyers actually asked for

Tagged every sales conversation, support ticket, and abandoned-cart survey for the quarter. Three themes dominated:

"Can I just buy it?" By far the most frequent. Developers wanted a purchase order, not a payment relationship.
"What happens to the code if I cancel?" Our subscription answer was "access revoked." Correct, and hostile-sounding to anyone shipping a real product.
"I need this for a client project, can I keep the fork after it ships?" Agency and freelancer use, a much bigger slice than we expected. A yearly plan does not serve "I need this for six weeks, then I'm done."

The rule I'd give you

Not "lifetime always wins." Match pricing to product shape:

Product shape	Pricing	Why
Hosted SaaS with per-user server cost	Subscription	Recurring cost matches recurring value
API-metered service	Usage-based	Cost scales with call volume
Downloadable tool / plugin / template	Lifetime	Marginal cost after delivery is zero
Continuously-curated feed or library	Hybrid	Ongoing editorial work justifies ongoing revenue
Hardware + optional cloud	Perpetual + optional sub	Two cost curves, two prices

The honest test: does my cost of serving this customer continue after they sign up? If yes, subscription. If no, you are selling a lifetime asset dressed up as a rental.

We would go back to subscription tomorrow for a hosted managed backend, a continuously-curated prompt library, an agency retainer, or an enterprise plan with a real SLA. For static, self-hosted, source-available code, subscription is a category error.

Where it landed

Every template in the Applighter catalog is now a one-time purchase between $49 and $99, including full TypeScript source, Supabase migrations, Expo config, and every future update to that template. Agencies get a multiple license upgrade instead of a seat subscription. Refund window is 7 days, no questions asked.

The FAQ line that took a week to write:

One payment, all future updates to that template, including Expo upgrades, new screens, and security patches. No subscription, no seat tax.

Every word in it was argued over. "All future updates" kills rug-pull fear. "Expo upgrades" makes the promise specific. "No seat tax" preempts the next question every dev asks.

Your turn

If you sell something downloadable and you're still on a yearly plan, I'd genuinely like to know what your refund rate looks like. And if you switched and it went badly, that's the more useful comment. Drop it below.

The 4 AI Patterns That Actually Ship in Mobile

Sophie F A — Mon, 17 Aug 2026 08:37:32 +0000

Most AI features in mobile apps die before ship. The ones that make it reduce to four patterns. Here they are with real numbers.

The three constraints that kill 80% of AI features

Before the patterns, the filter. An AI feature ships in a mobile app if and only if it clears these:

P95 latency under 2s (or streamed with TTFT < 500ms)
Cost per active user under $0.10/mo (unless paid tier is live day one)
A degradation story — offline, wrong answer, model down

Every pattern below clears all three. Every pattern that doesn't is why your last AI feature never left staging.

Pattern 1 — Transcribe → Structure

Shape: voice in → structured artifact out (summary, action items, journal entry).

// 1. capture audio (expo-av / expo-audio)
// 2. stream to Whisper / Deepgram / AssemblyAI
// 3. LLM call with a JSON schema
// 4. render + persist

Numbers:

Stage	P50	P95	Cost / 5-min recording
Upload	400ms	1.2s	free
Whisper transcription	3s	7s	$0.03
gpt-4o-mini structuring	800ms	2.1s	$0.002

The UX trick: stream the transcript in during upload. The user never waits on the wall clock. Perceived latency stays under 1s because the UI is animating continuously.

Reference implementation: the AI Voice Notes template on Applighter ships this end-to-end — 16+ screens, waveform visualizer, pluggable transcription backend.

Pattern 2 — Chat over your data (RAG)

Shape: documents + question → grounded answer.

// ingest (once per doc)
const chunks = chunkPdf(file, { size: 800, overlap: 100 });
const embeddings = await openai.embeddings.create({
  model: 'text-embedding-3-small',
  input: chunks.map(c => c.text),
});
await supabase.from('doc_chunks').insert(
  chunks.map((c, i) => ({ ...c, embedding: embeddings.data[i].embedding }))
);

// query (every message)
const q = await embed(userQuestion);
const { data: matches } = await supabase.rpc('match_chunks', {
  query_embedding: q,
  match_count: 6,
});
const answer = await streamChat({
  messages: [
    { role: 'system', content: `Answer using only:\n${format(matches)}` },
    { role: 'user', content: userQuestion },
  ],
});

Cost profile — 1,000 users × 20 msg/day:

Embeddings: ~$4/mo
LLM (gpt-4o-mini): ~$18/mo
pgvector on Supabase free tier: $0
Total: ~$22/mo → $0.022/user

Charge $4.99. Print money.

Supabase's pgvector is the low-ops choice — same Postgres you already use for auth. Pinecone/Weaviate/Chroma only make sense above ~100k docs.

Reference: Supabase vector columns docs.

Pattern 3 — Streaming generation

Shape: prompt → streamed text/JSON.

The transport is the whole game. Same model, same prompt, but token-by-token output shows meaningful content in <300ms. Non-streamed on cellular feels broken; streamed feels instant.

React Native gotcha: default fetch doesn't reliably stream on Android. Use expo/fetch:

import { fetch } from 'expo/fetch';

const res = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ messages }),
});
const reader = res.body!.getReader();
const decoder = new TextDecoder();
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  setStreamedText(prev => prev + parseSSE(decoder.decode(value)));
}

Three things that break in prod:

Backgrounding. iOS suspends the stream. Buffer server-side, reconnect on resume.
FlatList reflow. Appending chars re-measures rows every keystroke. Memoize, or use a fixed-height container.
Interruption. Users tap to type mid-stream. Need cancel-and-restart, not a modal.

Pattern 4 — Multimodal vision extraction

Shape: photo → structured JSON.

const image = await ImagePicker.launchCameraAsync({ base64: true });
const res = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    { role: 'system', content: 'Extract data as JSON matching this schema...' },
    { role: 'user', content: [
      { type: 'text', text: 'Extract line items' },
      { type: 'image_url', image_url: { url: `data:image/jpeg;base64,${image.base64}` } },
    ]},
  ],
  response_format: { type: 'json_schema', json_schema: RECEIPT_SCHEMA },
});

Gotchas:

Resize first. iPhone photos are 3–5MB base64. Resize to 1024×1024 max, save 80% of tokens, no accuracy loss.
The model will guess. Always show the extraction with editable fields before saving.
P50 is ~3s. Show a skeleton, don't block the camera UI.

Side by side

Pattern	Model	P50 latency	Cost/event	Ships in
Transcribe → structure	Whisper + gpt-4o-mini	4s	$0.03	1 weekend
RAG	gpt-4o-mini + pgvector	1.5s streamed	$0.001/msg	3–5 days
Streaming generation	gpt-4o-mini	300ms TTFT	$0.0005/reply	2 days
Vision extraction	gpt-4o	3s	$0.01	2–3 days

The pattern that never ships: agents

Autonomous agents fail silently and expensively. A stuck agent burns $2 of API before anyone notices. A hallucinating agent sends the wrong Slack. On desktop, fine — you're watching a terminal. On mobile — backgrounded, killed, lost network mid-run — it's a support ticket factory.

The four patterns above ship because they're bounded: user sees input, user sees output, loop closes in seconds.

Agents will get there. Not in 2026.

Picking your pattern

Users speak more than they type → Pattern 1
Users have their own data → Pattern 2
Users compose text → Pattern 3
Users capture from the physical world → Pattern 4

Ship one. Compose later. Never all four at once — that's the roadmap slide of a startup that no longer exists.

Canonical version with more code + template links

Cross-Platform Design Tokens — Getting Web + Mobile to Feel Like One Product

Sophie F A — Thu, 06 Aug 2026 09:13:40 +0000

Most full-stack SaaS templates ship a Next.js web app and a React Native mobile app in the same repo. Fewer share design tokens between them. And that's the difference between an app that feels like one product on two surfaces and an app that feels like two companies wearing the same t-shirt.

The visual drift problem

Open a random full-stack SaaS template. Compare the primary button color on the web dashboard to the primary button color on the mobile app. Are they exactly the same? Same shade, same weight, same radius, same padding? In most templates, no — they're close but not identical, because the web team picked one hex and the mobile team picked another, and there's no shared source of truth.

That drift compounds. Six months later, the web app has ten shades of blue, the mobile app has eight, and neither team can tell you which is the "brand" blue.

What shared tokens actually mean

Shared design tokens for a full-stack SaaS means one JSON (or TypeScript) file that defines every visual value the app uses, and both the web app and the mobile app import from it.

tokens/
colors.ts // brand, surface, text, border, semantic (success/warning/error)
typography.ts // heading scale, body scale, mono
spacing.ts // 4px base unit, exposed as space.1, space.2, space.4, space.8
radius.ts // sm, md, lg, full
shadow.ts // sm, md, lg

The web app consumes them via Tailwind config or a CSS-in-JS theme. The mobile app consumes them via a theme provider that resolves platform-appropriate values. Same source, different runtimes.

Where web and mobile should diverge

Sharing tokens does not mean web and mobile should look identical. There are good reasons to diverge:

Typography: iOS has SF Pro, Android has Roboto (or Noto), the web can have anything. Shared tokens define the scale (heading.xl = 32px); platform code picks the family.
Touch targets: mobile needs a 44pt minimum tap target, web can be smaller. Shared spacing tokens, different application.
Elevation: mobile uses subtle shadows or none (Material) plus platform blur effects; web can use heavier shadows because there's more visual noise to compete with.
Corner radius: iOS trends smaller (8-12px), Android trends larger (16-24px), web is a taste call.

A well-designed shared tokens system exposes the primitives (color, spacing, scale) and lets the platform layer pick the composition. Templates that force pixel-identical layouts across web and mobile end up making both surfaces feel wrong.

Auditing a template's design layer

Search the codebase for hex codes. If there are more than ~20 outside the tokens file, the template has drifted.
Look at the tokens file. Is it semantic (text.subtle) or raw (gray800)? Semantic wins for theming.
Check dark mode. Is it token-based (each token has a light + dark value, resolved at the provider) or if (isDark) scattered through screens? The former scales, the latter doesn't.
Check for a component gallery (Storybook, or a /design route). Templates that shipped one thought about design as a system, not screens.
Check for component variant definitions in the theme, not the component. Button.variants.primary in theme > with hardcoded styles.

The handoff pattern that scales

[7:02 AM]The design handoff pattern that works long-term for full-stack SaaS templates:

Designer works in Figma with a token library that mirrors the code tokens.
When tokens change (a new brand color, an updated radius scale), the designer edits Figma and files a PR against the tokens file with the same names.
Engineering merges the PR, tokens flow to both web and mobile instantly, no screen touched.
Component names in Figma match component names in code — PrimaryButton in both places.

Templates that ship this pattern from day one save the design team weeks of translation work per project. Templates that don't force every design change to become an engineering task.

Applighter's approach

At Applighter, the cross-platform tokens layer is treated as first-class — one tokens file consumed by both the Next.js web app and the Expo mobile app, semantic naming throughout, platform-appropriate composition at the render layer, Figma library that mirrors code component names. Not because we're perfect on this — because we watched too many full-stack templates ship with a drift problem baked in.

Whatever template you evaluate, ask this one question: is there a single tokens file that both surfaces import? If yes, the design work will scale. If no, budget the retrofit.

React Native i18n in 2026: A Practical Expo Router Playbook

Sophie F A — Mon, 03 Aug 2026 07:35:54 +0000

If your React Native app only speaks English, you're leaving ~75% of smartphone users on the table. Here's the modern stack for shipping a multilingual Expo app without three days of glue code.

The Stack

react-i18next: translation management (6M+ weekly downloads, TS-first)
expo-localization: device locale detection (or react-native-localize for bare RN)
Intl: dates, numbers, currencies (built into Hermes)
I18nManager: RTL layout flipping

Setup in 4 Steps

1. Install

npx expo install expo-localization
npm i i18next react-i18next

2. Translation files

locales/
  en.json
  es.json
  ar.json

{
  "welcome": "Welcome",
  "cart": {
    "itemCount_one": "{{count}} item",
    "itemCount_other": "{{count}} items"
  }
}

Use the ICU plural suffixes (_one, _other, _few, _many, _zero). Arabic has 6 plural forms, so get this right on day one.

3. Bootstrap

// i18n.ts
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import * as Localization from 'expo-localization';
import en from './locales/en.json';
import es from './locales/es.json';
import ar from './locales/ar.json';

const deviceLocale = Localization.getLocales()[0]?.languageCode ?? 'en';

i18n.use(initReactI18next).init({
  compatibilityJSON: 'v4',
  resources: {
    en: { translation: en },
    es: { translation: es },
    ar: { translation: ar },
  },
  lng: deviceLocale,
  fallbackLng: 'en',
  interpolation: { escapeValue: false },
});

export default i18n;

Two production-important bits: compatibilityJSON: 'v4' for modern plural rules, and escapeValue: false because RN already escapes JSX.

4. Wire into Expo Router

// app/_layout.tsx
import { Stack } from 'expo-router';
import './i18n';

export default function RootLayout() {
  return <Stack />;
}

Then in any component:

import { useTranslation } from 'react-i18next';

const { t } = useTranslation();
<Text>{t('cart.itemCount', { count: 3 })}</Text>
// "3 items"

The Gotchas Nobody Warns You About

Never concatenate around t(). Word order changes across languages:

// ❌ Breaks in Japanese, German, Arabic
<Text>{t('hello')} {user.name}!</Text>

// ✅ Whole sentence is one key
<Text>{t('greeting', { name: user.name })}</Text>

RTL doesn't flip everything. Flexbox auto-flips, but you'll need to fix:

left/right → use start/end
Directional icons → wrap in transform: [{ scaleX: -1 }] when I18nManager.isRTL
Hardcoded textAlign

Hardcoded strings in third-party UI kits. Buttons in libraries like RN Elements ship English defaults. Override or pick i18n-aware libs.

Push notifications aren't localized by the phone: your backend has to send the localized copy or use OS-level notification categories.

Formatting

Never string-concat dates or currencies. Use Intl:

new Intl.DateTimeFormat(i18n.language, { dateStyle: 'medium' }).format(new Date());
new Intl.NumberFormat(i18n.language, { style: 'currency', currency: 'USD' }).format(29.99);

Add @formatjs/intl-datetimeformat polyfills if you need older Android or less common locales.

Testing Discipline

Turn on saveMissing in dev. react-i18next logs every missing key. Fail CI on any.
Pseudo-localize with en-XA. This surfaces hardcoded strings and 30–40% longer text for layout stress-tests.
Snapshot per locale. French/German/Arabic snapshots catch layout regressions.

Shortcut

If you're starting fresh, RapidNative generates the whole i18n scaffold (provider, layout wiring, translation files, RTL flags) from a natural-language prompt. You get the same setup you'd write by hand, in about 30 seconds.

Otherwise: ship it. It's 2–3 days of setup and it opens up 3 billion more users.

How to Build a Video Calling App with React Native and WebRTC

Sophie F A — Wed, 15 Jul 2026 07:22:22 +0000

The WebRTC pipeline is where the interesting engineering lives. The UI around it — call setup screen, contact list, in-call controls, history log — is boilerplate you've built a hundred times. That's exactly the layer that RapidNative handles well: describe the screens you need, get production-ready React Native + Expo code you can drop straight into your Metro bundle.

For a video calling app, that's the pre-call lobby ("Start Call" / "Join Call" / recent contacts), the in-call overlay (avatar, timer, mute/video/end buttons, participant list for group calls), and the post-call summary. You can start from a PRD or sketch the flow and get a working Expo project in minutes, then wire in the react-native-webrtc layer described above.

The pattern generalizes: use AI to move fast on UI-heavy layers where you're implementing patterns everyone recognizes, and spend your engineering time on the parts that are genuinely hard — like the ICE candidate gathering that just failed on your test call. If you're building anything real-time, our writeups on how RapidNative delivers real-time React Native previews and how we built real-time collaboration for team app building cover the WebSocket patterns that pair nicely with WebRTC signaling.

Frequently Asked Questions

Does react-native-webrtc work with Expo Go?

No. react-native-webrtc ships native iOS and Android modules that Expo Go cannot load. You need to move to Expo Dev Client or the bare workflow and use EAS Build (or a local expo run:ios/expo run:android) to include the native code. The @config-plugins/react-native-webrtc plugin handles the required permissions automatically.

How much does a WebRTC video calling app cost to run?

For 1-to-1 calls, near zero — media flows peer-to-peer. Your only costs are the signaling server (a $5/month VPS handles thousands of concurrent calls) and TURN relay for the roughly 15–20% of calls that fall back to relayed mode. Budget $0.40 per GB of TURN traffic. Group calls with an SFU move more media through your servers and cost proportionally more.

Can I use WebRTC for one-to-many streaming?

WebRTC is optimized for two-way conversation. For one-to-many broadcast (like a webinar or Twitch-style stream), you can use an SFU, but at scale you'll pay more than a protocol like HLS or LL-HLS designed for that pattern. WebRTC shines when latency matters more than viewer count.

What's the difference between STUN and TURN?

STUN helps a peer discover its own public IP address so two peers behind NAT can attempt a direct connection. TURN is a fallback: when direct P2P fails (usually because both peers are behind symmetric NAT), TURN acts as a media relay. STUN is cheap and free servers exist; TURN uses your bandwidth and typically costs money.

Is WebRTC secure?

Yes. All WebRTC media is encrypted with DTLS-SRTP by default — it's not optional in the spec. You cannot send unencrypted media. The signaling channel is your responsibility; use WSS (secure WebSockets) or HTTPS for whatever you build.

Wrapping Up

You now have every piece needed for a production-quality react native video calling app: a signaling server, a peer connection lifecycle, media capture, offer/answer exchange, ICE handling, and the standard call controls. Add a TURN server, wire the UI to your app's state management, and you're 80% of the way to shipping.

The hardest part of WebRTC isn't the API — it's the network. Test on real cellular connections, log ICE state transitions, and instrument connection failures early. Everything else is UI polish, and that's the part AI is happiest to write for you.

Ready to build? Start with RapidNative to spin up the app shell around your WebRTC layer in minutes, or browse more React Native tutorials on the blog.