DEV Community: Jules Sarah

How we cut support tickets 70% with docs

Jules Sarah — Fri, 04 Sep 2026 13:15:43 +0000

We sell React Native + Expo app templates. Six months ago, ~25% of buyers opened a support ticket within their first week. Today it's ~7%. Same product, same buyers. Only the docs changed.

This is the tactical writeup: what we audited, what we changed, and the seven doc pages that eat most of our former support volume.

Audit 90 days of tickets. Tag each with root cause + which doc would have prevented it.
Two-thirds of our tickets were setup friction, not bugs.
Consolidate environment variable docs into ONE page with a complete table.
Ship a "first 15 minutes" quick start that skips every optional feature.
Put error strings verbatim in your docs so Google indexes them.
Make your support surface more prominent, but route through a dialog that suggests docs first.
Result: ~70% fewer tickets, better bug reports, more time for real work.

The audit

We store support requests in a Supabase table (support_requests) surfaced through a small admin dashboard. Pulled 90 days, ~312 tickets, tagged each:

category: env-misconfig | supabase-setup | eas-build | stripe | bug | customization
template: weather-app | fitness-app | ai-voice-notes | chat-with-pdf | ...
doc_that_would_have_helped: <path or "none">

Breakdown:

Category	% of tickets
`.env` misconfig	34%
Supabase project setup	22%
Expo / EAS build errors	15%
Genuine bugs	11%
Stripe / license activation	9%
"How do I customize X"	9%

66% of tickets were pre-first-run setup friction. Not novel bugs. Not missing features. The twenty-minute cliff between git clone and a working simulator build.

Change #1: Index error strings, not concepts

The single highest-ROI change. For every ticket that mentioned an error message, the literal string now appears verbatim in a doc page with the fix beneath it.

Bad:

### AsyncStorage resolution issues

If your bundler can't resolve async storage, ensure the dependency is installed.

Good:

### Error: `Unable to resolve module "@react-native-async-storage/async-storage"`

```bash
npx expo install @react-native-async-storage/async-storage
npx expo start --clear
```

This happens when the module was added transitively (usually via
`@supabase/supabase-js` session persistence) but not explicitly installed.

Devs paste error strings into Google. Google indexes the string. Google sends them to the fix. You never see the ticket.

Change #2: One `environment.mdx`, not seven scattered mentions

Old state: .env variables were mentioned in the Supabase page, the Stripe page, the push-notifications page, the OneSignal page, the EAS page. Each mention was correct in isolation. Collectively, nobody could find anything.

New state: one environment.mdx page. One table. Columns: variable name, source, client-or-server, what fails if missing.

| Variable                          | Source                | Scope   | If missing                                |
|-----------------------------------|-----------------------|---------|-------------------------------------------|
| EXPO_PUBLIC_SUPABASE_URL          | Supabase dashboard    | Client  | App loads, all queries return 401         |
| EXPO_PUBLIC_SUPABASE_ANON_KEY     | Supabase dashboard    | Client  | Auth silently fails                       |
| SUPABASE_SERVICE_ROLE_KEY         | Supabase dashboard    | Server  | Server routes return 500                  |
| STRIPE_SECRET_KEY                 | Stripe dashboard      | Server  | Purchase webhooks 500, no license grants  |
| ...                                                                                                     |

Boring. Effective. This one page killed a plurality of setup tickets alone.

Change #3: Six-command quick start

Old quick-start.mdx was maximalist: clone, install, env, Supabase, Stripe, EAS, push notifications, deep linking. New one:

git clone <your-license-url>
cd applighter-template
npm install
cp .env.example .env
# fill in EXPO_PUBLIC_SUPABASE_URL + ANON_KEY
npx expo start

Six commands. A running app on your simulator. Everything else is optional and lives on its own page.

Nobody wants to configure OneSignal in their first hour. Stop making them.

Change #4: Prominent support surface, routed through docs

Counter-intuitive result: making our support link more visible reduced tickets, not increased them.

The floating support button (a contact-author-fab component) opens a dialog. The dialog:

Asks for a one-line problem summary
Searches our docs for keyword matches
Surfaces top 3 doc results before offering the submit button
Only then lets you file a ticket

Roughly 40% of dialog opens never become tickets. People click a doc result, read it, close the dialog, and move on. Zero human interaction.

What didn't work

Videos. Three 8-minute setup walkthroughs. Two weeks of production. ~40 views/month combined. No measurable ticket delta. Devs skim; video prevents skimming.

Chatbot on our docs. Hallucinated flags, invented API surface, confidently misrepresented patterns we don't use. Customers pasted its answers back to us as bug reports. Killed after one week. The space is improving fast, but static docs that say the true thing still beat generative docs that say a plausible false thing.

The seven-page scaffold

If you're starting fresh (this is the structure every Applighter template's docs now follow):

quick-start.mdx: six commands, no optional features
installation.mdx: prerequisites, tool versions, common install errors verbatim
environment.mdx: one table, every variable, every failure mode
folder-structure.mdx: where things live, in one screen
supabase.mdx: project provisioning, RLS, storage buckets
expo-integration.mdx: EAS Build, provisioning, error strings verbatim
ui-components.mdx: customization points, how to not break updates

Everything beyond these seven pages is a nice-to-have.

Metrics worth tracking

Tickets per 100 active customers/week (target: <8)
% of tickets citing a doc page (target: >60%, which means people are reading first)
% of support-dialog opens that don't become tickets (target: >30%)
Median first-response resolution rate (target: >50%)

Metric to stop tracking: total weekly support hours. Goes to zero if you ignore your inbox. Useless.

References

Expo EAS docs: https://docs.expo.dev/build/introduction/
Supabase RLS docs: https://supabase.com/docs/guides/auth/row-level-security

Fewer tickets, better product, same 4,000 words of docs, just pointed at the right problems.

If you sell templates or dev tools: what's your top ticket category? Curious whether the two-thirds-setup-friction split holds outside our niche. Drop it in the comments.

The auth-screen UX playbook for Expo apps

Jules Sarah — Wed, 02 Sep 2026 10:58:13 +0000

Auth is the most scrutinised surface in a mobile app. People decide whether it looks legitimate almost immediately, and whether they're willing to sign up shortly after. Everything downstream is gated behind that.

Mobile OAuth in particular is where otherwise good apps leak users quietly, because the failure isn't an error. It's a browser tab the user has to close themselves.

The legitimacy scan

On first open, people scan for a small set of signals:

A logo that isn't pixelated
Provider buttons using the official brand assets, not lookalikes
Copy that doesn't read as machine-translated
No layout shift as the screen mounts

All four have to land. Any one being off loses users who will never tell you why.

Use the platform packages rather than rolling your own buttons. expo-apple-authentication renders Apple's official button, and @react-native-google-signin/google-signin gives you Google's. Both handle the brand requirements you'd otherwise have to read the guidelines for.

Keep the OAuth callback in-app

This is the difference between OAuth working and OAuth converting.

The naive flow opens a browser, the user signs in, the browser shows a success page, and then the user has to work out that they should return to the app themselves. Some don't.

const { data } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: {
    redirectTo: Linking.createURL('/'),
    skipBrowserRedirect: true,
  },
});

const result = await WebBrowser.openAuthSessionAsync(
  data.url,
  Linking.createURL('/'),
);

if (result.type === 'success') {
  // parse access_token and refresh_token from the returned URL fragment
  await supabase.auth.setSession({ access_token, refresh_token });
}

openAuthSessionAsync uses ASWebAuthenticationSession on iOS and Custom Tabs on Android. Both close themselves when they see the return scheme, so the user lands back in the app with a session already established and no visible handoff.

The token parsing is the fiddly part and the snippet leaves it as a comment deliberately: the tokens arrive in the URL fragment rather than the query string, so a naive URLSearchParams on the whole URL returns nothing and you'll spend twenty minutes wondering why.

Password reset is a funnel nobody revisits

It gets designed once and never looked at again, which means when it breaks, it breaks silently. Nobody files a bug about a password reset that didn't arrive. They just leave.

The flow that works:

Email input screen
resetPasswordForEmail(email, { redirectTo: 'myapp://reset' })
The emailed link deep-links into the app with a session already established
New password via updateUser({ password }), then a success screen with a sign-in action

The breakage to know about: the emailed link won't open the app unless the scheme is registered under Additional Redirect URLs in your Supabase auth settings. Add it once. This accounts for most "reset doesn't work" reports, and it produces no error anywhere in your code.

Error copy that doesn't alarm people

Never surface raw auth errors. AuthApiError: Invalid login credentials reads as something being broken. "Email or password doesn't match" reads as a typo.

Map every one:

const AUTH_ERRORS: Record<string, string> = {
  'Invalid login credentials': "Email or password doesn't match. Try again.",
  'User already registered': 'You already have an account. Try signing in.',
  'Password should be at least 6 characters': 'Password needs to be 6+ characters.',
};

