DEV Community: Sophie F A

Every EAS Submit Failure Mode I've Hit in Six Months (and What Catches Each Pre-Submit)

Sophie F A — Wed, 16 Sep 2026 13:44:02 +0000

TL;DR

eas submit exiting 0 does not mean your app is on track for review. It means the binary reached the store's front door
Six failures I've hit in six months: wrong ascAppId, IAPs not attached to the version, vanished TestFlight tester groups, incomplete Play Data Safety, versionCode collisions, and screenshot resolution rejections
Each one shares a shape: green CLI, red store, and roughly a day lost to the review calendar
Every single one is catchable before you submit. Checklist at the bottom

eas submit is genuinely good software. That is the problem. The CLI succeeds so cleanly that it trains you to believe the release is done, when all it has actually verified is that a binary was delivered. Everything that gets apps rejected lives on the other side of that handoff, in App Store Connect and Play Console state that the CLI never sees.

Here is every way that has bitten me since March, and the pre-submit check that now catches each one.

Failure 1: Wrong ascAppId, right exit code

Two apps under one Apple team. The submit profile in eas.json carried the ascAppId of the wrong one:

{
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

The CLI went green, because the ID was valid. The build just landed under the wrong app in App Store Connect, and I spent a morning wondering why the right app showed no new build.

Pre-submit catch: print the target before you fire. A two-line script that echoes ascAppId and the app's bundle identifier side by side, and refuses to continue if they don't come from the same app record, ends this class of mistake permanently.

Failure 2: IAPs not attached to the version

The binary was fine. The in-app purchase products existed. But new IAPs have to be attached to the app version and submitted with it for their first review. Ship the binary without them and Apple rejects the release, because the app references products the reviewer cannot see.

Pre-submit catch: if this release introduces or changes any IAP, open the version page in App Store Connect and confirm the products are listed under it before submitting. This is a thirty-second look that saves a full review round trip.

Failure 3: The vanished TestFlight external group

After a fresh submit, external testers stopped getting builds. The external tester group was still there, but the new build wasn't distributed to it: external distribution needs the build assigned to the group, and the first build of a new version needs beta review again. Nothing failed. Testers just quietly received nothing.

Pre-submit catch: treat "build uploaded" and "build distributed" as separate checklist items. After every submit, verify the new build shows against the external group, not just in the builds list.

Failure 4: Play Console Data Safety, the silent blocker

On Android my release sat in "Ready to send for review" while I assumed it was in review. The Data Safety section had a newly required disclosure I hadn't filled, and Play Console will hold a release on incomplete store listing sections without anything resembling an error in your terminal.

Pre-submit catch: open the release dashboard and look for any yellow banners before and after submitting. If your app adds an SDK, assume the Data Safety answers changed.

Failure 5: versionCode collision

eas submit delivered the AAB, Play rejected it: versionCode already used. A local build from weeks earlier had burned the number.

Pre-submit catch: stop managing it by hand.

{
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

Remote version management makes EAS the single source of truth for versionCode and iOS build numbers, and this failure mode disappears.

Failure 6: Screenshot resolution mismatch

Metadata, not binary. App Store Connect enforces exact pixel dimensions per display size class, and a set exported at the wrong scale gets the whole release bounced. The required sizes also shift as new devices ship, so a screenshot set that passed last year can fail this year untouched.

Pre-submit catch: script it. A tiny check that reads each PNG's dimensions and compares against the currently required sizes takes ten minutes to write and never lets a stale set through.

The pattern

All six failures share one shape: the CLI reported success, the store said no, and the cost was paid in calendar days, not compute. Review queues turn a five-minute config mistake into a one-day delay, and two mistakes into a lost week.

The fix is boring: a pre-submit checklist that verifies store-side state, not just build-side state. Ours is now the first file in every release branch.

If you'd rather not own that checklist at all, this is exactly the job we built RapidNative Deploy for: it runs these store-side checks and handles the submission path so a green pipeline actually means a shipping app.

Which one of these has cost you a review cycle? And what's the failure mode I haven't hit yet? Drop it in the comments.

Where AI-Generated Full-Stack Code Silently Rots (and How Templates Cap the Damage)

Sophie F A — Wed, 16 Sep 2026 13:12:42 +0000

TL;DR

AI-generated full-stack code does not fail on merge. It fails months later, at the seams between subsystems
Three recurring rot sites: missing auth boundary tests, decorative RLS policies, and Stripe webhooks that only handle checkout completion
The AI writes tests for the code it wrote, never for the gap it introduced
Templates cap the damage because their value is debugged code, not written code
Safe workflow: template for the seams, AI for the surface area, human-picked failure modes for every new route

Six months of shipping Next.js + Supabase + Stripe apps under a mixed workflow (some human-written, some AI-scaffolded from Claude and Cursor) has surfaced a repeatable pattern. The AI-generated code doesn't fail on merge. It fails in month three. And it fails in a specific place: the seams between subsystems that the AI never wrote a test for, because it never generated the test that would have caught its own gap.

This post is a field report on where the rot happens, and why starting from a template collapses most of the failure surface.

The three places AI-generated code rots

Auth boundary tests are always missing. Every Next.js + Supabase project I've reviewed that was generated top-to-bottom by an AI had tests. They were also generated by the AI. Every test verified that a signed-in user could read their own data. Zero tests verified that an anonymous user got a 401. Zero tests verified that user A couldn't read user B's data by manipulating the URL. The AI wrote the tests it thought about, which was the tests for the code it wrote.

RLS policies are decorative. Related to the above. AI will generate a create table users_data migration and skip enable row level security. If your dev environment uses the Supabase local stack, RLS is off by default on your custom tables. The auth policy is documentation, not enforcement, and the missing test never catches it.

Stripe webhooks fire on the wrong event, then no-op silently. The pattern the AI reaches for is if (event.type === 'checkout.session.completed'). That covers the most common flows and misses subscription upgrades, downgrades, cancellations, and dunning. The webhook is wired, the code is present, the user's subscription state drifts silently over weeks.

Why templates cap the damage

A template is not obsolete because AI can generate code. A template is a codebase that has already been debugged by a human against real production traffic. The value isn't the 200 lines the AI could regenerate in a minute. The value is the hours of debugging those 200 lines that someone already paid.

Concretely, the Applighter Next.js + Stripe + Supabase starter ships with:

All migrations enable RLS by default. Skip it explicitly if you don't want it; the default catches you if you forget.
A Stripe webhook handler that dispatches on the full event set (customer.subscription.updated, .deleted, invoice.payment_failed, etc.), not just checkout completion.
A test suite that verifies auth boundaries (anon requests, cross-user access attempts, expired sessions) before any happy-path tests.

You can still let AI generate the app on top. The template ensures the seams already have the tests the AI won't write for you.

How to use AI on top of a template safely

The workflow that has worked for us:

Start from a template that has the seams solved.
Let AI generate feature code: new routes, new components, new business logic.
Do not let AI generate tests for the seams. It cannot see the failure mode it just introduced.
Human-write a smoke test per new route: anon access, wrong-user access, malformed input. The AI can help you write the assertions, but you should be picking the failure modes.

The rule of thumb: AI generates the code it thought of. Humans think of the code the AI didn't.

Concluding thought

Most of the "AI-generated codebase failure" postmortems I read describe the same shape: everything worked, tests passed, then a specific class of user request revealed data leaking through a policy that was written but not enforced. This is not a Claude problem or a Cursor problem. It is a workflow problem. And the workflow fix is trivially available: start from a codebase where the seams are already solid, and use the AI to fill in the surface area on top.

Applighter's templates exist for this reason.

Where has AI-generated code rotted on you? Drop the failure mode in the comments.

Google Play's 12-Tester Rule: The Playbook Solo Indie Devs Need Before They Hit It

Sophie F A — Wed, 09 Sep 2026 13:25:05 +0000

You built the app. You bought the developer account. You upload the build, hunt for the publish button, and instead find a wall: run a closed test with 12 testers for 14 days before you can even apply to publish.

Most solo devs discover this rule at the worst possible moment, launch week. This is the playbook for hitting it on purpose instead.

TL;DR

Personal Play Console accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. Per app.
The 14 days are the most recent 14 days. Drop below 12 testers and your window breaks.
Only the closed testing track counts. Internal testing does not.
Passing the count is not passing the test: Google also looks at whether testers actually used the app, and you answer a questionnaire when you apply.
Recruit 18 to 20, not 12. Attrition is the rule, not the exception.
Budget three weeks minimum from "build ready" to "live on the store."

What the rule actually is (and what it isn't)

The rule, from Google's own testing requirements: before applying for production access, a personal developer account created after November 13, 2023 must run a closed test with a minimum of 12 testers who have been opted in continuously for the last 14 days.

Unpack the load-bearing words:

Personal account, created after Nov 13, 2023. Organization accounts are exempt, and so are older personal accounts. If your account predates the cutoff, you can stop reading and go publish.
Opted in. A tester counts when they click your opt-in link and join the test through the Play Store with their Google account. Twelve email addresses in your tester list that never clicked count as zero.
Continuously, last 14 days. Measured backwards from now. Not "14 days total, eventually."
Closed testing. Internal testing (up to 100 testers, no review) is great for your own devices but contributes nothing to this requirement.
Per app. Passing once does not unlock the account forever. Each new app runs its own closed test.

What the rule is not: a guarantee. Hitting 12x14 makes you eligible to apply for production access. When you apply, you answer questions about your testing process, what feedback you got, and what you changed. Google has also been checking that testers genuinely engaged with the app, not just opted in and vanished. Twelve ghosts can pass the counter and still sink the application.

One more historical footnote worth knowing: the requirement launched at 20 testers and was later reduced to 12. Any tutorial telling you "20 testers" is just old, not describing a different rule.

Why Google added it

The Play Store had a spam problem: low-effort apps churned out from throwaway accounts, published in bulk, abandoned. A two-week test with a dozen real humans is a speed bump that costs a spammer more than it costs you. It also front-loads a thing you should be doing anyway: watching real people use your app before strangers do.

Understanding the intent matters tactically. Google is not counting heads for fun; it is looking for evidence of a real testing process. Everything below is built around producing that evidence honestly.

The 14-day counter: resets, gotchas, real elapsed time

This is where launches die, so be precise about the mechanics:

The meaningful clock runs while you have 12 or more opted-in testers. Practically, treat it as starting when tester #12 opts in, not when you create the track.
Because the requirement reads "the last 14 days continuously," a dip below 12 on day 10 does not pause your progress, it breaks it. You are back to rebuilding a clean 14-day window.
Testers can opt out silently. A tester who uninstalls the app but stays opted in still counts toward the opt-in number, but contributes nothing to the engagement picture. Both numbers matter.
Real elapsed time is longer than 14 days. Add: Google's review of the closed-test release itself before testers can join (often a few days for a first release from a new account), recruiting time, and the production access review after you apply. This is why the honest runway is three weeks, not two.

Write these two dates down the moment tester #12 opts in: the opt-in date, and opt-in date + 14. Everything between them is a "do not drop below 12" zone.

Where to actually find 12 real testers

In rough order of quality:

People who want the app to exist. If you built a climbing log, post in a climbing community. These testers open the app because they care, which is exactly the engagement signal you need.
Friends, family, colleagues. Reliable opt-ins, mediocre engagement. Give each one a specific job ("use it to track one real thing this week") or they will install and forget.
Dev communities and mutual-testing groups. Indie devs testing each other's apps (Discord servers, subreddits, forums). It works, with two caveats: reciprocity costs you time testing other apps, and a track full of developers who open the app once is thin engagement evidence.
Paid testing services. They exist in volume. If you go this route, understand what you are buying: opted-in accounts, not necessarily the genuine-usage story Google increasingly wants to see. Treat it as a top-up, not a strategy.

The move that consistently works for solo devs: recruit from 1 and 2 first, then backfill from 3. And recruit before the build is ready, so testers are waiting on you instead of the reverse.

The opt-in URL: sharing it without looking desperate

The mechanics: create the closed track, upload the build, add an email list (or Google Group, which is far easier to manage), and share the opt-in link Google generates. Testers open it, join, and install from the Play Store.

The pitch matters more than the link. What flops: "please help me, Google makes me do this." What works is a one-liner that gives people a reason and a bounded ask:

I'm launching <app> for <audience> and it's in a 2-week
pre-release test. If you'd use something like this, you can
get it early here: <link>. One ask: open it a couple of
times a week and tell me the first thing that annoys you.

That framing does three jobs at once: it filters for people who might actually use the app, it sets the engagement expectation, and it primes the feedback you will need for the production access questionnaire.

Use a Google Group for the tester list. Adding and removing individual emails in the Console gets old by tester #6.

Attrition planning: over-recruit, track, react

Plan for a third of your testers to flake. Not because people are bad, but because "install a stranger's app and keep it for two weeks" is a genuinely annoying favor.

The system:

Recruit 18 to 20 for a 12 floor. Every one above 12 is insurance against a broken window.
Track opt-ins daily. The Console shows your tester count. Thirty seconds each morning, that's the whole habit.
Have 2 to 3 warm spares. People who said yes but whom you have not sent the link. If the count reads 13 and trending down, deploy a spare the same day, because a new opt-in today protects a window that a new opt-in on the day you drop below 12 cannot.
Nudge once, mid-window. A single day-7 message ("halfway, anything broken? anything missing?") revives idle testers and generates the feedback trail you want. More than one nudge and you are spam.

What if you fail the test

Two distinct failure modes, two remediations:

The counter broke. You dropped below 12 mid-window. Nothing is lost except time: keep the track, backfill testers, and let a fresh 14-day window accumulate. This is annoying, not fatal.

Production access was denied. You hit the numbers, applied, and Google said no. This almost always means the testing story was weak: no evidence of real usage, questionnaire answers that read like nobody actually tested anything, or an app with obvious unfinished parts. The fix is a genuinely better test cycle: engaged testers, a change you shipped in response to feedback, and questionnaire answers that name both. Then reapply.

Then there is the third option: deciding your time is worth more than fighting the process. This gate is one of several reasons a done-for-you route exists; a service like LetsDeployIt handles store submission end to end, which for a lot of solo devs (especially the wave shipping AI-built apps who never planned to learn Play Console at all) is the difference between launching and stalling at the paperwork.

The 3-week release runway

The rule quietly converts "publish to Google Play" from an afternoon into a project phase. Plan it like one:

Week 0 (before the build is final)
  - Recruit 18-20 testers, park them in a Google Group
  - Create the closed track early; first releases can sit
    in review for days

Week 1-2 (the window)
  - Day 0: 12+ opted in, write down the target date
  - Daily: 30-second tester count check
  - Day 7: single nudge + collect feedback
  - Ship at least one visible fix from that feedback

Week 3
  - Apply for production access; answer the questionnaire
    with specifics (feedback received, changes made)
  - Production review + staged rollout

The devs who resent this rule fight it during launch week and lose a month. The devs who absorb it into the plan run the test while they polish the store listing and lose nothing.

Solo devs who've been through it: how long did your window actually take, and where did you find your 12? Drop it in the comments, the tester-sourcing answers genuinely help the next person who lands here from the Play Console wall.

Claude Code on a React Native Codebase: Guardrails That Actually Change the Output

Sophie F A — Wed, 09 Sep 2026 13:19:12 +0000

Every React Native developer has run the same experiment by now: point an AI agent at the codebase, ask for a feature, watch it produce something that compiles, and then quietly rewrite half of it before merging. The demo works. The diff does not.

The gap is not model quality. It is that an agent with no constraints makes the statistically average choice at every fork, and the statistically average React Native choice is frequently wrong for your app: wrong navigation pattern, wrong state library, a fresh useState where you have a store, an inline style where you have a design system.

Guardrails close that gap. Here are the ones that measurably changed what Claude Code hands me on RN projects.

TL;DR

A short CLAUDE.md beats a long one. Two paragraphs on stack and conventions do most of the work.
Fence off ios/, android/, and native config with permission rules AND an instruction. Belt and suspenders.
One screen or one hook per task. If you cannot describe the diff in a sentence, split it.
Make the agent run typecheck, lint, and tests itself before showing you anything.
Agents are great at gluing and modifying. For standard app skeletons, a template is still faster.

The gap between "writes RN code" and "writes RN code you'd merge"

Unguided agent output on an RN codebase fails in predictable ways:

It invents a second way to do something you already do one way (a new fetch wrapper next to your API client).
It reaches for dependencies you do not have, or worse, installs them.
It edits generated or native files that should never be touched by hand.
It styles components from scratch instead of using your primitives.

None of these are intelligence failures. They are context failures, and context is exactly the thing you control.

CLAUDE.md: the two paragraphs that change the defaults

Claude Code reads a CLAUDE.md file from your project root at the start of every session and treats it as standing instructions. Most people either skip it or write a 300-line novel the model has to dig through. The high-leverage version is short and opinionated:

# CLAUDE.md

This is an Expo (managed workflow) app. TypeScript strict mode.
Navigation: expo-router, file-based. State: zustand stores in src/stores/.
Data fetching goes through src/api/client.ts only. Never call fetch directly.
UI: use the components in src/components/ui/. Do not write inline styles;
use the theme tokens in src/theme/.

Never modify anything in ios/, android/, or app.json without asking first.
Before finishing any task, run: npx tsc --noEmit && npm run lint && npm test.
If any of those fail, fix them before presenting the diff.

That is the whole file. Every line kills one category of "compiles but wrong" output. The first paragraph replaces the model's generic defaults with your actual stack. The second paragraph sets the boundaries and the exit criteria.

The test for whether a line belongs in CLAUDE.md: have you corrected the agent for this twice? Then it goes in. Otherwise it is noise.

Guardrail: keep the agent out of native land

On RN specifically, the highest-damage failure mode is the agent "helpfully" editing native projects: a Podfile tweak here, a gradle change there, an Info.plist permission it decided you needed. These changes are invisible in a JS-focused review and surface as build failures days later.

I fence this at two layers.

Layer 1: permission rules. Claude Code supports allow/deny permission rules in .claude/settings.json at the project root, so the constraint ships with the repo:

{
  "permissions": {
    "deny": [
      "Edit(ios/**)",
      "Edit(android/**)",
      "Write(ios/**)",
      "Write(android/**)",
      "Bash(pod:*)",
      "Bash(npx expo prebuild:*)"
    ]
  }
}

Layer 2: the instruction. The "never modify ios/, android/, or app.json without asking" line in CLAUDE.md. This is not redundant. Permission rules are enforcement; the instruction changes planning. Without it, the agent plans a native change, hits the wall, and flails. With it, the agent routes around native work from the start or stops and asks, which is what you actually want.

If you are on Expo managed workflow, you get this guardrail almost for free: keep the agent in JS, keep config in app.json under human control, and let EAS handle the native layer.

Task shape: small, verifiable, one screen at a time

The size of the task changes the quality of the output more than any prompt wording. My working rule: if you cannot describe the expected diff in one sentence, the task is too big.

Bad: "Add a profile feature."

Good, as a sequence:

1. Add a ProfileScreen at app/profile.tsx using the ui/ components.
   Static layout only, hardcoded data. No navigation changes yet.
2. Add a useProfile hook in src/hooks/ that loads the profile
   via src/api/client.ts. Include a loading and error state.
3. Wire useProfile into ProfileScreen. Handle loading/error with
   our existing <Spinner /> and <ErrorView />.
4. Add the profile tab to the router layout.

Each step is one screen, one hook, or one wiring job. Each is verifiable on its own: you can open the diff, look at one file, and say yes or no in under a minute. The agent also self-corrects better at this size because failures are local.

The compounding benefit: step 2's output is written against step 1's real code, not against an imagined version of it.

The testing loop: what the agent runs before you see a diff

An agent that hands you untested code has done half a task. The loop I make explicit (in CLAUDE.md and in the task prompt for anything nontrivial):

npx tsc --noEmit   # strict TS catches most RN agent mistakes
npm run lint       # convention drift, unused imports, hook rules
npm test           # whatever exists; even thin coverage catches regressions

Strict TypeScript is doing the heaviest lifting here. A big share of agent errors in RN are shape errors: wrong prop types, wrong navigation params, a store selector returning the wrong slice. tsc --noEmit converts those from runtime surprises into a loop the agent resolves on its own before you ever look.

What the agent cannot do is see the screen. So my manual review step for UI work is deliberately narrow: run it, look at the screen on one device size, tap through the flow once. Logic correctness has already been machine-checked; I am only reviewing what machines cannot check.

When the agent is faster than a template, and when it isn't

Honest accounting, because "AI writes the whole app" is the claim and it is only half true.

The agent wins when the work is specific to your app: modifying existing screens, wiring a new flow into established patterns, refactors, integrating that one weird SDK, writing tests against your actual code. This is where templates cannot help you by definition.

The agent loses on standard app infrastructure. Auth flows, onboarding, navigation shells, Supabase wiring, settings screens: an agent will generate these from scratch in an hour and you will spend another two reviewing boilerplate that thousands of apps share. That is what starter templates are for; a catalog like AppLighter exists precisely so the React Native + Expo + Supabase skeleton is a solved problem you download instead of a week of agent diffs you review.

The pattern that actually compounds: template for the skeleton, agent for everything that makes the app yours. The template also quietly improves the agent, because now every task starts from consistent, conventional code, which is exactly the context agents extrapolate from best.

The pattern that beats "just ship what it wrote"

Putting it together, the loop that has consistently produced mergeable RN diffs for me:

1. CLAUDE.md: stack, conventions, boundaries, exit criteria (short)
2. Permission rules: native dirs and dangerous commands fenced
3. Tasks sized to one-sentence diffs, sequenced
4. Agent runs tsc + lint + tests before presenting
5. Human review narrowed to: screen looks right, flow feels right

None of this is sophisticated. That is the point. The teams getting real throughput from agents on RN codebases are not writing clever prompts; they are removing the degrees of freedom where the agent's average choice diverges from their codebase, and letting it sprint inside the fence.

What is in your CLAUDE.md? I am collecting RN-specific guardrails, so drop yours in the comments, especially the rule you added after an agent burned you.

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.