DEV Community: Chris F A

What React Native Devs Actually Struggle With: A Year of Support Tickets

Chris F A — Mon, 28 Sep 2026 14:46:48 +0000

TL;DR

We categorized twelve months of Applighter support tickets. The framework isn't the problem; the perimeter is.
Top 3: EAS Build failing on first run, Supabase RLS returning [], env vars undefined in production builds.
Run bunx expo doctor before asking for help. It usually names the broken file.
Only EXPO_PUBLIC_ vars reach the app bundle, and your .env is probably gitignored from EAS.
Use expo/fetch for AI streaming. The default RN fetch won't stream.
Put your cache reset in a script. You'll type it wrong at 2am otherwise.

People file tickets when they're bleeding, not when they're reflecting. So a year of support tickets paints a very different picture than community surveys. Here's the top ten, ordered by volume, with the fix for each.

#	Problem	Layer
1	EAS Build fails on first run	build
2	Supabase RLS returns empty arrays after auth	backend
3	Env vars don't reach the native binary	build
4	Metro cache poisoning after a dependency bump	build
5	Missing iOS Info.plist permission strings	ios
6	Android package name conflicts on rename	android
7	Android push silently not delivering	native
8	AI streaming stalls / drops tokens	ai
9	Stripe webhook not reaching a Supabase Edge Function	payment
10	Voice transcription latency on mid-range Android	ai

1. EAS Build fails on first run

Clone, prebuild, build, and it dies at "Install pods" or in Fastlane signing. Three usual causes:

Template SDK and local CLI disagree (and nobody ran expo doctor)
A device profile used before provisioning exists
No EXPO_TOKEN in CI

Our templates now ship a preflight that blocks the build if doctor is red:

#!/usr/bin/env bash
# scripts/preflight.sh
set -e
bunx expo doctor || { echo "❌ Fix expo doctor issues before building"; exit 1; }

If you're building from CI, make sure the token is set:

env:
  EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

2. Supabase RLS returns `[]` after auth

"I'm signed in, I see my user ID, but select * returns nothing." Supabase isn't broken; RLS is working.

A typical owner-only policy:

alter table projects enable row level security;

create policy "owners can read their projects"
on projects for select
using (auth.uid() = owner_id);

Checklist:

Log the raw Authorization header. The token is often undefined.
auth.uid() vs auth.jwt() ->> 'sub' behave differently with anon requests mixed in.
Never ship the service_role key in a client bundle.
Access tokens expire after an hour by default. Make sure the session refreshes:

import { createClient } from '@supabase/supabase-js';
import AsyncStorage from '@react-native-async-storage/async-storage';

export const supabase = createClient(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY!,
  {
    auth: {
      storage: AsyncStorage,
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: false,
    },
  },
);

The full auth setup (email, OAuth, Sign in with Apple) is in our Supabase auth in React Native guide.

Mental model: policies are WHERE clauses that always run.

3. Env vars are `undefined` in production

Works in Expo Go, works in the simulator, undefined in the standalone build. Two reasons: .env is usually gitignored so EAS never sees it, and only EXPO_PUBLIC_ vars are inlined into the bundle.

- API_URL=https://api.example.com
+ EXPO_PUBLIC_API_URL=https://api.example.com

Then declare the values for EAS, either as EAS environment variables or per profile:

{
  "build": {
    "production": {
      "env": { "EXPO_PUBLIC_API_URL": "https://api.example.com" }
    }
  }
}

Reminder: EXPO_PUBLIC_ means public. No secrets.

4. Metro cache poisoning

Dependency bump, inscrutable crash, nothing works until someone says "reset the cache." Script it:

{
  "scripts": {
    "reset": "watchman watch-del-all; rm -rf node_modules ios/Pods .expo && bun install && bunx expo prebuild --clean"
  }
}

Lighter first attempt: bunx expo start --clear.

5. Missing Info.plist permission strings

Camera, mic, photos, or location without a purpose string means a failed upload or a review rejection. Say why, specifically:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSCameraUsageDescription": "This app needs camera access to scan documents.",
        "NSMicrophoneUsageDescription": "This app records voice notes."
      }
    }
  }
}

"This app uses the camera" isn't enough.

6. Android package rename breaks the build

The package name lives in app.json, build.gradle, AndroidManifest.xml, the Java/Kotlin source path, google-services.json, and OAuth redirect URIs. Miss one and you get a ClassNotFoundException on launch. On managed Expo, let the tooling regenerate:

rm -rf android
# set expo.android.package in app.json
bunx expo prebuild --clean

7. Android push says "ok" but nothing shows

Usual suspects: FCM credentials not configured in EAS, OEM battery optimization, no channel, or no Android 13+ permission. Cover the last two in code:

import * as Notifications from 'expo-notifications';
import { Platform } from 'react-native';

export async function setupAndroidPush() {
  if (Platform.OS !== 'android') return;
  await Notifications.setNotificationChannelAsync('default', {
    name: 'Default',
    importance: Notifications.AndroidImportance.HIGH,
  });
  const { status } = await Notifications.requestPermissionsAsync();
  if (status !== 'granted') console.warn('Push permission denied');
}

8. AI streaming stalls or drops tokens

React Native's default fetch doesn't do ReadableStream. Use expo/fetch:

import { fetch } from 'expo/fetch';

const res = await fetch(url, { method: 'POST', body, headers });
const reader = res.body!.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  onChunk(decoder.decode(value, { stream: true }));
}

9. Stripe webhook never reaches Supabase