Plus a network fallback, because "can't reach the server, check your connection" is a completely different message from "your details are wrong" and users act on them differently.

And put errors inline, under the field that failed. A red banner at the top of the screen is a web pattern that mobile inherited, and on a phone it means the user is looking at the wrong part of the screen to find out what went wrong.

The general shape

Every item here is the same class of problem: nothing throws, nothing appears in your error tracking, and the user simply doesn't complete. A browser tab left open. A reset email that goes nowhere. An error message that reads as a system failure rather than a typo.

Auth either works or it doesn't, technically. The gap between working and converting is entirely in these details.

The Applighter Expo templates ship auth wired this way, though everything above is a few hours of work in any project and worth doing before your first round of user testing.

What's the auth bug that took you longest to find? Mine was the redirect URL, and it took two days because nothing anywhere reported an error.

7 AI App Templates in 12 Months: What We Learned

Jules Sarah — Fri, 28 Aug 2026 11:30:28 +0000

Seven React Native templates in twelve months. Two AI-first, five conventional apps with AI stitched into the seams.

This is the concrete retrospective: the stack, the schema, the payment webhooks, the SDK bumps, the pricing. If you're building a template business or considering buying one, it's the post I wanted a year ago.

One AI job per template beats a chat tab bolted onto a generic app
The schema with correct RLS is the hard part; screens are replaceable
SDK upgrades are the largest recurring cost and we didn't price them in
Payments took four weeks, not four days
Cheap templates sold fewer copies, not more

The stack

After two false starts we locked it:

Runtime      : Expo SDK 54, new architecture
Language     : TypeScript, strict
UI           : NativeWind
Motion       : Reanimated + Gesture Handler
State        : Zustand + TanStack Query
Backend      : Supabase (Postgres, Auth, Storage, Edge Functions)
Payments     : Stripe, webhooks handled server-side
LLM          : Provider abstraction so the model is swappable
Tooling      : EAS build, update, submit

Each piece was picked for one property: it survives contact with a customer who doesn't know the library. NativeWind classes are searchable. Worklets don't stall when the JS thread does. Supabase migrations are versioned SQL you can read.

The registry pattern

Every template is a config file registered in one map:

// app/apps/config/index.ts
export const appConfigs: Record<string, ProductData> = {
  "weather-app":       weatherAppConfig,
  "fitness-app":       fitnessAppConfig,
  "e-learning-app":    eLearningAppConfig,
  "taxi-booking-app":  taxiBookingAppConfig,
  "ai-voice-notes":    aiVoiceNotesConfig,
  "chat-with-pdf":     chatWithPdfConfig,
};

Adding a template is one import and one map entry. A database-backed catalog was tempting for about a week and turned out to be unnecessary. Seven templates fit in a Record comfortably.

1. AI feature, not AI wrapper

Both of our best-selling AI templates do exactly one AI thing.

// AI Voice Notes: one job, audio to structured summary
async function summarize(audioUri: string) {
  const transcript = await transcribe(audioUri);
  return await extractStructure(transcript); // { summary, actions, decisions }
}

No chat bubble. No "ask this app anything" tab.

The templates where we bolted a chat tab onto a generic screen underperformed the ones where the AI was the feature. A chat tab is a way of not deciding what the AI is for, and buyers can tell.

2. RLS is the moat

Screens are easy to replace. A schema with correct row-level security takes weeks.

Every template ships migrations under supabase/migrations/, and every read and write is gated by a policy assuming auth.uid().

create policy "read own notes" on notes
  for select using (auth.uid() = user_id);

create policy "write own notes" on notes
  for insert with check (auth.uid() = user_id);

create policy "update own notes" on notes
  for update using (auth.uid() = user_id);

The bug we caught most in review was a missing sibling policy. Select correct, update absent. It fails silently, because the read works and the write just quietly does nothing to rows it shouldn't touch.

We test every template with two dummy accounts on a fresh Supabase project. Not optional. Reference: Supabase RLS docs.

3. SDK bumps eat weeks

Three SDK versions across the year. Each bump cost roughly a full engineering week per template:

New architecture opt-in
expo-audio replacing expo-av
Native modules re-verified on both platforms
Animation API drift

Seven templates, three bumps, a week each. That arithmetic is unpleasant and we didn't price it into the first three templates. We paid for it in December.

If you sell templates, maintenance is not overhead. It's the product.

4. Payments is a project

The webhook granting a customer access to what they bought is larger than any screen in any template.

type Grant = { userId: string; productId: string; source: "single" | "bundle" };

async function reconcile(event: Stripe.Event) {
  switch (event.type) {
    case "checkout.session.completed": /* create grant(s) */ break;
    case "charge.refunded":            /* revoke grant   */ break;
    case "customer.updated":           /* rekey email    */ break;
    // multi-line-item bundles, dedupe against prior grants,
    // same customer arriving with two different emails
  }
}

Plan four weeks. Not four days.

The cases that broke us were never the happy path. They were bundles containing a template the customer already owned, and refunds arriving after an email change.

5. NativeWind and Reanimated

A boring combination that kept winning:

import Animated, { FadeIn } from "react-native-reanimated";

export function Card({ title }: { title: string }) {
  return (
    <Animated.View entering={FadeIn} className="p-4 rounded-2xl bg-white dark:bg-slate-900 shadow">
      <Text className="text-lg font-semibold text-slate-900 dark:text-white">{title}</Text>
    </Animated.View>
  );
}

Searchable classes, worklets on the UI thread, and an unexpected third benefit: AI assistants get both libraries right on the first attempt.

That last one matters more than we expected, because most of our customers open the template in an AI editor rather than reading it top to bottom. A stack that models well is a stack that gets extended correctly.

6. Demo video beats README

Every template config carries a video. A short edited walkthrough moved conversion more than any pricing test we ran.

Not a screen recording. An edit.

7. Pricing

Single-app licence at $79, with a bundle at a materially better per-app rate. Two things surprised us.

Bundle attach rate is high. Customers who buy one template come back for the bundle rather than buying a second single.

And cheaper templates sold fewer copies, not more. Below a certain price, buyers appear to read the price as a signal about quality, and the ones who don't are not the customers you want anyway.

Scratch versus template

For a buyer starting a new app:

Task	From scratch	With a template
Auth (email, OAuth, Apple)	About a week	Included
Supabase schema and RLS	About a week	Included
Push notifications	Several days	Included, minus certificates
AI feature with streaming and storage	About a week	Included
Design tokens	A few days	Included
Icon, splash, EAS config	A couple of days	Included
Your own payments, if you sell something	About a week	Still yours

That last row is the honest one. A template gets you to a working app quickly. It does not remove the work of charging your own customers, and any comparison table that says otherwise is selling you something.

What we'd do differently

Pick the styling stack on day one
Write the schema before the screens
Record the demo video before launch, not after
One AI job per template, never a chatbot
Test on a clean machine before every release
Price maintenance from the start

Wrap

A year, seven templates, more webhook edge cases than anyone deserves.

The ones that survived contact with customers had real schemas, one focused AI job, and payments that didn't fall over on the first refund. Everything else was decoration, and we learned which was which by shipping the decoration first.

Full write-up with the internal architecture detail is on the Applighter blog.

If you sell templates or plugins, what did maintenance actually cost you in year one? I suspect most people underprice it the same way we did, and nobody publishes the number.

Rebuilding a Next.js MDX docs site without a framework

Jules Sarah — Fri, 21 Aug 2026 09:43:48 +0000

You don't need Nextra or Fumadocs for a small Next.js MDX docs site
next-mdx-remote/rsc + gray-matter + rehype-pretty-code + shiki covers ~95% of the surface
Our whole docs loader is 79 lines; the route is about 30
Zero client JS ships for the page body, since Shiki tokenizes at build time
Under ~50 pages this is faster to build and easier to change. Over ~100, use a framework.

The stack

{
  "next-mdx-remote": "^6.0.0",
  "gray-matter": "^4.0.3",
  "remark-gfm": "^4.0.1",
  "rehype-pretty-code": "^0.14.3",
  "shiki": "^4.0.2"
}

That's the whole runtime. Everything else is our own code: a docs loader, a dynamic route, and about 100 lines of custom MDX component overrides.

Directory layout

content/
  docs/
    index.mdx
    getting-started/
      installation.mdx
      environment.mdx
      quick-start.mdx
    core-concepts/
      expo-integration.mdx
      supabase.mdx
      ui-components.mdx

Each file starts with three-field frontmatter:

---
title: Introduction
description: One-line summary for meta description and sidebar.
order: 1
---

No schema validation. Forget order and the page goes to the end. Forget title and the sidebar shows the filename. This has bitten us zero times.

The loader

// lib/docs.ts
import fs from "node:fs";
import path from "node:path";
import matter from "gray-matter";

const DOCS_DIR = path.join(process.cwd(), "content/docs");