Three causes: signing secret mismatch, JWT verification on (Stripe doesn't send a Supabase JWT), or pointing at a preview URL.

# supabase/config.toml
[functions.stripe-webhook]
verify_jwt = false

Then fire a test event before going live:

stripe trigger checkout.session.completed

10. Voice transcription feels slow on budget Android

Mostly hardware and network, not a bug. Chunk audio at shorter intervals (a few seconds, not ten), show a typing indicator, and fall back to a smaller model tier on older devices:

const model = isHighEndDevice ? config.fastModel : config.smallModel;

The takeaway

React Native the framework has stabilized. The pain is in the seams: build tooling, permissions, backends, push, AI providers, device quirks. If you're prioritizing what to learn this week:

eas.json and build profiles
Your backend's auth model (RLS if Supabase)
Env var propagation
A scripted cache reset
Apple's common rejection reasons

Which of these ten has cost you the most hours? Or is your worst one not on the list? Drop it in the comments. 👇

Build vs Buy a React Native Template: What Founders Miss

Chris F A — Wed, 23 Sep 2026 10:30:32 +0000

TL;DR

"Build vs buy" is the wrong framing. It's an engineering allocation problem, not a purity contest.
~80% of any mobile app is table stakes: auth, payments, push, RLS, EAS builds, nav. ~20% is your actual product.
Building the 80% yourself runs roughly 200 to 490 hours before you write one line of product code.
Most cheap templates are UI-only mood boards. That's why founders think templates are bad.
Buy a template with a real backend, clean patterns, and a sane license. Then spend your whole budget on the 20%.

You've already lost a week

Every week another founder pings me with: "Should we build our React Native app from scratch, or buy a template?"

Honestly? If you've argued about this in Slack for more than half a day, you're already losing. It's the last-mile cousin of "should we use TypeScript?" and "should we use a monorepo?": an obvious answer 90% of the time, dressed up like it deserves a design doc.

The pattern I see across dozens of pre-launch teams:

Founder writes a Notion doc: "custom stack vs. template"
Doc grows a comparison matrix
Co-founder pushes back on the matrix
Two weeks pass. Zero code shipped.
Someone just picks one and moves on

That pick is almost always right. The two weeks were pure sunk cost.

The 80/20 nobody tells you about

Founders overestimate how much of their app is actually theirs. Here's the 80%, written the way you'd actually scope it:

// The 80%: identical in basically every consumer/prosumer app
const tableStakes = [
  "auth: email + OAuth + Apple Sign-In",
  "password reset with deep-linked email tokens",
  "row-level security on every table",
  "push notifications: permission prompts + delivery receipts",
  "IAP and/or Stripe checkout",
  "offline-safe state + cache invalidation",
  "error boundaries, loading skeletons, empty states",
  "a11y labels + dynamic type",
  "EAS Build, code signing, TestFlight, Play Console",
  "OTA updates via expo-updates",
  "legal screens + refund flows",
];

// The 20%: the thing your pitch deck is actually about
const differentiator = "the AI pipeline / matchmaker / workout planner / marketplace mechanic";

"Build from scratch" = building both arrays on one budget. "Buy a template" = skipping the first array so the whole team chases the second. Stated that way, the choice is boring.

The real question is which template, and whether it actually gives you a real 80%. Most don't.

What building the 80% actually costs

Rough, illustrative numbers (not a benchmark) at $80/hr for a mid-market React Native dev:

Component	Optimistic hrs	Realistic hrs	At $80/hr
Auth (email + OAuth + Apple + reset)	40	90	$7,200
Supabase schema + RLS + migrations	30	70	$5,600
Push notifications (iOS + Android)	25	60	$4,800
Stripe + license grants	30	80	$6,400
Nav + deep links + tab bar patterns	20	50	$4,000
EAS Build + submission automation	15	40	$3,200
Design system + dark mode + a11y	40	100	$8,000
Total for the 80%	200	490	~$39,200

And "realistic" assumes a senior RN engineer who has already shipped push on production Android. Then there's the tail: Apple deprecates push cert formats, Supabase changes its auth SDK error shape, RN ships a new architecture. You own all of it. Forever.

What buying costs (when it goes wrong)

You grab a $59 marketplace template. Three weeks later you're ripping half of it out because:

It was UI-only. No backend, no auth, no data layer.
The license was ambiguous. Shipping it in a paid app costs extra.
Copy-paste patterns everywhere, so every feature multiplies tech debt.
React Navigation 5 with class components. In 2026. Two days of migration before feature one.
AI agents choke on it. Cursor and Claude Code can't extend inconsistent patterns.

That's why so many devs end up in the "just build it" camp. Not because building is smart, but because their first template was so bad that anything felt better.

Audit a template in 60 seconds

Before you trust a template (or your agent does), run this against the repo:

# 1. Is TypeScript actually strict?
grep -E '"strict":\s*true' tsconfig.json || echo "⚠️ not strict"

# 2. How many state libraries are fighting each other?
grep -oE '"(redux|@reduxjs/toolkit|zustand|@tanstack/react-query|mobx|jotai|recoil)"' package.json

# 3. Class components hiding in there?
grep -rl "extends React.Component" --include=*.tsx . | grep -v node_modules | wc -l

# 4. Is there a real backend, or just screens?
ls supabase/migrations 2>/dev/null || echo "⚠️ no migrations: probably UI-only"

# 5. Is the vendor alive?
git log -1 --format=%cr

One state library, strict TS, zero class components, real migrations, recent commits: your agent can work with that. Anything else and it'll fight you.

The comparison you should actually run

Forget "custom vs. template." Compare what's in the repo on day one:

	Build from scratch	Cheap UI template	ThemeForest-tier	Applighter template
First running app	2–6 weeks	3–7 days	3–7 days	Same afternoon
MVP (real backend + auth)	8–16 weeks	6–10 weeks	5–9 weeks	1–3 weeks
Backend included	You build it	❌	Occasionally	✅ Supabase (Postgres + RLS + edge functions)
Auth flows	You build them	Screens only	Screens only	✅ OAuth + Apple
AI pre-wired	❌	❌	❌	✅ Where relevant
Commercial license	You own it	Ambiguous	Per-app fees	✅ One-time, upgradeable
Agent-friendly	Depends	Rarely	Rarely	✅
Lifetime updates	You maintain	❌	❌	✅

Timelines are indicative ranges based on typical scope, not measured benchmarks.

The real delta isn't custom vs. template. It's templates that ship a product vs. templates that ship a mood board.

Where is your differentiator, really?

Product-shaped: AI pipeline, matching algorithm, workout logic, onboarding funnel. Most apps live here. Buy.
Infrastructure-shaped: novel native audio pipeline, custom protocol, on-device private ML, bespoke offline sync. Build, or fork hard.

Most founders who claim to be infrastructure-shaped aren't. Be honest.

Don't build from scratch if...

No senior RN engineer is on it full-time.
Your deadline is under eight weeks.
Your pitch is a screen mock, not a systems diagram.
You'd write auth, payments, and push anyway (0% of your moat).
Your AI agent will do most of the coding. Agents extend clean patterns; they flounder on greenfield sprawl.

Don't buy (or return it) if...

It's UI-only. That's a Figma export.
The license is ambiguous or per-app.
The code fights your agent.
The vendor is dead: no commits in a year.
You can't swap the backend or AI provider (GPT-4o → Claude, Whisper → Deepgram) without a rewrite.

What a good buy looks like

Concrete example: the AI Voice Notes template on Applighter ($79):

16+ screens in React Native + Expo, TypeScript everywhere
Supabase backend: schema, RLS, storage, edge functions
Recording → transcription → summarization, already wired
EAS Build config ready for TestFlight + Play Console
One commercial license, upgradeable to multi-app
Lifetime updates, no subscription, 7-day refund window

Whatever vendor you pick, the same three questions apply: real backend? holds up under an agent? license lets you succeed without punishing you?

The middle path: fork it

Buy, then fork aggressively. Rip out what you don't need, keep auth + Stripe + push + React Native nav patterns, and own the parts that matter. This is why license terms matter more than price: a $49 template you can legally fork beats a "free" one with restrictive terms.

Quick FAQ

Always cheaper to buy? For the 80%, yes, by a wide margin, if the template includes a real backend. UI-only templates save less than you think.

Can I customize it? On a good template, it's your code. On a bad one, customization = rewrite.

Does a template hurt acquisition value? No. Acquirers care about metrics and code quality, not code origin.

Swap the backend later? Ask before you buy. Modular templates let you swap Supabase ↔ Firebase or GPT-4o ↔ Claude without a rewrite.

Build vs buy is a symptom, not a decision. If you can name your differentiator in one sentence, you already have your answer.

So what's your 20%? Drop a comment with what you're building and whether you started from scratch or a template. 👇

Your Expo + Supabase Login Works. Now Restart the App.

Chris F A — Wed, 23 Sep 2026 10:03:18 +0000

TL;DR

supabase.auth.signInWithPassword "working" in Expo Go proves almost nothing. The failures live in session persistence, deep-link callbacks, token refresh, and standalone builds.
Supabase needs an explicit storage adapter on React Native, or the session never survives an app restart.
OAuth and magic-link callbacks that work in Expo Go silently break in a standalone build unless the redirect scheme is wired correctly.
autoRefreshToken won't fire while the app is backgrounded. You have to nudge it on AppState change or users get logged out mid-session.
Test auth on a real standalone build, not just Expo Go. The gap between them is where the bug reports come from.

You wired up signInWithPassword, the happy path works, the demo looks great. Then a user restarts the app and they're back on the login screen. Or they tap the magic link and land on a blank screen. Or they open the app after lunch and every request 401s.

Expo + Supabase auth is one of those stacks where the tutorial ends exactly where the real problems start. Here are the four that account for most of the "auth is broken" tickets, and the fix for each.

Gap 1: The session doesn't survive a restart

This is the first one everyone hits. Sign-in works, you close the app, reopen it, and the user is logged out. On the web, Supabase persists the session in localStorage automatically. React Native has no localStorage, so unless you hand Supabase a storage adapter, the session lives only in memory and dies with the process.

The fix is to pass an explicit storage implementation when you create the client:

import 'react-native-url-polyfill/auto';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { createClient } from '@supabase/supabase-js';

export const supabase = createClient(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY!,
  {
    auth: {
      storage: AsyncStorage,
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: false, // there's no URL to read on native
    },
  },
);

Three things in that config block matter and get missed:

storage: AsyncStorage is what actually persists the session across launches. Newer Expo setups use expo-sqlite's storage instead. Either works. The point is you must supply one.
detectSessionInUrl: false. The web client reads the session from a URL fragment after redirect. On iOS and Android there's no URL, so leave this off or the client waits on something that never arrives.
react-native-url-polyfill/auto at the very top. Supabase's SDK uses the URL API internally, and without the polyfill you get cryptic failures on some RN versions.

Gap 2: The magic-link / OAuth callback dies in a standalone build

Deep links are the second wall. Your email-link or OAuth flow works perfectly in Expo Go, you ship a standalone build, and tapping the link opens the app to a blank screen with no session.

The reason: Expo Go handles deep links through its own exp:// scheme. Your standalone build uses your app's own scheme, and Supabase has to be told to redirect there. Set your scheme in app.json:

{
  "expo": {
    "scheme": "myapp"
  }
}

Then build the redirect URL from that scheme and pass it into the auth call:

import * as Linking from 'expo-linking';

const redirectTo = Linking.createURL('auth/callback');

await supabase.auth.signInWithOtp({
  email,
  options: { emailRedirectTo: redirectTo },
});

And handle the callback when the link opens the app. The link carries the tokens in its fragment, and you feed them back to Supabase:

import * as Linking from 'expo-linking';
import { useEffect } from 'react';

function useAuthDeepLink() {
  useEffect(() => {
    const handle = async (url: string) => {
      const { params } = Linking.parse(url);
      if (params?.access_token && params?.refresh_token) {
        await supabase.auth.setSession({
          access_token: String(params.access_token),
          refresh_token: String(params.refresh_token),
        });
      }
    };

    const sub = Linking.addEventListener('url', ({ url }) => handle(url));
    Linking.getInitialURL().then((url) => url && handle(url)); // cold start
    return () => sub.remove();
  }, []);
}

The getInitialURL call is the part people forget. addEventListener only catches links that arrive while the app is already running. If the link cold-starts the app, you need getInitialURL or the very first tap silently does nothing.

Gap 3: The token expires while the app is backgrounded

autoRefreshToken: true sounds like it handles everything. It doesn't. The refresh timer only runs while the JS engine is active. When the app is backgrounded (which is most of the time), the timer is frozen. The user opens the app after an hour, the access token has expired, and the first request 401s before the refresh catches up.

Supabase's own guidance is to drive the refresh off AppState. Start and stop it as the app foregrounds and backgrounds:

import { AppState } from 'react-native';
import { supabase } from './supabase';

AppState.addEventListener('change', (state) => {
  if (state === 'active') {
    supabase.auth.startAutoRefresh();
  } else {
    supabase.auth.stopAutoRefresh();
  }
});

With this in place, the moment the app comes back to the foreground it refreshes the token before your screens fire their queries, and the 401-on-resume bug disappears.

Gap 4: You're testing in the wrong environment

Notice the pattern in the first three gaps: each one behaves differently in Expo Go than in a standalone build. That's the real trap. Expo Go is a shared sandbox with its own scheme, its own lifecycle handling, and forgiving defaults. Your production build has none of that.

So the rule is simple: auth is not "done" until you've tested sign-in, restart-survival, deep-link callback, and resume-after-an-hour on an actual dev-client or standalone build. Everything green in Expo Go is a necessary check, never a sufficient one.

A quick pre-ship checklist:

Sign in, force-quit, reopen. Still logged in?
Trigger a magic link / OAuth from a standalone build. Does the callback land a session?
Cold-start the app from the auth link. Does getInitialURL catch it?
Background the app past the token lifetime, reopen. Does the first request succeed?
Sign out. Is the session actually cleared from storage, not just from memory?

The boilerplate is the same every time

Here's the thing about all four of these: the fix is identical from app to app. The storage adapter, the scheme wiring, the deep-link handler, the AppState refresh loop. It's the same 80 lines whether you're building a fitness app or a marketplace, and it's exactly the kind of plumbing that's tedious to write and easy to get subtly wrong.

That's why a pre-built starter earns its place here. AppLighter's Expo + Supabase templates ship with this auth layer already wired: session persistence, deep-link callbacks, and the AppState refresh loop, tested on standalone builds. You start from a login flow that already survives a restart, instead of discovering gap 1 through a user complaint.

Whether you use a template or write it by hand, the checklist above is the same. Auth that works in the demo and auth that works after a restart are two different features.

Your turn

Which of these four bit you first? I'm betting it's the restart one. Drop a comment with the auth bug that cost you the most time, and what you're building.

The cold-start problem for paid React Native templates (our first 100 customers)

Chris F A — Mon, 21 Sep 2026 08:23:52 +0000

TL;DR

Cold-start = two overlapping asymmetries: no reviews to earn trust, no traffic to earn reviews
What worked, in order: long-tail SEO, community answers on Reddit, open-sourcing one small utility, cross-linking SKUs, a visible refund policy
What flopped: X threads, Product Hunt, paid ads (CAC ~$120 on a $79 product), YouTube
Brand search converted ~4x cold traffic, but only exists after months of the unglamorous stuff
First 20 sales took three months. The next 80 took two.

You can ship the cleanest Expo starter on the internet, wire Supabase RLS by the book, and set up Stripe webhooks that never miss, and still watch your dashboard sit at zero for weeks. Getting our first 100 customers for Applighter was less about the code and more about a small number of distribution bets made after the code stopped mattering.

Why "just make a good template" doesn't work

Every founder selling code has the same theory: if it's good enough, developers will find it. They won't. Two things are true about the buyer's mind at the same time:

A template is a risk purchase. A $79 template can burn $10,000 of engineering time if it's badly structured. Buyers want proof, not marketing copy.
They're drowning in options. ThemeForest lists thousands of React Native templates, mostly five-year-old Redux samples with no backend. The category has burned every buyer at least once.

So the buyer's default assumption is this is another one. Your entire job before the first sale is breaking that assumption for people who've never heard of you.

Week 1 starting position

Launch templates live: real, buildable Expo + Supabase apps
$79 per single-app license
Zero email list. Zero Twitter reach. Zero backlinks.
One landing page built in a weekend

Week 1 revenue: $0. Week 2: $79. Week 3: $158. This is not a "made $10K in 30 days" post.

What actually worked, ranked by attributed first sales

1. SEO on very specific long-tail queries

We didn't chase "react native template." We ranked for:

"React Native Supabase template with RLS and storage"
"Expo EAS build cost calculator"
"Streaming AI responses to React Native"

Low-hundreds monthly volume each. Nobody competes for them because they're too specific for big content teams. That's exactly why they convert: whoever searches that phrase has already decided to build the thing and wants the fastest way.

Our first 20 sales came from four blog posts in this category. Always the technical, specific, "we actually did this" posts. Never the "top 10 tips" ones.

The mechanism: specific Google query → post that solves it → "oh, they sell a template that already implements this" → click. Not glamorous. Very reliable.

2. Building in public in the right communities

Reddit was our second-biggest channel. But not r/reactnative: we got flagged as promotional twice there. What worked:

Answering questions in r/expo with real technical answers that referenced our template as one of the options
Long "here's how I built this" posts in r/indiehackers and r/SideProject
Answering bug threads on r/Supabase where our stack overlapped

Rule learned the hard way: you can promote in a comment if you gave three comments of pure help first. Reddit's spam detection, human and algorithmic, is very good at spotting drive-bys.

3. Buying trust with a small open-source release

We open-sourced one piece of infrastructure: a Supabase migration generator plus the license-grant edge function pattern we use with Stripe. Went nowhere on GitHub in isolation. But it:

Gave buyers a real GitHub org to click through and see we exist
Turned into two Indie Hackers threads and one Hacker News mention (front page ~3 hours)

The HN mention alone drove three same-day sales and got us indexed for terms we didn't otherwise rank for.

4. Cross-linking SKUs

Each template page links to the others in a "you might also want" section. When one template started ranking, it dragged the adjacent ones up with it: same buyer intent, same domain authority pool. If you only have one product you can't do this, but it's a reason to build three related SKUs once the first one ships.

5. The refund policy is a sales tool

7-day, no-questions-asked, displayed on the pricing card, not buried in the footer. Refund rate to date: 3.1%. Conversion lifted noticeably when the badge became visible. Buyers of a $79 template are risk-buying; a visible refund is the cheapest possible risk reducer.

What flopped

Channel	Result	Why we stopped
Twitter/X threads	~150 impressions, ~0 clicks	Reach without buyer intent
Product Hunt	~40 upvotes, 2 sales	One-day spike, no compounding
Paid Google Ads	CAC ~$120 on a $79 product	Terrible unit economics
LinkedIn posts	3 sales	Not repeatable, worst noise ratio
YouTube tutorial	200 views in 3 months	Production time too high for this stage

Pattern: paid + broad intent loses at this price point. Organic + specific intent wins.

Month-6 funnel numbers

Channel	Sessions	Conv. rate	Sales
Long-tail SEO (blog)	4,200	0.9%	38
Direct + brand search	1,100	3.4%	37
Reddit referral	380	1.3%	5
Hacker News (one-off)	2,100	0.14%	3
Twitter/X	90	1.1%	1
Paid	40	0%	0

Two takeaways:

Long-tail SEO wins on volume despite mediocre conversion, once you have 10+ ranked posts.
Brand search converts ~4x, but it only exists as the compounding return on everything else.

You can't buy your way to that mix. You write your way to it.

What we sell against

For context on positioning (this is what breaks the "just another UI kit" objection): full React Native + Expo source on a current SDK, complete Supabase backend with schema/RLS/storage/edge functions, working AI integrations with real API contracts, Stripe-powered license grants that provision the repo on payment, NativeWind + TypeScript throughout. The full catalog is at Applighter if you want to see how the pages are structured; steal whatever works.

A typical ThemeForest listing is UI screens, mocked data, no backend, unclear licensing. Beating that bar is easy on paper and hard in practice, because your first buyers have no way of knowing you're different.

The checklist if we started over

Ship one template. Not a catalog. One, undeniably good.
Write four blog posts about specific problems it solves, like "streaming OpenAI responses in Expo without dropping frames."
Analytics before launch. Search Console, a privacy-respecting analytics tool, a UTM convention.
Open-source one small utility. Your credibility artifact.
Show up in 2-3 communities regularly. Not in bursts. Get known before you sell.
Visible refund policy on the pricing card.
Wait. SEO compounds at month 3-6. Quitting at month 2 because "nothing is working" is where most people lose.

What cold-start really means

It's not that you have no customers. It's that you have no evidence: no reviews, no case studies, no referrals, no rank. Every channel that scales in month 12 requires evidence that doesn't exist in month 1. The whole game of the first 100 sales is building evidence faster than your runway burns. Everything else is downstream.

Anyone else selling dev tools or templates as an indie? What was your first channel that actually produced a sale (not impressions, a sale)? Drop it below. I'll trade notes on anything we tried.

AI features in mobile apps: 4 patterns that ship

Chris F A — Fri, 18 Sep 2026 14:19:44 +0000

TL;DR

Almost every AI feature shipping in mobile apps is one of four patterns: text-in/text-out, voice-in/text-out, vision-in/structured-out, or retrieval over the user's own content.
Everything else (multi-agent orchestration, autonomous browsing, on-device frontier models, real-time voice) is still a science project on mobile in 2026.
If a feature request doesn't map to one of the four, it's probably not ready to ship.
Ship one pattern deeply instead of four badly.

Most AI features in mobile apps collapse into four patterns. Not forty. Four. Strip away the marketing pages and the LinkedIn threads about "AI-first paradigm shifts," and what's actually shipping in production React Native, Swift, and Kotlin apps is a very small, very boring set of shapes. Every one of them has been solved. None of them require an autonomous multi-agent framework.

Why the taxonomy matters

Founders and PMs describe AI features in terms of what the user sees: "the app understands my meals," "the app writes my notes for me." Engineers have to build in terms of what the model actually does. It takes input tokens of some modality, emits output tokens of some modality, sometimes conditioned on retrieved context.

When you translate a product ask into one of the four patterns below, three good things happen:

You know which API to call (transcription, chat, embeddings, vision).
You know the latency budget you're working with.
You know whether it'll actually work at all with today's models.

If you can't map a feature request onto one of these four, that's usually a signal the feature isn't ready to ship, not a signal you need a more sophisticated architecture.

Pattern 1: Text-in, text-out

What it is: the user types (or the app produces) text; the model returns text. Chat, summarization, rewriting, translation, tone-adjustment, "explain this like I'm five."

Lowest engineering cost, highest UX ceiling. Which is why every consumer app now has some flavor of it, and why most of them feel forgettable. The wins live in the small stuff: streaming so the first token appears in under 400ms, keeping the input responsive during generation, and handling network drops without losing the partial response.

React Native hazards specifically:

Streaming over fetch on iOS is painful. The default fetch doesn't stream response bodies on Hermes reliably. Use expo-fetch or an SSE library.
Keyboard behavior. KeyboardAvoidingView fights with a growing message list. Pin the input to the bottom of the safe area and animate the message list instead.
Cost per DAU adds up fast. A chatty user at Claude Sonnet or GPT-4o quality is $0.10–$0.40 per day. Cache aggressively; use a cheaper model for the first turn.

Pattern 2: Voice-in, text-out

What it is: the user speaks; the app returns a transcript, and (usually) a summary, action items, or a structured extract.

The transcription half is solved. Whisper on OpenAI, Deepgram Nova, AssemblyAI Universal: all three produce production-quality transcripts of 30–60 second clips for well under a cent. The interesting engineering is the second half. Taking a 4,000-word verbatim transcript and returning something a human actually wants to look at.

The pipeline that ships:

Record audio locally with expo-av (or react-native-audio-recorder-player on bare RN).
On stop, POST the file to your backend.
Backend calls the transcription API, gets back the transcript.
Backend passes the transcript to an LLM with a structured-output prompt: { "summary": string, "action_items": string[], "key_decisions": string[] }.
Backend saves both the raw transcript and the structured extract.
Client fetches the structured extract when the recording detail screen opens.

That's the entire pipeline. Boring on purpose. Every "smart voice notes" app in the store is doing this. The differentiation is in the summary prompt, the UI for surfacing action items, and how graceful the recording UX feels during long meetings. If you want the client side already wired up (recording screen, waveform, processing states, transcript/summary/actions tabs), the AI Voice Notes template ships exactly that with a pluggable transcription seam.

Pattern 3: Vision-in, structured-out

What it is: the user takes a photo; the app extracts structured data from it. Meal → macros. Receipt → line items. Whiteboard → text. Business card → contact.

This is the under-appreciated one. GPT-4o and Claude Sonnet both accept image inputs and can be prompted to return strict JSON. A single API call replaces what used to require a tesseract OCR pipeline plus a NER model plus a lot of regex.

The shape of the call:

const response = await claude.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  messages: [{
    role: "user",
    content: [
      { type: "image", source: { type: "base64", media_type: "image/jpeg", data: base64 } },
      { type: "text", text: "Extract every line item from this receipt. Return strict JSON matching the schema: { items: [{ name: string, price_cents: integer, quantity: integer }] }" },
    ],
  }],
});