export function getAllDocs() {
  return walk(DOCS_DIR).map((filePath) => {
    const raw = fs.readFileSync(filePath, "utf8");
    const { data, content } = matter(raw);
    const slug = filePath
      .replace(DOCS_DIR + path.sep, "")
      .replace(/\.mdx$/, "")
      .split(path.sep);
    return { slug, frontmatter: data, content };
  });
}

The rest of lib/docs.ts is getDocsNavigation(), which walks once and returns an ordered tree, and getDocPrevNext(), which is twelve lines and a disproportionate UX win. Whole file is 79 lines.

The dynamic route

// app/docs/[[...slug]]/page.tsx
import { notFound } from "next/navigation";
import { MDXRemote } from "next-mdx-remote/rsc";
import remarkGfm from "remark-gfm";
import rehypePrettyCode from "rehype-pretty-code";
import { mdxComponents } from "@/components/docs/mdx-components";
import { getAllDocs } from "@/lib/docs";

export function generateStaticParams() {
  return getAllDocs().map((doc) => ({ slug: doc.slug }));
}

export default async function DocPage({ params }) {
  const { slug } = await params;
  const doc = getAllDocs().find(
    (d) => d.slug.join("/") === (slug ?? []).join("/"),
  );
  if (!doc) notFound();

  return (
    <MDXRemote
      source={doc.content}
      components={mdxComponents}
      options={{
        mdxOptions: {
          remarkPlugins: [remarkGfm],
          rehypePlugins: [[rehypePrettyCode, { theme: "github-dark-dimmed" }]],
        },
      }}
    />
  );
}

Zero client JS ships for the page body. Shiki tokenizes code at build time on the server. Prism this is not.

Why we skipped the frameworks

We evaluated Nextra, Fumadocs, and Contentlayer.

Framework	Cut because
Nextra	Good, but the opinionated theme fights our marketing shell
Fumadocs	Genuinely modern. Four packages to learn for eight docs pages.
Contentlayer	Effectively unmaintained. Extra build step for a marginal type-safety win.

If you have 100+ pages, use Fumadocs. If you have 8, write the 200 lines.

The MDX component override pattern

// components/docs/mdx-components.tsx
export const mdxComponents = {
  h1: (props) => <h1 className="text-3xl font-bold tracking-tight mt-0 mb-4" {...props} />,
  h2: (props) => <h2 className="text-2xl font-semibold mt-10 mb-3 scroll-mt-24" {...props} />,
  h3: (props) => <h3 className="text-xl font-semibold mt-8 mb-2 scroll-mt-24" {...props} />,
  p: (props) => <p className="my-4 leading-7 text-neutral-200" {...props} />,
  a: (props) => <a className="text-primary underline underline-offset-4" {...props} />,
  code: (props) => <code className="rounded bg-neutral-800 px-1.5 py-0.5 text-sm" {...props} />,
  // 23 overrides in total
};

scroll-mt-24 on headings is a small detail with an outsized payoff. Deep links to #section-name scroll to the heading with your sticky header out of the way, so tickets, Slack threads, and Discord messages linking to /docs/foo#bar land where the reader expects rather than one header-height too high.

Do this on day one. Retrofitting it means re-testing every anchor you've already shared.

What we still don't have

Search. Our previous search was window.find(). We removed it. Real full-text search is next quarter.
Versioned docs. Not needed yet.
OpenAPI reference generation. Not needed at all; our surface is React Native, not REST.
Live-editable code blocks. Good idea. Not shipping until we need it.

When this pattern breaks down

Around 50 pages you'll start wanting search. Around 100 you'll want versioned docs. At that point migrate to Fumadocs and enjoy the ride.

Until then the DIY pipeline is faster to build, easier to change, and has no lock-in.

References

Next.js MDX guide, the canonical pipeline recommendation
next-mdx-remote, which added RSC support in a recent major
rehype-pretty-code, a Shiki wrapper for rehype
Shiki, the TextMate-grammar tokenizer VS Code uses

What we'd do differently

Ship prev/next navigation on day one, not week two. Twelve lines, and it changes how people move through the docs.

Design the callout component before you write the first .mdx file. If you don't, you'll retrofit thirty pages by hand.

Add anchor IDs on h2 and h3 from the start. Load-bearing for every external link anyone ever shares.

The full comparison and the reasoning behind each package pick is on the Applighter blog.

What's your page-count threshold for reaching for a framework? Mine used to be about 20 and this project moved it considerably.

Two Junior Devs, One Expo Template, and 15 Hours Lost to Docs That Didn't Exist

Jules Sarah — Wed, 19 Aug 2026 07:01:47 +0000

I onboarded two junior devs onto a React Native app last week. Same Expo starter template, similar backgrounds: both had shipped web React apps, neither had touched mobile.

I kept a diary of every friction point. This is it.

The pattern held the way it always does. The first week was dominated by problems the template could have prevented, not by the problem the app actually solves.

Environment setup: estimated 2 hours, took about 5 per dev
Nobody knew the difference between Expo Go, dev builds, and EAS builds
Auth was implemented correctly in three places, so both devs picked differently
One deep link cost 6 hours for one dev and 8 for the other
Total avoidable loss: roughly 15 hours each, all of it fixable with docs and one shell script

Day 1: the environment install cliff

Estimated 2 hours. Took about 5 per dev.

Wrong Node version. One had 20, one had 16. The README said "Node 18+" while .nvmrc pinned 18.17. Nothing surfaced the mismatch; things just failed oddly downstream.
Missing Xcode command line tools. Silent until expo run:ios errored with a message mentioning xcrun and not what to install.
CocoaPods version mismatch. Silent until pod install failed four layers deep in a trace.
Wrong Android SDK path. Both devs. Symptom was expo run:android unable to find adb. Fix was setting ANDROID_HOME properly in the shell profile.

None of these are template bugs. They're template UX failures. A setup script that checks Node version, xcrun availability, CocoaPods version, and ANDROID_HOME up front, then fails loudly with an actionable message, would have saved three hours each.

The pattern in all four: the failure surfaced far from its cause. That's the property that turns a five-minute fix into a two-hour one.

Day 2: the build system nobody explained

Task: add a screen, preview it on a phone.

Both devs added the screen without trouble. Both got stuck getting a build onto their device.

Neither knew the difference between Expo Go, a development build, and an EAS build. These are three different things with three different use cases and the README described only expo start.
One got a build that installed and crashed on launch, because the required environment variables weren't set in EAS secrets.

The fix isn't code. It's a page explaining how the build system works: what each build type is for, when to use which, and where environment variables live. Five minutes to write. Three hours to skip.

Day 3: auth that was correct in three places

Task: add a protected route.

Both implemented it. Both did it slightly wrong, in different ways, and both were defensible readings of the codebase.

The auth context was wired through a provider, but route protection existed in the root layout, in individual screens, and in a custom hook. Three valid patterns, no indication which was canonical.
Token refresh happened invisibly through middleware. Nothing documented that it existed. One dev spent two hours building a refresh mechanism that was already running.
The RLS policies governing the protected data lived in a separate repo. Neither dev knew, and both were confused when a correctly authenticated request returned an empty array.

That last one is worth sitting with. Nothing errored. Auth worked, the request succeeded, the array came back empty, and the actual cause was in a repository they hadn't been told about.

Fix: one auth architecture page. A diagram of token flow, one worked example of protecting a route, and a pointer to where RLS policies live. Fifteen minutes to write once.

Day 5: the deep link that ate a day

Task: magic-link email flow. User taps a link, app opens, lands on a specific screen.

One dev took about 6 hours. The other about 8. It should have been 90 minutes.

The template used imperative routing, so deep linking required a manual linking config that wasn't documented anywhere.
Dev builds and production builds had different bundle identifiers, so a link opened one and not the other. Neither dev knew this was normal, and both assumed they'd broken something.
Testing required xcrun simctl openurl on iOS and adb shell am start on Android. Neither had used either command.

Had the template shipped with file-based routing, deep linking would have worked automatically for any route file. This was the most expensive lesson of the week and the one most attributable to an architectural choice rather than a documentation gap.

What the template should have shipped

In priority order:

A doctor script. Checks every dependency, fails loudly, tells you what to install.
A build system page. Expo Go vs dev build vs EAS build, 200 words, with a decision tree.
An auth architecture page. Where tokens live, how refresh works, where RLS policies are, one worked example.
File-based routing. Every concern you can defer to convention is a concern you don't have to teach.
A testing on device page. Simulator, emulator, physical device via EAS, physical device via QR.

Four of those five are documentation. None is a code change. Combined they'd have cut roughly 15 hours from each dev's first week.

This is the part I keep relearning: the expensive gaps in a template are rarely architectural. They're the things everyone on the team already knows and nobody wrote down.

The onboarding checklist we ship now

Every project gets a docs/ONBOARDING.md:

Run the doctor script. Fix every red item before continuing.
Copy .env.example to .env. Ask your lead for values.
Run in Expo Go. Scan the QR. Confirm you see the home screen.
Read docs/architecture/auth.md. Five minutes.
Read docs/architecture/builds.md. Five minutes.
First PR: add your name to docs/team.md. Get it reviewed. Merge.
Second PR: add a new route. Get it reviewed. Merge.
Now start real work.

Eight steps, roughly four hours if the tooling cooperates. It replaces about a week of ad-hoc onboarding, and steps 6 and 7 exist purely so someone's first merge is trivial rather than load-bearing.

Templates that ship this kind of thing by default, like the Expo starters at Applighter, remove most of week one before it starts. But you can write the four pages above for your own codebase this afternoon, and you should.

The closing note

A good template isn't only about code architecture. It's about the first week of somebody's life on your project.

Every minute of documentation skipped in the template costs hours of confusion downstream, and it costs them from the person least equipped to absorb it: the one who just joined and doesn't yet know what's normal.

What ate your first week on a new codebase? Mine was an undocumented env var that made the app silently render an empty state.

React Native Performance Optimization: The 2026 Playbook

Jules Sarah — Tue, 11 Aug 2026 09:48:19 +0000

Profile before changing code. Before/after numbers required in every performance PR.
New Architecture on (default since RN 0.76) is the single biggest win.
Hermes stays on; the footgun is source maps, not the engine.
FlashList for any list past ~50 items. Set estimatedItemSize.
Animations off the JS thread: Reanimated 4, Gesture Handler, Skia.
Ship a performance budget in CI with Flashlight so regressions break the build, not the App Store rating.

Most React Native apps do not need more code to feel fast. They need less of the wrong code, in the right places. In 2026 the platform has changed enough (New Architecture is default, Hermes is default, FlashList is stable, Reanimated 4 is stable) that the old advice, memoize everything, throw shouldComponentUpdate at every list item, dread the bridge, is either automatic or actively wrong.

This is the current playbook. It is opinionated, ordered by impact, and it assumes one thing above all: you measured the problem before you changed any code. That single discipline is worth more than every trick below combined.

What "fast" actually means in React Native

Before you optimize anything, agree with your team on numbers. "It feels slow" is not a spec. In 2026, a shippable React Native app on a mid-tier Android device (think Pixel 6a, Samsung A34) should hit:

Cold start under 2.0 seconds on Android, under 1.2 seconds on an iPhone 13, measured from tap to first interactive frame.
Sustained scroll at 58+ fps on lists of 500+ items with images.
Interaction latency under 100 ms from touch to visible state change.
JS heap under 180 MB during normal use, no monotonic growth over a 10-minute session.
Install size under 30 MB for the base binary, App Store thin variant.

If you cannot state your app's current numbers against these, that's the first fix. Everything below assumes you know where you stand.

Step 1: Profile first, stop guessing

React Native's performance surface spans three worlds: the JavaScript thread, the UI/main thread, and native modules. A bug in one will look identical to a bug in another until you profile.

The 2026 toolbelt:

Hermes Sampling Profiler: the primary tool for finding hot JS functions. It ships with React Native, has near-zero overhead, and produces flame graphs you can open in Chrome DevTools or Perfetto. Start every investigation here.
React DevTools Profiler: commit-by-commit view of which components rendered and why. Use it to catch re-render storms; the "Highlight updates when components render" toggle is the quickest way to see them without profiling.
Flashlight: CLI tool for measuring FPS, CPU, memory and JS thread health during scripted test runs. Puts real numbers on regressions in CI.
Perfetto (Android) and Instruments (iOS): for anything that crosses the native boundary: cold start, module init, layout, gesture responsiveness.
Expo's built-in performance inspector: if you're on Expo (you probably should be), the dev menu now includes an FPS meter and JS heap sampler that's good enough for 80% of day-to-day work.

The measurement rule is simple: produce a before number, produce an after number, and require both in the PR description. Every performance change without both numbers gets reverted on principle. This one rule alone will make your app faster than any single optimization on this list.

Step 2: Be on the New Architecture, the single biggest win

React Native 0.76 made the New Architecture the default. Expo SDK 52 followed. If you are still opted out, you are leaving a large share of your cold start and roughly all of your bridge overhead on the table.

The New Architecture is three pieces working together:

JSI (JavaScript Interface) replaces the old asynchronous JSON bridge with direct, synchronous calls between JS and native code. The bridge is gone. Calls that used to be serialize -> queue -> deserialize -> return -> deserialize are now function pointers.
Fabric is the new renderer. It's concurrent-mode aware, does layout on the UI thread, and eliminates the "commit storm" that used to cause jank during scroll + fetch combinations.
TurboModules are the successor to native modules. They load lazily (only on first use), which alone can shave 200–400 ms from cold start in apps with many linked modules.

Migration in 2026 is mostly a checkbox: "newArchEnabled": true in app.json for Expo, or the equivalent in gradle.properties and Podfile.properties.json for bare projects. What breaks are third-party native modules that never got upgraded; check each dependency's issue tracker before you flip the flag. Teams that finished the migration have reported cold starts improving by a third or more, list rendering throughput up by similar margins, lower memory use, and animation frame rates jumping from the high 40s to a steady 58–59 fps. Run your own before/after; the direction is consistent even where the exact numbers vary by app. This is the single largest performance change React Native has ever shipped.

The New Architecture in React Native 0.76+ is where the "React Native feels native" claim finally becomes true. Photo by Rob Hampson on Unsplash

Step 3: Hermes is the default, leave it on and understand what it's doing

Hermes is the JavaScript engine on iOS and Android by default in 2026. Its value is not just runtime speed, it's the ahead-of-time bytecode compilation step that happens during your build. Your app ships pre-compiled bytecode instead of raw JS, which is why cold starts on Hermes are typically much faster than on JSC.

Three things to actually do:

Confirm Hermes is on in your release build, not just dev. It's easy to miss when migrating from JSC. hermesEnabled=true in gradle.properties, :hermes_enabled => true in the Podfile, or the equivalent Expo config.
Enable bytecode precompilation in CI, so the bytecode is baked at build time rather than the first launch on device.
Check your source maps. Hermes bytecode makes stack traces unreadable in Sentry/Bugsnag without the correct source map upload. This is the one Hermes footgun that consistently bites teams in production.

The engine itself is stable. You do not need to tune it. The wins come from not accidentally disabling it and from wiring source maps correctly.

Step 4: FlashList for every list that matters

FlatList in 2026 is a fine default for short lists. The moment a list has more than ~50 items, images, or variable row heights, replace it with FlashList from Shopify. This is the single highest-leverage React Native optimization that requires you to write actual code.

FlashList is a drop-in replacement that recycles cells instead of unmounting them, does not allocate a new view for every item, and delivers several times the throughput of FlatList on data-heavy screens. On a Pixel 6a scrolling 1,000 image-plus-text rows, expect 58–60 fps sustained under FlashList against 30–40 fps with occasional freezes under FlatList.

Two rules to actually get the speedup:

Set estimatedItemSize accurately. Even off by 30% and you still get most of the win; missing entirely and FlashList falls back to slower measurement passes.
Do not put dynamic per-item work inside renderItem closures. Every re-render creates new closures; memoize row components and their handlers.

If your list has variable height rows and you cannot estimate size, use estimatedItemSize with the median height. Do not overthink it.

Step 5: Kill unnecessary re-renders, but only the ones that matter

Re-renders are the most over-optimized problem in React Native. Wrapping every component in React.memo bloats your bundle and slows down mounting. The rule for 2026: profile first, memoize where the profiler shows a hot path.

That said, four re-render anti-patterns cause most real performance bugs, and they're worth pattern-matching against:

Inline object props. <Component style={{ margin: 8 }} /> creates a new object on every parent render, which invalidates every downstream React.memo. Hoist styles into StyleSheet.create or a constant.
Inline handler props. <Button onPress={() => doThing(id)} /> creates a new function every render. Use useCallback, or better, move the handler inside a memoized child that owns the id.
Context provider sprawl. Every value change in a large context re-renders every consumer. Split contexts by update frequency: one for user identity (rarely changes), one for theme (rarely changes), one for live data (changes often). Do not put them all in a single context.
Selector reference issues. Redux/Zustand selectors that return new object references on every store update will re-render every consumer even if the values are identical. Use shallow equality checks or memoized selectors.

The why-did-you-render package is still the fastest way to find these in dev; it logs to console every time a memoized component re-renders unnecessarily.

Step 6: Move animations off the JS thread

An animation running on the JS thread will drop frames the moment JS is busy, which is always, because JS is where your business logic runs. In 2026 there is no reason to run animations on the JS thread at all.

The stack:

Reanimated 4 for anything driven by state, gesture, or timing. Its worklets run on the UI thread as native functions: a 60fps spring animation runs at 60fps even while the JS thread is parsing a 500KB JSON response.
React Native Gesture Handler for anything the user drags, swipes, or pinches. The old PanResponder API is JS-thread-bound and will jank; Gesture Handler runs on the UI thread.
Skia for anything painterly: charts, custom drawing, complex transitions. It bypasses the React view tree entirely and renders directly to a GPU canvas.