The gotchas are all on the input side:

Compress before upload. A raw iPhone photo is 4MB. The model doesn't need it. Resize to 1568px longest side, JPEG quality 0.7. That's ~200KB and the vision quality is indistinguishable.
Validate the JSON. Sonnet and GPT-4o will occasionally emit valid-looking JSON with the wrong keys. Parse with Zod and retry once if it fails.
Latency budget is real. A single vision call is 3–8 seconds. Show a "reading your photo" progress state; don't lie with a fake spinner.

This is the pattern that most obviously doesn't need on-device inference. Frontier vision quality beats every on-device option by so much that the round-trip is worth it.

Pattern 4: Retrieval-augmented anything

What it is: the user asks a question; the app finds the semantically relevant chunks of their own content and passes them to a model along with the query.

Most often mis-implemented, because two very different things get called "RAG":

Full-doc-in-context: shove a 20-page PDF into a 200K-context Claude call along with the question. Zero infrastructure. This is what most "chat with PDF" apps actually do.
True retrieval: hundreds or thousands of documents, so you chunk, embed, store vectors, and retrieve top-k at query time.

You want #1 until the user's corpus outgrows a single context window. Don't build pgvector-backed retrieval on day one for an app whose users have three documents.

When you do need true retrieval:

Embeddings: OpenAI text-embedding-3-small (1536 dims, ~$0.02 per million tokens) or Voyage voyage-3 for higher quality.
Storage: Supabase's pgvector extension, a single Postgres column, indexed with HNSW, queryable with cosine similarity in normal SQL.
Chunking: 500–800 token chunks with 100 token overlap, one embedding per chunk plus a foreign key to the source document.
Retrieval: top-8, then rerank with a cross-encoder if quality matters.