The rule: if you are writing Animated.Value with useNativeDriver: false, stop. Convert it to Reanimated or figure out why useNativeDriver: true isn't an option (usually it's an animatable prop that Reanimated supports and old Animated doesn't).

Step 7: Cold start, the number your users actually notice

Cold start is the sum of native init + JS bundle load + JS bundle execute + first render. The wins, in order of impact:

New Architecture on (Step 2). Biggest single win.
Hermes bytecode precompiled (Step 3). Second biggest.
Bundle size reduction. Every 100 KB of JS costs real parse+execute time on a mid-tier Android. Run npx react-native-bundle-visualizer and delete what surprises you. moment.js, lodash (full), and 5 different date-picker libraries you forgot you had are the usual suspects.
Lazy-load routes. Everything under React.lazy + Suspense at the route boundary. Your login screen does not need to parse your dashboard's 400KB of code.
Native module audit. Every linked native module runs its init code at startup. Remove modules you no longer use. Even removed JS imports leave native code linked until you unlink.
Font loading. Preload only the weights you use on the initial screen. Font.loadAsync for 12 weights blocks first paint for hundreds of ms.
Splash screen strategy. Keep the native splash visible until the first interactive screen is ready to render; don't cross-fade too early or you get a flash of empty content.

Instrument this with AppRegistry.setWrapperComponentProvider plus a manual mark at the first meaningful paint, log it to your analytics, and watch the median (not the mean; the mean lies).

Step 8: Memory, the silent killer

Memory leaks in React Native rarely crash the app. They just make it slower, and slower, and eventually the OS kills it in the background and users think "the app forgot me." The three sources that account for almost every leak in the wild:

Uncleaned event listeners. Every addEventListener, every subscribe, every AppState handler needs its cleanup in the useEffect return. The exhaustive-deps ESLint rule will not catch these; you have to review them.
Image caching without bounds. react-native-fast-image caches aggressively. Set a maxMemoryPolicy or your app will happily hold hundreds of MB of thumbnails. Same story for any list that renders image-heavy rows: use removeClippedSubviews and let FlashList recycle.
Uncleared timers and intervals. setInterval inside a component that mounts and unmounts on navigation is the classic leak.

Take a heap snapshot after 10 minutes of use, then again after 30, and compare. If the delta isn't roughly flat, you have a leak. The tool for this on iOS is Instruments' Allocations; on Android it's Android Studio's Memory Profiler.

Step 9: Network, the invisible half of "fast"

Users don't distinguish between "the app is slow" and "the network is slow." Your job is to hide the network from them.

TanStack Query for every fetch that has a cache key. Deduplication, background refetch, stale-while-revalidate: you get it for free. The single library that most improved perceived React Native performance in the last two years.
HTTP/2 or HTTP/3 on your API. If you're on HTTP/1.1 you're paying a full round trip per request. Cloudflare, Fastly, AWS ALB all default to HTTP/2 now.
Image CDN with responsive sizing. Serve 400×400 to the phone, not 4000×4000. Cloudinary, imgix, and Cloudflare Images all do this automatically from URL parameters.
Parallelize independent requests. Promise.all for anything that doesn't depend on the previous result.
Optimistic updates. For any user action that will succeed 99% of the time, update the UI immediately and roll back on error. Users feel every millisecond you make them wait for a spinner.

Step 10: Ship a performance budget in CI

Everything above is worthless if a well-meaning teammate ships a regression next Tuesday. The fix is a performance budget in CI, and the tool for it in 2026 is Flashlight.

Flashlight runs a scripted E2E test on a real (or emulated) Android device, records CPU/FPS/memory across the run, and fails the build if any metric exceeds the budget you set. Point it at your five most important user flows (cold start, login, main list scroll, detail view, checkout) and set the budgets 10–20% above your current numbers. Now every PR that regresses performance breaks CI, and the regression conversation happens in code review instead of in the App Store reviews six weeks later.

When to NOT optimize

Optimizing without measurement is how apps end up with 400 KB of memoization wrapping and no measurable difference. Three reasons to hold back:

The profiler doesn't show a hotspot. Then you're not fixing anything, you're just writing code.
The user cannot perceive the change. Nobody notices a 12 ms → 8 ms improvement on a screen that's already at 60 fps. They notice 30 fps → 60 fps. Chase the visible.
The optimization removes a real feature. Slower with the feature > faster without it, unless the feature is optional.

Where AI-generated code fits in

Modern AI mobile app builders like RapidNative have quietly closed a large part of this gap. When you describe an app in plain words and generate a real React Native + Expo project, the output already has the New Architecture enabled, Hermes on, FlashList for meaningful lists, Reanimated wired up, and TanStack Query for data, because those are the current defaults, and the model was trained on the current stack.

What AI generation does not do (yet, reliably) is your app's specific measurement work. It cannot know that your product screen renders 400 image cards and needs a memoized row component, or that your context provider has grown three orders of magnitude too much state. The playbook above is what you bring to a generated app: you get the correct baseline for free, and then you profile, measure, and tune what matters for your users.

If you're building a new React Native app in 2026, the fastest path is: generate the correct baseline, ship the first version, measure real user performance, and apply this playbook to what your profiler actually flags. Skip the weeks of boilerplate; spend that time on the parts of your app only you understand.

What's the optimization that actually moved your numbers, and what did you measure it with? Drop it in the comments; the profiler-verified wins are the ones worth collecting.

The App Store Privacy Declaration Checklist Nobody Gives You

Jules Sarah — Fri, 07 Aug 2026 07:36:45 +0000

Google Play's data safety form and Apple's PrivacyInfo.xcprivacy are the same idea in two formats, and both reject apps whose declarations don't match reality.
Audit every SDK before touching either form: what it collects, linked or unlinked, and the purpose.
The six categories that catch first-timers: crash reporting, IP addresses, purchase history, diagnostics, ad SDKs, account creation.
Apple's manifest has been enforced since May 2024. Missing entries surface as App Store Connect warnings, then rejections.
Automate the mapping: keep an SDK inventory file and regenerate the declaration on every release.

Every mobile app submission has a wall you don't see coming. Not the review queue, not screenshot rejections: the privacy declaration. Google Play's data safety section and Apple's privacy manifest are the same idea in two formats, and both reject an app whose declaration doesn't match reality.

Why this matters

An incorrect privacy declaration is not a technical bug, it is a policy violation. Google Play rejects the update, and repeated violations put the developer account at risk. Apple's privacy manifest (PrivacyInfo.xcprivacy, enforced since May 2024) surfaces missing entries as App Store Connect warnings, then rejections.

Most indie developers fill these forms from memory five minutes before submitting, then spend the next week resubmitting because they forgot Sentry collects device identifiers.

The full inventory audit

Before touching either form, list every third-party SDK in the app. For each, note three things: what it collects, whether that data is linked to the user (account ID or device ID) or unlinked, and whether it serves analytics, personalization, advertising, or app functionality.

Common indie-app SDKs and what they collect:

SDK	Collects	Linked?	Purpose
Firebase Analytics	Device ID, session data, user actions	Linked (Firebase user ID)	Analytics
Sentry	Device model, OS version, stack traces	Unlinked unless user context attached	Diagnostics
RevenueCat	Purchase history, subscription state	Linked (RevenueCat user ID)	App functionality
Mixpanel / PostHog	User actions, custom events	Linked (your user ID)	Analytics
AdMob / AppLovin	Device ID, ad interaction	Linked	Advertising

This audit output is what you reference against every question on both platforms' forms.

The 6 categories that trip up first-time submitters

Crash reporting. Counts as collection even if you never look at it. Sentry, Crashlytics, Bugsnag all collect declarable types.
IP addresses. Every network request logs an IP somewhere. If your backend logs IPs (it does), you collect device identifiers.
Purchase history. StoreKit or Play Billing plus RevenueCat means financial info, even though card data never touches your servers.
Diagnostic data. Performance metrics, ANR reports, custom logs. All collection.
Ad SDK data. Any monetization SDK means collecting for advertising. The most common source of rejections.
Account creation. Email, password hash, phone: always linked, always declared.

Google Play vs App Store

Same intent, different formats.

	Google Play	App Store
Format	Question-based Console form	`PrivacyInfo.xcprivacy` plist in the bundle
Structure	~40 questions across 14 data categories	Typed entries per data type plus required-reason API codes
Filled	In the Play Console UI	In code, merged from your app and every SDK's own manifest

Xcode 15+ merges your manifest with every SDK's bundled manifest into one privacy report, which feeds the App Store label. Fill the two platforms out separately; there is no shared source unless you build one.

Copy-paste starting point

For a typical indie app (analytics + crash reporting + payments):

You use	Play form answer	Apple manifest data type
Firebase Analytics	Collects: Device IDs, App interactions. Purpose: Analytics	`NSPrivacyCollectedDataTypeDeviceID`, `NSPrivacyCollectedDataTypeProductInteraction`
Sentry	Collects: Crash logs, Diagnostics	`NSPrivacyCollectedDataTypeCrashData`, `NSPrivacyCollectedDataTypePerformanceData`
RevenueCat	Collects: Purchase history	`NSPrivacyCollectedDataTypePurchaseHistory`

A starting point, not an answer key: verify each SDK's current documentation at submission time, since collection profiles change between versions.

Automate this, don't guess

Maintain a spreadsheet or JSON file with your SDK inventory and each one's collection profile, and regenerate the declaration on every release instead of recalling it. CI tooling such as LetsDeploy can diff your dependency list against the last declared inventory and fail the build when a new SDK appears undeclared. Fifteen minutes building this system saves days of rejection cycles per year.

What's the SDK that surprised you most on a privacy form? Mine was learning that crash logs count. Drop yours in the comments.

The Onboarding Chapter Missing From Most SaaS Template Reviews

Jules Sarah — Thu, 06 Aug 2026 09:37:42 +0000

The Onboarding Chapter Missing From Most SaaS Template Reviews

Most SaaS template reviews follow the same format.

Which framework does it use?
Does it support authentication?
Which database does it ship with?
Is the codebase clean?
Is it worth the price?

Those questions matter.

But they rarely cover the part that determines whether your users actually stick around:

The onboarding experience.

A modern tech stack gets people through signup.

A thoughtful onboarding flow gets them to their first success.

The tech stack tells you nothing about retention

A template with the latest version of Next.js, a polished UI, and perfect TypeScript can still lose users before they ever experience the product's value.

Meanwhile, a template running a slightly older stack—but with a carefully designed onboarding experience—can create happier users from day one.

The framework determines what's possible.

The onboarding determines whether users ever get there.

What a good onboarding flow contains

After reviewing dozens of SaaS templates, the best ones usually include most of the following.

Users land somewhere useful

Nobody likes opening a blank application.

If it's a project management app, preload a sample project.

If it's an analytics product, show demo charts.

If it's a CRM, include sample contacts.

An empty product feels unfinished.

A populated product teaches by example.

A short first-run experience

Not a ten-minute walkthrough.

Not a feature tour.

Just three to five focused steps that help users complete the product's primary workflow.

The goal isn't education.

The goal is momentum.

Activation events are already wired

The best templates don't just include analytics.

They already track the moments that matter.

trackEvent("signup_completed")
trackEvent("workspace_created")
trackEvent("first_invite_sent")
trackEvent("integration_connected")
trackEvent("subscription_started")

You can always replace the analytics provider later.

What's valuable is that somebody already identified the events worth measuring.

Empty states teach

Good empty states answer the question:

"What should I do next?"

Bad empty states say:

No projects yet.

Good empty states say:

You don't have any projects yet. Start by creating one for your team's current goal.

That's product design—not placeholder text.

Trial status is obvious

If users are on a 14-day trial, they should always know:

How many days remain
What happens when it ends
What features they're currently using

No surprises.

The first week is already planned

Great templates include more than a welcome email.

They ship with an onboarding sequence like:

Day 0 — Welcome
Day 2 — First success tips
Day 5 — Feature discovery
Day 10 — Trial reminder
Trial ended — Next steps

That saves teams days of writing and experimentation.

Ship activation events, not just dashboards

Every SaaS template includes an admin dashboard.

Very few include meaningful analytics instrumentation.

The templates worth adopting already track moments like:

Signup completed
First workspace created
First invite sent
First integration connected
First subscription started

The code itself isn't complicated.

What's valuable is the product thinking behind it.

Empty states are a UX exercise

Every empty screen is an opportunity to help users.

Compare these two messages.

Version A

No items found.

Version B

You don't have any projects yet. Most teams begin by creating a project around their current quarterly goal.

One creates confusion.

The other creates momentum.

When reviewing a SaaS template, browse every screen with zero data.

If every page says "No items yet," you'll spend weeks fixing onboarding gaps after launch.

How to spot templates that took onboarding seriously

Look for these signals:

✅ Demo ships with realistic sample data

✅ First-run onboarding is built into the demo

✅ Activation events are already instrumented

✅ Empty states teach users what to do next

✅ Subscription and trial status are visible

✅ Transactional onboarding emails are included

Templates that check every box are surprisingly rare.

When you find one, you're paying for product thinking—not just code.

Applighter's take

At Applighter, we've learned that onboarding deserves the same attention as architecture.

That's why our templates include:

Sample workspaces from day one
Activation events wired into the product
Empty states that guide instead of confuse
A complete first-week onboarding email sequence

Whether you choose Applighter or another template, evaluate onboarding with the same rigor you evaluate the tech stack.

Because users don't retain because your framework is modern.

They retain because they know what to do next.

Final thoughts

The SaaS template ecosystem spends a lot of time comparing frameworks.

Users don't.

They care about one thing:

Can I succeed in the first five minutes?

The best templates answer that question before the user ever has to ask it.

That's why onboarding deserves to be part of every SaaS template review.

Ship a React Native app in days, not months

Jules Sarah — Fri, 31 Jul 2026 10:38:06 +0000

If you've ever started a React Native project on Monday and looked up on Friday to realize you've written zero product code, only auth, DB migrations, and EAS config, this post is for you.

Applighter customers ship in days, not months. Not because they're faster developers, but because the patterns below are already in the repo when they clone it.

The setup tax

Every React Native project pays it:

Task	Days
Auth (email + OAuth)	3–5
DB schema + RLS	2–4
Stripe + entitlements	3–5
AI streaming	4–7
EAS build/submit	1
Design system	2–3
Push	2
Total	~4 weeks

Before line one of your product code.

Pattern 1: one theming primitive

// app/apps/lib/theme.ts
export function applyProductTheme(brandHex: string) {
  const hsl = hexToHsl(brandHex)
  // propagates to background, foreground, primary, secondary,
  // muted, accent, destructive — all HSL-derived
  return buildPalette(hsl)
}

One color in, full palette out. Rebrand an app in 20 minutes, not a weekend of grep-and-replace.

Pattern 2: hybrid data provider

// app/apps/lib/data/provider.ts
export async function getProductData(slug: string) {
  try {
    const data = await fetchFromSupabase(slug)
    if (data) return data
  } catch {}
  return staticFallback[slug]  // ships in the bundle
}

Cloned repo runs on the simulator without env vars. First-run latency: 60 seconds, not 90 minutes.

Pattern 3: RLS pre-baked

-- supabase/migrations/20260112085737_create_transactions_table.sql
alter table transactions enable row level security;

create policy "users read own transactions"
  on transactions for select
  using (auth.uid() = user_id);

Every table ships with the policy. You audit, you don't design.

Reference: Supabase RLS docs.

Pattern 4: Stripe → grant → download

// app/api/webhook/stripe/route.ts
if (event.type === "checkout.session.completed") {
  const { isBundle, targets } = await resolveGrantTargets(supabase, productId)
  await grantProducts(supabase, {
    userId,
    productId,
    licenseType,
    source: "stripe_purchase",
  }, targets)
  await sendReceiptEmail({ userId, downloadUrl })
}

Bundles expand into individual grants. Guest checkouts validated by session_id. Single/Multiple/Enterprise license types. It's the code you'd write on day 4 of a Stripe integration, except it's already there.

Pattern 5: EAS ready

// eas.json
{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal" },
    "production": { "autoIncrement": true }
  },
  "submit": { "production": {} }
}

/ship slash command → eas build --profile production && eas submit. See Expo EAS docs.

Pattern 6: agent-legible codebase

Every template ships with a .claude/ directory of slash commands. /add-screen, /swap-backend, /audit-security. They work because the codebase is:

Small files, obvious responsibilities
NativeWind classes (Tailwind semantics)
Typed data providers
Colocated components with their tests

An agent (Claude Code, Cursor) can extend it without wandering. That's a real speed multiplier in 2026.

Comparison

	From scratch	Free boilerplate	Applighter
Time to TestFlight	4–6 weeks	2–3 weeks	3–5 days
Backend	You build	Not included	Supabase, wired
Payments	You build	Not included	Stripe + grants
RLS	You design	N/A	Pre-baked
Updates	You maintain	Repo-dependent	Lifetime
Cost	~$8–20k dev time	Free + hidden time	$79 one-time

What ships in days vs. weeks

Bimodal distribution across ~500 customers:

3–5 days: rebrand-and-launch on an existing template (weather, fitness, e-learning)
2–4 weeks: novel AI product built on template infrastructure (voice notes, PDF chat, calorie tracker)

Both compress the ground-up equivalent by ~4x.

When not to use a template

Building something the data model doesn't stretch to fit (games, real-time collab)
Learning React Native for its own sake
Need a stack we don't ship (Firebase, Convex, bare RN)