The mobile client doesn't need to know any of this. From RN's perspective it's still POST /api/chat with a message.

The four patterns compared

Pattern	Typical latency	Cost per request	On-device viable?	Where it breaks
Text-in / text-out	200ms–3s (streaming)	$0.001–$0.05	Only tiny 1–3B models on flagships	Streaming on Hermes; keyboard UX
Voice-in / text-out	2s–15s	$0.006/min + LLM	Whisper Tiny for short clips	Long-audio memory; iOS background recording
Vision-in / structured-out	3s–8s	$0.01–$0.05 per image	Not at frontier quality	JSON schema drift; slow uploads
Retrieval	500ms–4s	$0.001 per query	Embeddings yes; retrieval cloud	Chunking; stale embeddings

What doesn't ship (yet)

An honest list of patterns that keep showing up in pitch decks and don't survive contact with a shipping mobile app in 2026:

Multi-agent orchestration inside the app. A LangGraph-style DAG of five agents debating each other is fun in a notebook and a debugging nightmare on a phone. Ship a single call with a good prompt first.
Autonomous browsing agents. "Book me a flight" works in demos and falls apart the moment a real airline site loads a captcha. Mobile isn't the platform to prove this out.
On-device frontier-quality models. Gemini Nano and Apple Intelligence exist. They don't match Sonnet or GPT-4o. Ship cloud, add on-device later as a latency/privacy optimization.
Real-time interruptible voice conversation. The APIs are technically usable, but the mobile plumbing (WebRTC, background audio, Bluetooth switching) is where 80% of the work lives.

None of these are bad ideas. But if your roadmap depends on any of them working right now in an app launching next quarter, you're setting engineering up to fail.

FAQ

Q: Do I need to fine-tune?
Almost never in 2026. A well-written system prompt plus structured output constraints (JSON schema, Zod validation, retry on failure) gets you to production quality for all four patterns. Fine-tune only when you have thousands of high-quality examples and frontier models still fail on your task.

Q: Client or server inference?
Server, by default. On-device is worth it only for very latency- or privacy-sensitive flows, usually a subset of pattern 1.

Q: What do these cost per user?
Rough 2026 numbers per DAU: chat $0.05–$0.40; voice notes $0.02–$0.15; vision extraction $0.01–$0.10 per photo; retrieval $0.001–$0.01 per query. Cache aggressively and pick the smallest model that clears your quality bar.

Q: What about TensorFlow Lite and friends?
Useful for non-LLM tasks: image classification, pose estimation, wake-word detection, offline OCR. They complement the four cloud-LLM patterns; they don't replace them.

Ship one pattern well, not four badly

Every pattern above has a full quarter of UX work behind it: good recording state, good streaming, good empty states, good failure modes. Pick the one that actually solves your user's problem. Ship it deeply. Add the second in v2.

Which of the four are you building right now, and what's the ugliest part so far? Drop a comment.

How to Ship a React Native App in Days, Not Months

Chris F A — Fri, 11 Sep 2026 13:23:47 +0000

TL;DR

Tracking 30 indie devs put the median at 11 weeks from expo init to App Store, with ~4 weeks spent on plumbing: auth, RLS, billing, dark mode, EAS credentials.
Kill the plumbing tax and "ship in days" stops being a slogan. Six patterns do it: one-hex theming, RLS in the migrations, atomic Stripe flows, four-state auth, provider-agnostic AI scaffolds, and a single template registry.
The realistic week: day 1 rebrand, day 2 point at your Supabase, day 3 swap screens, day 4 test payments, day 5 EAS build and submit.

You can ship a React Native app in days. Not with vibes, not with an AI agent that hallucinates a schema, and not by writing a screen a night for six months. You ship in days when the boring, load-bearing parts (auth, RLS, Stripe, theming, App Store config) are already done, and your only remaining job is the 20% that actually makes your product yours. This post is the honest breakdown of the patterns that make that real, from building the Applighter template library.

Why "days, not months" isn't marketing hype

We ran the numbers on this one before we wrote it. Tracking 30 indie devs put the median at 11 weeks from expo init to App Store, with 4 of those weeks spent on plumbing that has nothing to do with the product idea. Auth. Push notifications. Subscription billing. Dark mode. Row-Level Security policies. Icon and splash screen generation. EAS credentials. None of it is hard. All of it takes a week each if you've never done it, and 2–3 days each even if you have.

That 4-week plumbing tax is the difference between "ship in days" and "ship in months." Kill the tax and you're left with the fun part. Here are the six patterns that kill it. Whether you buy a template or build these yourself, this is the checklist.

Pattern 1: One-hex-code theming

The single most demoralising afternoon of a template purchase is the one where you realise the "customisation" is a search-and-replace across 47 files, and one of them is a hard-coded gradient you can't find without the design tool that made it.

The fix: theme everything through one file. One function, applyProductTheme(primaryColor), converts a single hex string to HSL, injects the CSS variables (--primary, --ring, --accent), and lets Tailwind opacity utilities like bg-primary/10 resolve automatically. A theme provider wraps the tree so nothing in the app hard-codes a colour.

The practical effect: swap one string, refresh, and the whole app is rebranded, including buttons, badges, shadows, and gradient stops. It's not novel (shadcn has trained the ecosystem on the pattern) but it takes discipline to keep it out of individual screens. Audit for it.

Pattern 2: RLS baked into the migrations, not bolted on later

Row-Level Security is the thing most indie React Native apps get wrong. They ship with the anon key in the client (fine), then discover in month three that the anon key can read every user's data, because the tables were created with ENABLE ROW LEVEL SECURITY never called and no policies attached.

Ship policies as first-class citizens in supabase/migrations/. A representative example from a support-requests table:

ALTER TABLE public.support_requests ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can create support requests"
  ON public.support_requests FOR INSERT
  TO authenticated WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Users can view own support requests"
  ON public.support_requests FOR SELECT
  TO authenticated USING (auth.uid() = user_id);

Two things matter here. First, RLS is turned on in the same migration that creates the table: you can't forget. Second, the policies are written the boring, correct way (auth.uid() = user_id) with no clever exceptions that break under concurrency. It's the reason Supabase's RLS docs exist, and it's the pattern that survives audits.

If you're rolling your own, budget three days for a security-tight RLS pass on a five-table schema. Starting from a template that has it means zero days, on a schema someone else has already been paged over.

Pattern 3: Stripe checkout, webhook, and license grants as one atomic flow

Payments are the second most common place where indie apps fall over. Not because Stripe is hard (the webhook docs are excellent) but because you have to be idempotent, you have to handle guest checkout, you have to grant access on checkout.session.completed, and you have to notify yourself when it fires. All at once. All correct.

Our checkout flow lives in three files, and the shape is worth stealing even if you build it yourself:

app/api/checkout/route.ts validates the product, checks for duplicate ownership, short-circuits free products, and records attribution before handing off to Stripe.
app/api/webhook/stripe/route.ts verifies the signature, creates a guest user if needed, records the transaction, fans out access grants, sends the purchase email, pings Slack, and forwards a Meta Conversions API event. All keyed off stripe_session_id for idempotency.
app/api/download/[productId]/route.ts gates the download on a valid grant and streams a versioned zip back.

Every edge case has hit this flow at least once: guest checkout with a typo'd email, Stripe retry storms, cross-device grants. If you're selling subscriptions instead of one-time purchases, react-native-purchases is drop-in for the same reason.

Pattern 4: Auth flows that already handle the four bad states

Every real app has to handle: signed-out, signed-in, session-expiring-mid-request, and signed-in-but-email-unverified. Most tutorials handle two of them. Handle all four, with OTP, magic link, and Apple/Google Sign-In pre-wired.

The client/server key split that keeps you out of trouble:

modules/db/supabaseClient.ts uses the anon key, called from client components and screens. This is what almost every query in the app touches.
modules/db/supabaseServer.ts uses the service-role key, called from API routes and server actions only. This is the key you never, ever bundle into the mobile client.

A significant amount of our internal review time goes into making sure new templates don't accidentally import from supabaseServer in a screen file. Be equally paranoid.

Pattern 5: AI feature scaffolds you can point at any provider

Three AI template shapes solve the same annoying scaffolding problem three different ways:

The transcription UI (waveform, recording state, retry-on-network-loss) is real work you can't LLM your way out of.
The streaming chat interface (auto-scroll, cancel, retry, code-block rendering) has a pile of subtle bugs waiting for you if you build it from scratch.
Image-to-structured-data (photo to parsed nutrition JSON) needs a validation layer or your users see hallucinated 2,400-calorie apples.

Each scaffold is provider-agnostic. Swap the OPENAI_API_KEY for an Anthropic or Groq key, change one client, done.

Pattern 6: A single template registry so nothing drifts

Less glamorous, but it's why a multi-template library stays maintainable. Every template is registered in app/apps/config/index.ts and each has a config file (e.g. app/apps/config/ai-voice-notes.config.ts) that exports a ProductData shape: features, stats, tech stack, FAQ, testimonials, pricing, screenshots.

That config drives the product page, the OG image, the download endpoint, and the checkout SKU. Adding a new template means one config file and one migrations folder; everything else is inferred. The customer-facing benefit: every template feels like it was built by the same team, because the primitives are literally the same files.

The comparison table

Task	From scratch	AI-only (Cursor/Copilot)	Generic RN boilerplate	Full app template
Auth (email + OAuth + OTP)	5–7 days	2–3 days + edge-case debugging	2–3 days	0 days
Supabase schema + RLS	3–5 days	1–2 days (often insecure)	1–2 days	0 days
Stripe checkout + webhook + grant	4–6 days	3–4 days (often non-idempotent)	2–3 days	0 days
Theming / dark mode	2–3 days	1–2 days	1 day	30 minutes
App Store + EAS config	2–4 days	1–2 days	1–2 days	0 days
Push notifications	2–3 days	1–2 days	1 day	0 days
Product-specific feature work	Whatever's left of your month	Whatever's left of your month	Same	Your entire week

Competitors in this space are worth naming honestly. Ship Mobile Fast and Ship React Native both ship in the same ballpark of "AI wrapper boilerplate + auth + payments." The difference with Applighter is whole, production-shaped apps (Fitness, Taxi Booking, E-Learning, Chat with PDF) rather than a single starter you fork per project. If you're building a "wrapper" app, either of the two is a fine choice. If you want to start from something already recognisable as an App Store submission, that's what the full-app approach is for.

What "days" actually means, day by day

The concrete week I've watched customers run more than once:

Day 1: Buy, download, pnpm install, run on simulator, apply one hex code for your brand.
Day 2: Point SUPABASE_URL / SUPABASE_ANON_KEY at your own project, run migrations, verify auth works with your credentials.
Day 3: Rip out the one screen you don't need, add the one screen your idea does need, wire the copy.
Day 4: Add your Stripe test keys, run a full purchase, download, and in-app-unlock loop.
Day 5: App Store screenshots, EAS build, submit for review. TestFlight tomorrow.

Five days. Not because templates are magic, but because the four-week plumbing tax is already paid. What's left is the actual product decision, and that's the part you shouldn't shortcut.

FAQ

Can I really ship a real, App-Store-quality app in a week?
Yes, if the app you're shipping is close in shape to an existing template and you have a moderate React Native background. If nothing covers your idea or you're new to Expo, budget 2–3 weeks. Still an order of magnitude faster than from scratch.

What if my backend isn't Supabase?
Keep the DB layer behind a small module (modules/db/). Swapping to Firebase, Convex, or a REST API you already own becomes a day of work rather than a rewrite.

Do templates work with the current Expo SDK?
The Expo release cycle is well-communicated enough that tracking it is a scheduled task, not fire drills. We update within a week of each SDK release.

Is this lock-in?
The code is yours the moment you download. Full source, unencrypted, unminified. Ripping out the theming layer in month three is a normal refactor, no different from any other codebase.

What's the plumbing task that ate the most of your last app: auth, RLS, payments, or EAS credentials? Drop a comment. Curious what the community's tax actually looks like.

Local Dev Without Docker: A 2026 Look at the Alternatives (and When They're Actually Better)

Chris F A — Wed, 09 Sep 2026 13:37:44 +0000

Run docker stats on a typical full-stack laptop in 2026 and you'll see something like this:

NAME              CPU %     MEM USAGE / LIMIT     MEM %
supabase-db       2.3%      680 MiB / 15.9 GiB    4.2%
supabase-auth     0.5%      130 MiB / 15.9 GiB    0.8%
supabase-storage  0.3%      95 MiB / 15.9 GiB     0.6%
... 9 more containers ...

Add it up and a full local Supabase stack idles somewhere around 1.5 GB of RAM before you write a single line of application code. On an M-series MacBook with memory to spare, fine. On a 16 GB work laptop already running an IDE, Slack, a browser, and DevTools, it's not.

Docker isn't wrong. It's just often overkill for local development, and the ecosystem has quietly grown alternatives worth reaching for.

The three real reasons Docker is still the right answer

Before dumping Docker, be honest about the cases where it's the correct choice:

You genuinely need production parity. Your prod runs in Kubernetes; you want the same image locally to catch container-config bugs. Fair.
You're building tools that ship as containers. Docker locally is the SDLC.
You need process isolation with real network boundaries. Testing service-mesh routing, sidecar patterns, and similar.

Everything else (a Postgres plus Redis for your Next.js app, a local dev database for your side project, a Postgres to run migrations against) doesn't need Docker's isolation guarantees.

Alternative 1: Native installs

The most underrated 2026 answer:

brew install postgresql@17 redis
brew services start postgresql@17

Fastest boot: no container startup overhead, Postgres is up in a couple of seconds.
Lowest RAM: an idle native Postgres sits in the tens of megabytes, versus the full containerized backend stack measured in gigabytes.
Native OS integration: starts on login via brew services, no daemon in between.

The downside: you get exactly one Postgres version at a time. If you juggle multiple projects on different Postgres majors, this gets awkward. Which is what the tools in Alternative 3 exist for.

Alternative 2: Single-binary embeds

A newer category: databases and services shipped as single executables.

SQLite has been doing this forever. sqlite3 my.db is a few megabytes and zero config.
PGlite compiles Postgres to WASM: roughly 30 MB, runs in Node or the browser. Great for tests and prototypes.
Tinbase bundles real Postgres 17 plus auth, realtime, and edge functions into a single executable (58 MB binary, about 92 MB installed). MIT-licensed, works with the supabase-js SDK unchanged, no Docker daemon required.

The value isn't the binary size. It's that a single file is trivially reproducible across a team: download one executable and you're running. No docker-compose.yml drift, no daemon, no port fights with someone else's Postgres container.

Alternative 3: Micro-runtimes (Nix, mise, devbox)

The reproducible-environment problem Docker mostly solved for backend, tools like Nix, mise, and devbox solve for local dev without containerization:

Nix flakes: declarative, exact-version pinning of Postgres, Node, whatever. Steep learning curve, rock-solid results.
mise: simpler, per-project .mise.toml for language versions and tools.
devbox: Nix underneath with a friendlier UX.

You still run the binaries natively (no container overhead) but with the reproducibility Docker was hired for.

Comparing on metrics that matter

For a local dev environment running Postgres plus auth plus realtime for a small app:

Approach	RAM idle	Cold start	Team reproducibility
Docker Compose (Supabase local)	gigabyte-class	tens of seconds	High (docker-compose.yml)
Brew install (Postgres alone)	tens of MB	seconds	Low (manual setup)
Single-binary Postgres runtime	~100 MB-class	seconds	High (one file, one checksum)
Nix + native Postgres	tens of MB	seconds	High (flake.nix)

The Docker column isn't wrong, and it wins on "everyone already knows it." But it's paying for reproducibility with more than a gigabyte of RAM that the alternatives deliver for a fraction of that.

Worked example: replacing a Supabase docker-compose

The typical Supabase local setup is a dozen containers. A replacement that keeps the ergonomics (Postgres, supabase-js compatibility, auth, realtime) but ships as one file:

# Before: docker-compose up --wait   (a dozen containers, gigabyte-class RAM)
# After:  ./tinbase                  (one process, under 100 MB)

Your app code doesn't change. It's the same supabase-js SDK, pointed at the local URL Tinbase prints on startup:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'http://localhost:PORT',   // from tinbase startup output
  'ANON_KEY'                 // also printed on startup
)

The SDK doesn't know the difference. Your app code stays identical. Your laptop gets a gigabyte-plus of RAM back.

Closing: pick the runtime that fits the workload

"Docker-first for everything" was a 2018 answer. In 2026, the answer is "pick the runtime that fits the workload." Prod-parity work: Docker. Local backing services: native or single-binary. Bespoke tools: whatever ships fastest.

None of the alternatives obsolete Docker. They just recover the RAM and startup time you were paying for reproducibility you weren't actually cashing in.

What does your local stack look like in 2026: still docker-compose, fully native, or something in between? Drop your setup in the comments, especially if you've replaced a heavy compose file with something smaller.

We open-sourced our React Native template engine (but not the part that makes money)

Chris F A — Wed, 09 Sep 2026 13:19:52 +0000

TL;DR

We open-sourced our theme engine, ProductData config schema, UI primitives, and docs
We kept the Stripe webhook, license-grant fan-out, entitlement migrations, and admin routes private, permanently
The rule: code that answers a design question goes public; code that answers an entitlement question stays private
Three questions decided every file: would a competitor win by copying it, is it interesting to customers, and is it the piece the payment guards