FAQ

Do I need Supabase experience? No. Templates run with the DB seeded.

Can I skip the theming layer? Yes. Default colors ship out of the box.

What if a new Expo SDK breaks it? Updates are pushed to your dashboard. Pull and diff.

Refunds? 7-day money-back. Policy is on the site.

Try one

Browse the full template catalog. $79 one-time, full source, lifetime updates. Ship this week.

The React Native template launch that made us $87

Jules Sarah — Wed, 29 Jul 2026 04:34:56 +0000

Note: This is the honest developer-story version of an internal postmortem. If you want a shorter, more meme-friendly version, we have one on Medium. If you want a first, code-heavy version, it's on Dev.to. This one is the long form.

Where we started

Two founders. 180 combined hours of work. One React Native template we were quietly proud of. Twelve screens, Expo SDK, TypeScript, NativeWind, tab-based navigation, auth screens that looked like Instagram's. We priced it at $29 and launched on a Tuesday morning.

By Friday evening we had:

5 sales
4 refund requests
1 chargeback in flight
$87 in the bank
1 email from a customer named "Dev" (probably not his real name) that started with "Hey guys, I have to be honest with you..."

That email is where this post starts.

The email that changed the company

The paraphrased version:

I thought this was going to save me a week. It saved me maybe an evening. The auth doesn't connect to anything, the API returns hardcoded data, and I still have to build the entire backend. Why did I pay $29 for what's basically a Figma export in TypeScript?

Every sentence was honest. We had shipped a UI kit. Our landing page used the phrase "full-stack" four times. In the repo, "full-stack" meant this:

// src/services/mockApi.ts
export const HARDCODED_NOTES: Note[] = [
  { id: '1', title: 'Meeting notes', body: '...' },
  { id: '2', title: 'Idea', body: '...' },
];

export async function getNotes(): Promise<Note[]> {
  await sleep(300); // for that "loading" feel
  return HARDCODED_NOTES;
}

The auth screens looked professional and did nothing. The Supabase env vars were placeholders. We had, to be blunt, defrauded the word "full-stack."

The audit

Before rebuilding, we forced ourselves to write down every layer where v1 fell short of the promise on the landing page.

Layer	Landing page promise	v1 reality
Database	"Postgres schema, migrations, seed data"	Zero SQL files
Auth	"Supabase Auth with email + OAuth"	UI screens returning fake sessions
Storage	"File uploads with signed URLs"	localStorage
AI	"OpenAI + Anthropic integration"	Not present
RLS	"Row-level security policies"	Not present
Docs	"Complete setup guide"	800-word README
Demo	"See it in action"	Six screenshots

The audit was demoralizing. It was also the roadmap.

The rebuild, layer by layer

Layer 1: real Postgres schema

Every current template ships with a supabase/migrations/ folder containing the actual tables the app needs, not a hand-wavy ER diagram. Buyers can run supabase db push and have a working schema before they've written a single line of code.

-- supabase/migrations/00_notes.sql
create table notes (
  id uuid primary key default gen_random_uuid(),
  user_id uuid not null references auth.users on delete cascade,
  title text not null,
  body text,
  created_at timestamptz default now()
);

alter table notes enable row level security;

create policy "Users read their own notes"
  on notes for select
  using (auth.uid() = user_id);

Layer 2: auth that actually authenticates

Email, Apple, and Google via Supabase Auth, with session hooks that persist across app restarts and refresh silently. The auth screens no longer lie.

Layer 3: storage with signed URLs and RLS

For templates like Chat with PDF, file uploads go straight to Supabase Storage with a signed URL flow and per-user RLS. No customer support ticket has ever said "the file upload doesn't work."

Layer 4: real AI service layer

An Edge Function proxies OpenAI, Anthropic, or ElevenLabs calls using the buyer's own API keys. It's modular: swap GPT-4o for Claude by changing a config constant. No vendor lock-in.

Layer 5: RLS policies from day one

Every template ships with per-table policies and two seed users so buyers can immediately verify that user A cannot see user B's data. This is table-stakes for production apps, and yet somehow rare in the template market.

Layer 6: 12,000-word docs, plus video

The single highest-leverage rebuild task. Written as copy-pasteable step lists with expected output. If a step is ambiguous, it gets rewritten.

Layer 7: agent-readiness

The one most competitors still ignore. Every template ships with:

A root CLAUDE.md describing the codebase in agent-friendly terms
Slash commands and skills for the common workflows (/add-screen, /add-supabase-table, /swap-ai-provider)
Real TypeScript types across the board (no any)
A file layout an agent can grep in one pass

It's tested against Claude Code, Codex, Cursor, OpenCode, and Windsurf, because in 2026 the buyer's first interaction with your codebase is via an agent.

Pricing: from $29 to $79

Counterintuitive lesson: raising the price improved every downstream metric.

At $29, we attracted price-shopping buyers whose expectations were "this must also do my dishes." Refund rate was around 40%.

At $79, we attracted senior indies who value their own hour at $100+ and are buying back time. Refund rate dropped to around 4%.

The right customer for a React Native template is not price-sensitive. They are time-sensitive. Price signals seriousness.

The demo video, in detail

40 seconds. Silent. One take. This is the shot list:

Terminal shows git clone, then npx expo start
iOS Simulator boots
Sign up as a new user
Do the hero action (record voice note, upload PDF, whatever the app does)
Cut to the Supabase table view showing the row that just landed
Fade out on the app logo

Nothing else. No music. No voiceover. The point is to remove doubt, not to entertain.

v1 vs v2 vs building from scratch

	v1 ($29)	v2 ($79)	From scratch
Setup time	~2 hours	~30 minutes	3–6 weeks
Backend	Mocked JSON	Real Supabase	You build it
RLS	None	Per-table + seed users	You write it
Demo	Screenshots	40-sec video	N/A
Agent-ready	None	Skills + slash commands	You configure
Docs	800 words	~12,000 words + video	N/A
Refund rate	~40%	~4%	N/A

For comparison, competitor templates like Ignite Cookbook ship strong scaffolding but leave the backend and AI as reader exercises. In 2026 that's the wrong tradeoff.

The cost of getting it wrong

180 hours on v1 that no one wanted
$600 in ads that returned nothing
200 hours on the rebuild
~$40k in real engineering opportunity cost
Six months of momentum

The postmortem was expensive. This blog post is us trying to make it slightly cheaper for the next founder considering a React Native template.

What I'd tell 2025-me

Docs first. If they're hard to write, the product is wrong.
$79 minimum. Cheaper attracts refund-prone buyers.
Real backend day one. Mock nothing a reasonable buyer expects to be real.
One demo video per template. 40 seconds. Silent. Happy path.
Ship for agents. CLAUDE.md, slash commands, real types.
Refund policy above the buy button. In big text.

The gap between "nice UI in a week" and "template a senior indie pays $79 for" is roughly three months of unglamorous infrastructure. Skip any of it and the launch dies quietly.

You can see where all of this ended up at Applighter.

Cutting React Native template support 70% with docs

Jules Sarah — Fri, 24 Jul 2026 09:52:54 +0000

We sell React Native templates. In Q1 2026 we rewrote our docs. Support tickets dropped 70%. This is the exact process, the exact structure, and the numbers.

The audit (do this first)

Before rewriting a single page, tag every support ticket for six weeks. Six columns:

date | customer | category | root_cause | resolution | in_docs?

Categories we ended up with: install, configure, extend, ship, billing, other.

Root causes: docs_missing, docs_wrong, docs_unfindable, product_bug, user_misunderstanding, out_of_scope.

The audit output for us:

Category	% of tickets	Docs-fixable?
install	24%	yes
configure	21%	yes
extend	18%	yes
ship	5%	yes
billing	10%	no
other	22%	mostly no

68% of tickets were docs-fixable. That number is the whole rest of the article.

The four-mode structure

Restructure your doc site around the four stages a new customer hits, in order:

docs/
├── getting-started/     # install
│   ├── installation.mdx
│   ├── environment.mdx
│   ├── quick-start.mdx
│   └── folder-structure.mdx
├── core-concepts/       # configure
│   ├── supabase.mdx
│   ├── expo-integration.mdx
│   └── ui-components.mdx
├── extend/              # extend
│   ├── adding-a-screen.mdx
│   ├── auth-guards.mdx
│   └── swapping-ai-provider.mdx
└── ship/                # ship
    ├── eas-build.mdx
    ├── app-store.mdx
    └── ota-updates.mdx

Order matters. Doc-site ordering is not aesthetic — it's a state machine. Each page assumes the customer completed the previous one.

The five rules

Print these. Stick them to a monitor.

1. First paragraph states the outcome, not the topic.

Bad:

# Authentication

This page covers authentication in the template.

Good:

# Adding auth to a new screen

By the end of this page, tapping a locked screen will redirect
signed-out users to `/sign-in` and preserve the deep link they
originally opened.