We open-sourced parts of our React Native template engine last month. Not all of it. This post is the specific breakdown of what went over the wall, what stayed inside, and how we decided.

Why we split it at all

We sell React Native app templates: Expo + Supabase + NativeWind, full source, one-time payment. Every template ships with its own storefront page: hero, feature grid, screenshot carousel, pricing card, FAQ. Each one gets a themed page with its own primary color, its own screens, its own copy.

Two years ago that meant near-duplicate Next.js pages with hardcoded colors. Then we built a config-driven system. Then customers asked us how it worked. Then we realized the interesting part (the "how") wasn't the part making us money. The part making us money was the license grant that lets someone download a ZIP after a Stripe checkout succeeds.

So we drew a line.

What we open-sourced

1. The ProductData contract. Every template is described by a single TypeScript interface in app/apps/lib/data/types.ts. Screenshots, features, pricing tiers, tech stack, testimonials, FAQs: all of it. Adding a new template is one config file plus one registry line:

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,
};

There's nothing proprietary about that pattern; half the marketing sites on the internet do a version of it. Making the schema public means anyone building a catalog site has a reference implementation.

2. The runtime theme engine. Each template has its own primary color. We used to ship a Tailwind class per template. Now the primary color is a hex string on the ProductData object, and app/apps/lib/theme.ts converts it to HSL at runtime and injects it into CSS custom properties that Tailwind reads through color-mix():

Every bg-primary/10 variant Just Works, per template, without generating extra CSS at build time. Small, self-contained, zero business logic. Full public.

3. The docs. Installation, environment setup, folder structure, Supabase integration, Expo integration, UI component guide. Public since day one. If you're evaluating a template and you can't read the docs before paying, you're going to buy something else. The docs are the sales pitch.

What stayed proprietary

Four categories, in rough order of "how loudly we'd shout if this leaked."

1. The license-grant fan-out. When someone buys a template, app/api/webhook/stripe/route.ts receives a checkout.session.completed event and calls into lib/grants.ts. That module's job is fan-out: single template purchase → one grant row. Bundle purchase → resolveGrantTargets() walks the bundle_items table and writes a grant per member template. The free-claim path goes through the same code, which is the whole point: one function, two entry points, no drift.

This is not code you can safely publish. It decides whether an authenticated user is allowed to hit the download endpoint. Every line is a lever an attacker could poke at.

2. The entitlement migrations. user_product_grants, product_licenses, bundle_items, template_screens: the RLS policies, columns, and constraints. The generic Supabase-auth-RLS-storage pattern is documented publicly on our blog; the specific schema that says "this user owns this template" is not. Publishing it would give any adversary a map of exactly what to try to bypass.

3. Partner integrations. A content-provider webhook, an internal Slack service, an affiliate webhook, and a partner API behind bearer-token auth and signature verification. None of this is code anyone else could use; it's glue between us and named counterparties, plus the credentials to talk to them.

4. Admin routes. Impersonation, template request triage, support queue management. Nothing clever in here. It's a bunch of if (!isAdmin) return 403 and DB reads. But "boring code that enforces boundaries" is exactly the code you don't publish, because the moment it becomes interesting is the moment someone finds a hole in it.

The comparison

Three template projects, three different splits:

Project	What's public	What's private	Business model
Applighter (open-core hybrid)	Theme engine, `ProductData` schema, UI primitives, docs	Stripe webhook, license grants, RLS schema, admin, partner APIs	One-time template sales; access gated by Stripe
Ignite (fully open)	Everything: CLI, generators, boilerplate	Nothing	Agency lead-gen; you pay for their consulting
Shipnative (fully closed)	Marketing site only	The whole boilerplate + updates	Subscription for source + updates

None of these are wrong. For Ignite, the boilerplate is a marketing loss-leader for the agency behind it. For Shipnative, the boilerplate is the product, and every leaked copy is a lost subscription. For us, the templates are the product, but the engine around them is just how we render marketing pages. It doesn't need to be secret to protect revenue. The Stripe webhook does.

The three questions we asked

Question 1: If a competitor copied this line-for-line, would they win?

Nobody wins by copying our theme engine. There are ten thousand hex-to-HSL converters on npm. The moat is the templates themselves, plus everything that surrounds them (documentation, discoverability, support, updates).

But if someone copied our grant fan-out, including the SQL constraints on user_product_grants, they'd have an exact map of how our entitlement checks work. That's not a competitive edge for them; it's an attack surface for us.

Question 2: Is this code interesting to future customers, or only to us?

The ProductData schema is genuinely interesting. A prospective customer reading a config file learns something about how we think about product data. That's a positive signal in a purchase decision.

The internal Slack service that posts "$29 sale from user X" to a channel is not interesting to anyone but us. Publishing it doesn't help customers evaluate the product. Keeping it private doesn't hurt them.

Question 3: Is this the piece the payment guards?

The tie-breaker. Anything that sits on the "you paid, therefore you get" edge stays private. Everything else is negotiable. The moment a file is part of the license-check chain, it stops being open-source-eligible.

What this means if you're buying a template

You can read the config for any template in the Applighter catalog before you buy. You can read the docs. You can see how the theme engine renders the color you'll get. Nothing about the sales page is a mystery.

What you buy is different: the full source of a template. Screens, hooks, Expo Router config, the Supabase schema for that template's features, EAS build config. The actual ZIP behind the paywall is what you're paying for. The engine that renders the storefront isn't.

What it means if you're building something similar

Publish everything that answers a design question ("how does the theme work?", "what's the config shape?"). Those are marketing assets.
Keep private everything that answers an entitlement question ("is this user allowed to download this file?"). Those are business assets.
The line is not "clever code" vs "boring code." Some of your most valuable-to-protect code is boring: a fifty-line handler that decides who can access what.
Don't split "for optics." If you can't articulate why a specific file is private, publish it.

Nobody's business model is protected by hiding UI code, but plenty of businesses are protected by hiding the code that guards their payment surface. Get honest about which is which and the split writes itself.

What's next

A public applighter/theme-engine package on npm, standalone, MIT-licensed, zero dependencies except a peer on Tailwind
A CLI scaffolder (npx create-applighter-app <template-slug>) for the free templates
Publishing the ProductData interface as its own package

None of that changes the split. The public parts are the parts that were never protecting anything. The private parts are the parts that are.

If you've drawn (or dodged) a similar open/closed line in your own product, drop a comment: what did you publish, and what would you never?

Docker Alternatives for Local Postgres Dev: A 2026 Comparison

Chris F A — Mon, 07 Sep 2026 13:48:19 +0000

TL;DR

Podman and Colima swap the Docker licensing/host layer but you still run 12 containers, so RAM barely moves
PGlite is tiny but you lose the Supabase SDK and have to build your own auth
A single-binary Supabase-compatible backend cut my local stack from ~1.6 GB to ~100 MB with the SDK unchanged
Docker still wins for prod parity; the question is whether local dev is where you need it

The test setup

One project, five backends. The app: Next.js, 12 tables, auth, one realtime subscription. The machine: a 16 GB Apple Silicon laptop, which is what a huge share of indie devs are actually working on. For each approach I looked at steady-state RAM, cold boot, and whether my app code needed changes.

My numbers are from my machine and my project. Yours will differ; the ratios probably won't.

Approach 1: Docker Compose + Supabase (baseline)

The documented path. supabase start brings up 12 containers: Postgres, PostgREST, GoTrue, Realtime, Storage, Kong, Studio, and friends.

supabase start
docker stats --no-stream

On my machine that stack idled around 1.6 GB of RAM, with cold boots taking the better part of a minute. App code: works out of the box, obviously. This is the reference everything else gets measured against.

Approach 2: Podman + Supabase

Podman is a daemonless, open-source container engine and the go-to answer to Docker Desktop licensing.

podman machine init --memory 4096
podman machine start

The swap is real for licensing and rootless security. It is not a RAM story: you are still running the same 12 containers with the same runtimes inside a Linux VM. My steady-state numbers were in the same band as Docker. Pick Podman because of licensing or philosophy, not because your fans are loud.

Approach 3: Colima + Supabase

Colima replaces the Docker Desktop VM with a leaner Lima-based one while keeping the Docker CLI and socket.

colima start --memory 4
docker context use colima

The host layer genuinely gets lighter and you drop the Desktop app entirely. But the workload is unchanged: 12 containers, one gateway, all the sibling runtimes. You claw back some host overhead, not the container tax itself.

Approach 4: PGlite + custom auth

PGlite runs Postgres compiled to WASM, in-process, no containers at all. For pure database work it is astonishingly light, starts instantly, and can even run in the browser.

The catch for a Supabase-style app: there is no PostgREST, no GoTrue, no Realtime. My auth flow and supabase-js calls had nowhere to go, so this approach means rewriting the data layer and rolling your own auth for local dev. Great for tests and toy schemas, rough for "run my actual app locally."

Approach 5: Single-binary Supabase-compatible

The last approach keeps the Supabase API surface but drops the container model: one binary that bundles real Postgres with the REST, auth, and realtime layers in a single process. Tinbase is the one I used: real Postgres 17, works with the official supabase-js SDK unchanged, MIT-licensed.

./tinbase start

On my machine: ~100 MB steady-state, cold boot in seconds, zero app code changes. The tradeoffs are the single-process ones: no container isolation, and less mature ops tooling than the Docker ecosystem.

Summary

Approach	RAM (my run)	Boot	SDK compat	Containers
Docker + Supabase	~1.6 GB	~1 min	Full	12
Podman + Supabase	similar	~1 min	Full	12
Colima + Supabase	slightly less	~1 min	Full	12
PGlite + custom	tens of MB	instant	None	0
Single-binary (Tinbase)	~100 MB	seconds	Full	0

When to pick what

Team mirrors prod on k8s, 32 GB machines → stay on Docker Compose
Docker Desktop licensing is the problem → Podman
You want the Docker CLI without the Desktop app → Colima
Unit tests and throwaway schemas → PGlite
Solo dev / prototyping on 16 GB, Supabase-style app → single-binary backend