2. Every code block is copy-paste runnable.

Bad:

// ... existing imports
export function Screen() {
  const { user } = useSupabase();
  // ...
}

Good:

import { useSupabase } from "@/lib/supabase";
import { Redirect } from "expo-router";

export function ProtectedScreen() {
  const { user, loading } = useSupabase();
  if (loading) return null;
  if (!user) return <Redirect href="/sign-in" />;
  return <YourScreenContents />;
}

3. Every page links to the next page. Never let the customer bounce to Google.

4. If you answer the same email twice, the docs get updated that day. Same day. This is the only rule with real leverage.

5. Ship a claude.md at the project root. If your customer opens the template in Claude Code, Cursor, or any AI-native editor, the AI reads this file first. Ours looks roughly like this:

# Applighter — <template name>

## Stack
- Expo 54, React Native 0.76
- Supabase (auth, Postgres, storage, edge functions)
- NativeWind 4, React Native Reusables (primitives)
- TanStack Query 5

## Key files
- `app/(auth)/*` — auth flows
- `app/(app)/*` — signed-in surface
- `lib/supabase.ts` — client + typed helpers
- `supabase/migrations/*` — schema (RLS policies live here)

## Conventions
- All server access via TanStack Query hooks in `hooks/`
- Never call supabase-js directly from a component
- Add new tables with a migration, not the dashboard

## Env vars
See `.env.example`.

The AI now writes correct code the first time. The customer never emails you.

Operational loop

Once the docs exist, keep them alive:

Log every ticket in a shared sheet (six columns above).
30-minute triage every Friday. Flag anything asked twice.
Doc gap → paragraph inline or new page scaffolded same day.

That's it. No LLM classification. No analytics vendor. The marginal cost of writing one paragraph is much lower than the marginal cost of answering the same email eight times.

Results

Support tickets: −70%
Docs-caused refunds: −85% (from ~4% to ~0.6% of purchases)
Time-to-first-customized-screen: 2–4 hours → 25–45 min
Five-star reviews mentioning "docs": 2 → 34 across two quarters

What we didn't do

No chatbot. Deflection metrics are gameable.
No paywalled docs. Public and indexable.
No community forum. Half-populated forums are worse than none.
No codebase restructure to match docs. Different audiences, different shapes.

Reference docs I used

Diátaxis framework — the closest published version of what we independently arrived at
Expo docs — the bar for RN documentation
Supabase docs — same

We build production-ready React Native templates at Applighter — the docs described above ship with every one of them.

If you've run this audit on your own support inbox, what was your docs-fixable percentage? I suspect 68% isn't unusual.

The Complete Guide to Offline Storage in React Native (2026)

Jules Sarah — Wed, 22 Jul 2026 11:25:11 +0000

Offline storage is five categories, not one library: key-value, secure, structured, file system, and server-state cache.
MMKV is the new default over AsyncStorage — roughly 30× faster with synchronous reads.
The offline-first pattern has four parts: local-first reads, optimistic writes, a durable mutation queue, and a sync engine.
Conflict resolution: last-write-wins is fine for most consumer apps. CRDTs are overkill unless you're building a collaborative editor.

Most React Native apps treat the network as an always-on dependency, and it shows the moment a request stalls.

Offline storage isn't one library — it's a stack: key-value stores for preferences, secure enclaves for tokens, structured DBs for domain data, and query caches for server state.

This post walks through the whole stack and the offline-first pattern that ties it together.

The five categories of RN offline storage

Key-value — AsyncStorage (compat) or MMKV (default). MMKV is ~30× faster and supports synchronous reads.
Secure — expo-secure-store or react-native-keychain. Backed by iOS Keychain / Android Keystore.
Structured — expo-sqlite, op-sqlite (JSI, synchronous), WatermelonDB (reactive + sync), Realm (Atlas Device Sync).
File system — expo-file-system for media. Never base64 blobs into KV storage.
Server-state cache — TanStack Query with persistQueryClient, backed by MMKV.

Comparison table

Library	Type	Perf	Encryption	Best for
AsyncStorage	KV	1×	Community fork	Legacy / compat
MMKV	KV	~30×	Built-in	New default
expo-secure-store	Secure KV	—	OS keychain	Tokens
op-sqlite	SQL	JSI	SQLCipher	Structured data
WatermelonDB	Reactive DB	Lazy	SQLCipher	Large offline lists + sync
Realm	Object DB	Fast	Yes	Atlas Device Sync

The offline-first pattern

Four moving parts:

Local-first reads. The UI always reads from the local store. The network populates the store; the store renders the UI.
Optimistic writes. The UI updates immediately, before the server acknowledges.
Mutation queue. A durable list (SQLite or MMKV) of pending server-side changes, each with a client ID.
Sync engine. A background worker drains the queue with exponential backoff and reconciles conflicts.

async function markMessageAsRead(id: string) {
  db.write(() => {
    db.messages.update(id, { readAt: Date.now(), pendingSync: true });
  });

  await mutationQueue.enqueue({
    kind: 'message.markRead',
    payload: { id, readAt: Date.now() },
    clientId: uuid(),
  });

  syncEngine.wake();
}

Conflict resolution

Last-write-wins. Timestamps, newest wins. Fine for most consumer apps.
Server-authoritative. Reject stale writes with a version mismatch.
CRDTs. Yjs or Automerge. Overkill unless you're building a collaborative editor.

Decision cheat sheet

Preferences or JWT? → MMKV + expo-secure-store
Instant-open cached lists? → TanStack Query with persistQueryClient on MMKV
Thousands of offline records? → op-sqlite, or WatermelonDB if you want reactive
Cross-device sync? → WatermelonDB or Realm
Media? → expo-file-system with metadata in SQLite

Pitfalls to skip

Blocking the JS thread with async AsyncStorage calls at startup
Storing blobs in KV stores
No cache wipe on logout
Infinite retry loops in the mutation queue
Persisting Redux state without a schema version

Wrap-up

Offline-first isn't a defensive posture — it's a performance strategy. Reading from local storage beats a round-trip every time, and a good sync engine hides the network from your users entirely.

Pick each layer deliberately and this becomes a solved problem rather than a recurring one.

I built RapidNative, an AI mobile app builder that generates production-ready React Native code you can extend with any of these libraries.

Anyone running MMKV + TanStack Query in production? Curious how the persistence layer has held up for you at scale.

DEV Community: Jules Sarah

How we cut support tickets 70% with docs

The audit

Change #1: Index error strings, not concepts

Change #2: One environment.mdx, not seven scattered mentions

Change #3: Six-command quick start

Change #4: Prominent support surface, routed through docs

What didn't work

The seven-page scaffold

Metrics worth tracking

References

The auth-screen UX playbook for Expo apps

The legitimacy scan

Keep the OAuth callback in-app

Password reset is a funnel nobody revisits

Error copy that doesn't alarm people

The general shape

7 AI App Templates in 12 Months: What We Learned

The stack

The registry pattern

1. AI feature, not AI wrapper

2. RLS is the moat

3. SDK bumps eat weeks

4. Payments is a project

5. NativeWind and Reanimated

6. Demo video beats README

7. Pricing

Scratch versus template

What we'd do differently

Wrap

Rebuilding a Next.js MDX docs site without a framework

The stack

Directory layout

The loader

The dynamic route

Why we skipped the frameworks

The MDX component override pattern

What we still don't have

When this pattern breaks down

References

What we'd do differently

Two Junior Devs, One Expo Template, and 15 Hours Lost to Docs That Didn't Exist

Day 1: the environment install cliff

Day 2: the build system nobody explained

Day 3: auth that was correct in three places

Day 5: the deep link that ate a day

What the template should have shipped

The onboarding checklist we ship now

The closing note

React Native Performance Optimization: The 2026 Playbook

What "fast" actually means in React Native

Step 1: Profile first, stop guessing

Step 2: Be on the New Architecture, the single biggest win

Step 3: Hermes is the default, leave it on and understand what it's doing

Step 4: FlashList for every list that matters

Step 5: Kill unnecessary re-renders, but only the ones that matter

Step 6: Move animations off the JS thread

Step 7: Cold start, the number your users actually notice

Step 8: Memory, the silent killer

Step 9: Network, the invisible half of "fast"

Step 10: Ship a performance budget in CI

When to NOT optimize

Where AI-generated code fits in

The App Store Privacy Declaration Checklist Nobody Gives You

Why this matters

The full inventory audit

The 6 categories that trip up first-time submitters

Google Play vs App Store

Copy-paste starting point

Automate this, don't guess

The Onboarding Chapter Missing From Most SaaS Template Reviews

The Onboarding Chapter Missing From Most SaaS Template Reviews

The tech stack tells you nothing about retention

What a good onboarding flow contains

Users land somewhere useful

A short first-run experience

Activation events are already wired

Empty states teach

Trial status is obvious

The first week is already planned

Change #2: One `environment.mdx`, not seven scattered mentions