Conclusion

Podman and Colima answer "how do I run Docker cheaper." The more interesting 2026 question is "does local Postgres dev need containers at all," and for a lot of solo and small-team work the answer is no. Try the swap for a week; the rollback path is just supabase start.

What's your local stack idling at right now? Run docker stats --no-stream and drop the number in the comments.

App Store screenshots: a designer's playbook for 2026

Chris F A — Wed, 02 Sep 2026 11:12:40 +0000

TL;DR

Design for the 6.7" iOS format only; Apple scales the rest
Every converting layout is the same three-band structure: headline, device, caption
Sequence your screenshots as a six-part story, and over-invest in the first three
Localization means redesigning layouts, not just swapping strings
Run the thumbnail test and the sequence test before every upload

App Store screenshots are the single highest-leverage design surface for a mobile app. Users decide install-or-scroll within the first few seconds of scanning search results, and those seconds are dominated by your screenshots. Not your icon. Not your description. Screenshots.

Despite that, most teams' screenshots are afterthought screengrabs. Big miss. Here's the playbook I'd insist on if you're leading design on a mobile app.

The 6.7" primary format

As of 2026, the iOS App Store only requires 6.7" screenshots (iPhone Pro Max class, 1290 x 2796 px). Apple auto-generates smaller-device previews from your 6.7" upload. Design for the primary; don't waste a cycle laying out 5.5" separately.

Android Play Store: 1080 x 1920 minimum, up to 8 screenshots. Similar hierarchy applies, but device frames matter less (Play doesn't render them prominently).

Hierarchy: headline > device > caption

Every screenshot layout that consistently converts uses the same three-band structure:

┌──────────────────────────────┐
│                              │
│   BIG HEADLINE (60pt+)       │  <- Top 1/3
│   Single value prop          │
│                              │
├──────────────────────────────┤
│                              │
│   [Device Mockup]            │  <- Middle 1/3
│   Real app UI                │
│   Real content, not lorem    │
│                              │
├──────────────────────────────┤
│                              │
│   Sub-headline in a line     │  <- Bottom 1/3
│                              │
└──────────────────────────────┘

Why it works: at thumbnail size (roughly 120px wide in search results), only the headline is legible. That headline sells the install. The device and caption sell the feature to users who tap through.

The story arc across 6 screenshots

You get up to 10 screenshots on iOS, 8 on Android. Users see the first 3 in search results and the rest when they tap into your listing. Structure them as a narrative:

The promise. Your single strongest value prop. "Every dollar tracked in one place."
The proof. The core feature that delivers that promise. Show the app doing the thing.
The delight. A visual moment that makes them want to hold the app. Widgets, animations frozen at their most impressive frame, a beautiful data visualization.
The utility. A secondary feature that reinforces they'll use it often.
The trust. Social proof, awards, press mentions.
The action. A screenshot that literally says "Get started free" with a CTA-styled headline.

The first three carry most of the conversion weight. Invest disproportionately in them.

Localization: don't just translate, redesign

German copy runs substantially longer than English. Arabic reads right-to-left. Chinese ideographs need larger vertical spacing.

If your English headline is "Track your money," the German equivalent "Verwalten Sie Ihr Geld" won't fit at 60pt in the same box. You need per-language screenshot layouts. Apple lets you upload localized screenshots per storefront. Use it.

Minimum viable localization: English plus your top two non-English markets. Don't bother with every App Store language until you have data on where your installs come from.

Testing before submission

Two tests I run on every screenshot set before uploading:

Thumbnail test. Screenshot your screenshots. Resize to 120px wide. If you can't read the headline, redesign.

Sequence test. Line up all 6 in order. Do they tell a story? Or is it 6 random screens? If the latter, reorder or replace.

If you'd rather automate the first pass, the screenshot linter in the deploy pipeline catches most of the common failures before submission: thumbnail-legibility check, device-frame correctness, alert-in-screenshot detection.

Common mistakes

Using third-party device mockup frames. Apple prefers the official device chrome from its own design resources, not third-party frames.
A screenshot showing an alert or modal (it looks like an error state at thumbnail size).
Dark-mode UI in screenshots when the app defaults to light mode (users flip-flop mentally).
Numbers or metrics in the mock UI that don't add up. Obsessive users notice and flag your app as fake.

Worth four hours, every launch

If you're rolling your own process, spend the four hours per launch. Screenshots are the four hours of design that most dominate your install conversion.

What does your current first screenshot say at 120px? Drop it in the comments; happy to critique headlines.

How I Ran the Full Supabase Stack Locally in 100 MB of RAM (No Docker)

Chris F A — Mon, 31 Aug 2026 17:40:32 +0000

How I Ran the Full Supabase Stack Locally in 100 MB of RAM (No Docker)

Twelve containers. 1.6 GB of RAM. 45 seconds to supabase start. Every time I opened my project.

This week, the same stack runs in ~100 MB, boots in 2.5 seconds, and my app code didn't change. Here's how.

Why this matters

Docker overhead for local dev is a background tax that's easy to ignore. My M1 Air fans spin up whenever Supabase is running. My battery drains ~30% faster. My other tools (VS Code, browsers, IDE plugins) share the remaining RAM with 12 containers I don't think about.

The real cost isn't the RAM itself, it's the workflows that get shaped around it:

I don't run local backup unless I know I'll code for >30 min (not worth the boot).
When I'm designing a schema change, I test it against hosted Supabase because local is slow.
Anyone on my team who isn't a full-time backend engineer (designers, PMs) uses staging instead of local, which creates its own dysfunction.

The alternative: a single-binary Supabase-compatible backend

The tool I ended up using is Tinbase — a single-file executable (~58 MB) that runs real Postgres 17 plus auth, realtime, edge functions, webhooks, and cron. It exposes the same HTTP + Postgres endpoints as hosted Supabase, so supabase-js connects to it unchanged.

From my app's perspective, the only change was the connection string:

ts
// Before (Docker Supabase local)
const supabase = createClient(
'http://localhost:54321',
'eyJhbGci...anon-key'
);

// After (Tinbase)
const supabase = createClient(
'http://localhost:4000',
'eyJhbGci...anon-key' // same SDK, same anon key format
);

That's it for app code. Zero refactor.

The migration steps

1. Install

bash
curl -fsSL https://tinbase.dev/install.sh | sh

One executable at ~/.tinbase/bin/tinbase. ~58 MB on disk.

2. Initialize a project

bash
tinbase init my-project
cd my-project
tinbase start

Boots in ~2.5s. Exposes:

Postgres on localhost:5432
REST API on localhost:4000/rest/v1
Auth on localhost:4000/auth/v1
Realtime WebSocket on localhost:4000/realtime/v1
Storage on localhost:4000/storage/v1
Admin UI on localhost:4000

Same endpoint structure as hosted Supabase.

3. Port migrations

bash
cp -r /path/to/my-app/supabase/migrations ./migrations
tinbase db reset

The migrations run against the embedded Postgres. RLS policies work identically because it's real Postgres 17.

4. Update the connection string in my app

[7:04 AM]Change the SUPABASE_URL env var from http://localhost:54321 to http://localhost:4000. That's the only app-side change.

5. Stop Docker

bash
supabase stop
docker system prune -a --volumes # reclaim ~2.3 GB of images + volumes

Benchmarks after the switch

Measured on the same M1 Air, same app, same test load (10 min of active development: a few queries, a realtime subscription, one edge function invocation).

Metric	Docker Supabase	Tinbase	Delta
Boot time (cold)	45s	2.5s	−94%
Boot time (warm)	15s	1.2s	−92%
Steady-state RAM	1626 MB	98 MB	−94%
Disk footprint	2.3 GB	58 MB	−97%
Idle CPU %	4-8%	0.1-0.4%	−95%
Fan noise	audible	silent	qualitative

The RAM number is the headline. Under active load with realtime + edge functions firing, RAM peaked at ~250 MB. Docker Supabase under the same load peaked north of 2 GB.

What worked out of the box

supabase-js SDK: unchanged. All CRUD, auth, realtime, storage calls work identically.
RLS policies: identical behavior (it IS real Postgres 17, same policy engine).
Edge functions: deployed the same way (tinbase functions deploy hello), runtime is Deno like Supabase.
Realtime subscriptions: WebSocket connection, same protocol.
Storage: same bucket/RLS semantics.
Migrations: standard Postgres SQL, ran without modification.

What I had to change

Being honest — a few things weren't 100% drop-in:

1. Supabase Studio → Tinbase Admin UI. The admin UI is different (obviously — it's a different product). If my team relied on Studio-specific features, I'd have to check compat. In my case, I mostly use it for eyeballing schema, which the Tinbase UI does fine.

2. Some newer Supabase-hosted features aren't there yet. Specifically, some of the newer analytics endpoints and the vector search integration are hosted-only for now. If my app depended on these, I'd need to keep them talking to hosted Supabase (Tinbase for the general dev workflow, hosted Supabase for those specific features).

3. Edge function environment isn't 100% identical. Deno version, some environment variables, some Supabase-specific runtime globals. I hit one edge case where I was using Deno.env.get('SUPABASE_URL') — worked in the local runtime, but the value was different. Easy fix, but worth mentioning.

Where the single-binary approach hits limits

This isn't a Supabase replacement. It's a local-dev replacement.

For production, hosted Supabase is still the right choice — you want their SLA, their scaling infrastructure, their team maintaining it. What Tinbase replaces is the local-dev docker-compose stack.

The approach starts to strain if:

You have multi-terabyte data volumes locally: fine for dev-sized datasets, less optimized for large ones (though it's real Postgres, so it scales as Postgres does).
You need every hosted-Supabase feature identically: check the compat matrix.
You're running this in prod at scale: it can, but that's not the primary use case.

For a workflow where I want the Supabase ergonomics without the Docker overhead — which is 95% of my local dev — it's genuinely better.

Takeaway

If you're on Docker Supabase for local dev and the RAM/boot-time overhead is a background tax, there's a lighter alternative now. Same SDK, same auth/realtime/storage semantics, one file. Migration is a connection string swap.

The Docker overhead was invisible to me until I removed it. Now the difference is stark: fans off, faster iteration, and (unexpectedly) designers on my team started running the app locally because the setup was one command.

Sometimes the right optimization isn't a smaller container image. It's asking whether you need the container abstraction at all.

The Design Workflow That Makes an Expo Template Stop Looking Like an Expo Template

Chris F A — Thu, 20 Aug 2026 11:05:49 +0000

TL;DR

Six defaults give away almost every Expo template: blue-500, Inter, Lucide outline icons, borderRadius: 12 cards, borderRadius: 8 buttons, and a "Nothing here yet" empty state.
Three changes do most of the work in 45 minutes: one palette, one type pairing, one radius token.
Mixed radii (8 on buttons, 12 on cards) is the single most visible tell. Pick one.
Add exactly one motion primitive: press-in scale to 0.97, one shared spring config, everywhere.
Name your Figma variables the same as your code tokens. Export to JSON, feed it to your theme, stop doing per-screen updates.
The full polish plan is 12 to 14 focused hours across a week.

Every Expo template on the market ships with the same tell-tale visual signature: teal or blue primary color, Inter font, generic Lucide icons, and a card-with-shadow list style. Users can spot a template-fork from three seconds away.

The reason: template authors are engineers, and engineers ship default themes. Founders inherit those defaults, launch, and their app blends into every other Expo template on the App Store.

Here's the design workflow I use to turn a template into something that looks like a real product. The core of it, the part that does most of the work, is 45 to 60 minutes.

The default look: what to notice

Almost every Expo template ships with:

Primary color: teal-500, blue-500, or purple-500 from Tailwind.
Body font: Inter, sometimes Manrope.
Icons: Lucide, Heroicons, or Ionicons in outline weight.
Card style: borderRadius: 12, shadow-md, white background.
Button style: borderRadius: 8, primary color fill.
Empty state: a small centered illustration plus "Nothing here yet."

The combination is instantly recognizable as "generic template." Users are trained to distrust it.

Three visual changes that de-generic-ify (45 min total)

1. Palette (15 min).

Pick a primary color that's NOT teal or blue-500. Coolors.co or Radix Colors' scales are good sources. Set:

primary: your brand color, a saturated hue distinct from defaults
bg: off-white or off-black, never pure #FFFFFF (pure white looks synthetic)
surface: a slight tint off bg
text: a warm dark like #171717, not pure black

The whole thing wants to live in one file:

// theme.ts
export const theme = {
  colors: {
    primary: '#5B3DF5',
    bg: '#FAFAF9',
    surface: '#F4F4F2',
    text: '#171717',
  },
  radius: { md: 12 },
  space: { 1: 4, 2: 8, 3: 12, 4: 16, 6: 24, 8: 32 },
} as const;

Wire it once, then search-replace the template's default hex values. If your template scatters raw hex across screens instead of centralizing it, that 15 minutes becomes an afternoon. Applighter templates keep palette, type, and radius as configurable variables for exactly this reason.

2. Typography (15 min).

Swap Inter for something with more character. Two safe non-Inter picks in 2026:

Geist (Vercel): modern, still neutral, but not Inter.
Manrope: friendlier, slightly rounder.

Or commit fully:

Space Grotesk for headings plus Inter for body. The mismatch reads as intentional.
DM Serif Display for headings plus DM Sans for body. Signals design-forward.

Load with expo-font. Never load more than 2 font families.

3. Corner radius (15 min).

Search your codebase for borderRadius: 8 and borderRadius: 12. Pick ONE radius token and use it everywhere. Common quality signals:

4: sharp, technical (Linear, Vercel)
12: friendly, standard (Apple's default)
20: soft, consumer (Instagram, Airbnb)

Mix-and-match radii is the single most visible "template" tell. If you do nothing else in this post, do this one.

Motion primitives that signal quality

Add ONE motion primitive to every interactive element:

Buttons: scale to 0.97 on press-in, back to 1.0 on release. 100ms.
Cards: subtle scale on press if tappable.
Screen transitions: use Expo Router's default fade, not the aggressive iOS slide.

One library: react-native-reanimated, already in most templates. One shared spring config, one wrapper component, used everywhere:

import { Pressable } from 'react-native';
import Animated, {
  useAnimatedStyle,
  useSharedValue,
  withSpring,
} from 'react-native-reanimated';

const spring = { damping: 20, stiffness: 300 };

export function PressScale({ children, onPress }) {
  const scale = useSharedValue(1);
  const style = useAnimatedStyle(() => ({
    transform: [{ scale: scale.value }],
  }));

  return (
    <Pressable
      onPressIn={() => (scale.value = withSpring(0.97, spring))}
      onPressOut={() => (scale.value = withSpring(1, spring))}
      onPress={onPress}
    >
      <Animated.View style={style}>{children}</Animated.View>
    </Pressable>
  );
}

Wrap your buttons and tappable cards in that and you're done. Applied consistently, this alone changes how the app feels, from "template" to "considered."

Icons and illustrations

Lucide icons are fine but instantly recognizable. Two paths off the default:

Phosphor Icons (free, huge set, 6 weights). Swap the import: import { Heart } from 'phosphor-react-native'.
Custom SVGs for the 5 most-visible icons. Your tab-bar icons, your empty state, your loading state. Commission or draw these. react-native-svg renders them at any size.

For empty states: replace the generic illustration with something specific to your product. "No orders yet" beats "No items yet" beats a stock cart drawing.

The one Figma-to-code handoff that saves the most time

If you're designing in Figma alongside the app, do THIS one thing:

Define your color, spacing, and radius tokens in Figma with the SAME names as in your code. primary, bg, surface, space-2, space-4, radius-sm, radius-md.

Then use Figma's Variables export to a JSON file. Feed that JSON into your Expo theme. Every design change flows through the token file, with no per-screen updates.

The ship-in-a-week visual polish plan

Day 1 (2 hrs): audit the template's default palette, type, radius, icons. Note every hex, every borderRadius, every icon library.

Day 2 (3 hrs): pick and apply the palette, type, and radius. Ship a build. Look at it on your device.

Day 3 (2 hrs): swap the icon set. Replace the 5 most-visible custom illustrations.

Day 4 (2 hrs): add motion primitives. Buttons, cards, screen transitions.

Day 5 (2 hrs): design 3 empty states specific to your product.

Day 6-7: user-test with 3 people. Watch what they say when they first open the app. Fix the visual bits they call out.

Total: roughly 12 to 14 focused hours. Your app stops looking like a template.

Why this matters

Users make a trust decision fast, and most of it happens before they read a word of your copy. If your app looks like every other template, they've seen a lot of similar apps this year and their trust default is "probably not that good."

A distinct visual identity, even a rough one, signals someone actually cared. That's worth a lot more than the fastest possible time-to-ship.

Which of the six default tells is still in your app right now? I'm betting on the mixed radii. Drop yours in the comments.

DEV Community: Chris F A

What React Native Devs Actually Struggle With: A Year of Support Tickets

1. EAS Build fails on first run

2. Supabase RLS returns [] after auth

3. Env vars are undefined in production

4. Metro cache poisoning

5. Missing Info.plist permission strings

6. Android package rename breaks the build

7. Android push says "ok" but nothing shows

8. AI streaming stalls or drops tokens

9. Stripe webhook never reaches Supabase

10. Voice transcription feels slow on budget Android

The takeaway

Build vs Buy a React Native Template: What Founders Miss

TL;DR

You've already lost a week

The 80/20 nobody tells you about

What building the 80% actually costs

What buying costs (when it goes wrong)

Audit a template in 60 seconds

The comparison you should actually run

Where is your differentiator, really?

Don't build from scratch if...

Don't buy (or return it) if...

What a good buy looks like

The middle path: fork it

Quick FAQ

Your Expo + Supabase Login Works. Now Restart the App.

Gap 1: The session doesn't survive a restart

Gap 2: The magic-link / OAuth callback dies in a standalone build

Gap 3: The token expires while the app is backgrounded

Gap 4: You're testing in the wrong environment

The boilerplate is the same every time

Your turn

The cold-start problem for paid React Native templates (our first 100 customers)

Why "just make a good template" doesn't work

Week 1 starting position

What actually worked, ranked by attributed first sales

1. SEO on very specific long-tail queries

2. Building in public in the right communities

3. Buying trust with a small open-source release

4. Cross-linking SKUs

5. The refund policy is a sales tool

What flopped

Month-6 funnel numbers

What we sell against

The checklist if we started over

What cold-start really means

AI features in mobile apps: 4 patterns that ship

TL;DR

Why the taxonomy matters

Pattern 1: Text-in, text-out

Pattern 2: Voice-in, text-out

Pattern 3: Vision-in, structured-out

Pattern 4: Retrieval-augmented anything

The four patterns compared

What doesn't ship (yet)

FAQ

Ship one pattern well, not four badly

How to Ship a React Native App in Days, Not Months

Why "days, not months" isn't marketing hype

Pattern 1: One-hex-code theming

Pattern 2: RLS baked into the migrations, not bolted on later

Pattern 3: Stripe checkout, webhook, and license grants as one atomic flow

Pattern 4: Auth flows that already handle the four bad states

Pattern 5: AI feature scaffolds you can point at any provider

Pattern 6: A single template registry so nothing drifts

The comparison table

What "days" actually means, day by day

FAQ

Local Dev Without Docker: A 2026 Look at the Alternatives (and When They're Actually Better)

The three real reasons Docker is still the right answer

Alternative 1: Native installs

Alternative 2: Single-binary embeds

Alternative 3: Micro-runtimes (Nix, mise, devbox)

Comparing on metrics that matter

Worked example: replacing a Supabase docker-compose

Closing: pick the runtime that fits the workload

We open-sourced our React Native template engine (but not the part that makes money)

Why we split it at all

2. Supabase RLS returns `[]` after auth

3. Env vars are `undefined` in production