DEV Community: Chris F A

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.

Ship a React Native app in days, not months

Chris F A — Fri, 31 Jul 2026 09:47:47 +0000

TL;DR

~4 weeks of every React Native project is setup, not product
One HSL-derived theming primitive kills grep-and-replace rebranding
A hybrid data provider means the repo runs on the simulator with zero env vars
RLS policies belong in the migration, not in your head at 2am
Stripe webhook → entitlement grant → authorized download is 3–5 days of small correct decisions
Agent-legible codebases (small files, typed providers, NativeWind) are a real speed multiplier in 2026

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 in day 4 of a Stripe integration — but 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

Compare with other template projects to see the market.

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, documented in the refund policy on applighter.com.

Try one

The full template catalog lives on applighter.com — $79 one-time, full source, lifetime updates.

What's the piece of setup that eats the most of your time on a new RN project? Drop it in the comments — theming, RLS, or Stripe entitlements are the three I'd bet on.

Designing a build artifact system a 3-person team can actually navigate

Chris F A — Wed, 29 Jul 2026 10:27:27 +0000

TL;DR

Filenames can't carry metadata. Stop asking them to — push the data into the binary and the EAS build record instead.
Every build needs 5 attributes: git SHA, environment, version + build number, who triggered it, and when.
One convention that holds up: <product>-<env>-v<semver>-b<buildnum>-<sha7>.<ext>
appVersionSource: remote + autoIncrement: true means you never ship two builds numbered 47.
Release notes generate themselves from git log between two SHAs — one source, three surfaces.
A Notion database with 6 columns beat Sheets, Airtable, Linear, and a #builds Slack channel.

By month four of any real mobile project, you have ~400 build artifacts scattered across EAS Build history, Slack DMs ("here's the beta build.ipa"), Google Drive folders titled builds temp DELETE LATER, and someone's Downloads folder. When QA asks "which build did we send to the pilot testers on Tuesday?", nobody knows. Not the PM, not the tech lead, not the person who literally sent it.

This is a workflow problem, not a tools problem. Every team I've watched solve it did four specific things. Every team still drowning skipped one of them.

The Finder problem: 400 artifacts, no naming convention

Here's a real Finder window from a team I audited last month:

MyApp-build.ipa
MyApp-build (1).ipa
MyApp-build-final.ipa
MyApp-build-final-USE-THIS.ipa
MyApp-preview-v3.ipa
MyApp-preview-v3-hotfix.ipa
app-release.aab
app-release (2).aab
MyApp_2026-06-14.ipa

None of these tell you: what commit, what env, what tester group, what release date, what build number ASC saw. To answer any of those, you have to open the EAS dashboard, cross-reference build ID, cross-reference commit SHA, and hope nobody force-pushed to the branch since.

The root cause is that filesystem filenames are being asked to carry metadata they can't hold. The fix is to stop trying and move the metadata upstream — to the build itself.

The 5 attributes every build must carry (and where to attach them)

Every artifact needs to answer:

What code? — git SHA (short, 7 chars) + branch
What environment? — dev / preview / production / hotfix
What version? — semantic version + build number (they're different things)
Who / what triggered it? — human name or CI job ID
When? — timestamp in one timezone (pick one, stick with it — IST for us)

Where to attach them, in order of durability:

In the binary itself (Info.plist / AndroidManifest) — survives everything, hardest to fake
In the EAS build metadata (gitCommitHash, gitCommitMessage — EAS captures these automatically if you use appVersionSource: remote)
In the artifact filename when downloaded — mostly for humans skimming Finder
In your team's tracker (Notion / Linear / Slack canvas) — the human-readable index

The mistake teams make: they only do #3 (filename) and skip #1, #2, #4. Filename gets truncated, renamed, forwarded — the data dies. Metadata in the binary lives forever.

Here's the EAS-side setup that makes #1 and #2 automatic:

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true,
      "env": {
        "APP_ENV": "production"
      }
    }
  }
}

appVersionSource: remote tells EAS to manage build numbers server-side, so you never manually bump ios.buildNumber again and you never ship two builds with number 47. autoIncrement: true adds one on every build. APP_ENV gets baked into the binary and is readable at runtime — so the app can display its own env in a debug menu, which is worth an hour of QA time per week alone.

A naming + tagging scheme that survives 6 months

For the human-facing name (filenames, Slack shares, Notion titles), one convention that's held up across three teams:

<product>-<env>-v<semver>-b<buildnum>-<sha7>.<ext>

Examples:

rapidnative-preview-v2.4.1-b127-a3f9c81.ipa
rapidnative-production-v2.4.0-b125-d7e21bc.aab

Rules that make this work in practice:

No spaces, no parens, no "final", no "USE-THIS". Ever.
Env is one of exactly 4 values. dev / preview / production / hotfix. If you need a fifth, you don't — merge it into one of these.
SHA is always 7 chars. Not 6, not 8. Consistency matters more than length.
The tracker row uses the same string as the row's title. So Cmd-F in Notion finds the artifact instantly.

This is boring on purpose. Boring conventions are the ones that survive team turnover.

Release notes that write themselves from artifact metadata

Once every build carries git SHA + previous-build's SHA (EAS knows both), release notes generate themselves. A tiny GitHub Actions step that runs after eas build completes:

- name: Generate release notes
  run: |
    PREV_SHA=$(gh api repos/${{ github.repository }}/releases/latest --jq .tag_name || echo "HEAD~10")
    CUR_SHA=${{ github.sha }}
    echo "## Changes in build $CUR_SHA" > release-notes.md
    git log --pretty=format:"- %s (%an)" "$PREV_SHA..$CUR_SHA" >> release-notes.md
    echo "" >> release-notes.md

The output becomes the testInformation field when you eas submit to TestFlight (external testers see it) and doubles as the Slack post when the build lands. One source, three surfaces, zero manual writing. If you'd rather not maintain the workflow file yourself, letsdeploy.it ships this exact step — SHA diffing, note generation, submission — as part of the pipeline.

The design principle: any artifact metadata worth showing to a human should surface in at least two places automatically. If it lives in only one place, it will get lost or become stale.

The one Notion / Linear pattern that beat every other tool

I tried five variants of build tracking over two years: Google Sheets, Airtable, a Notion database, a Linear project view, and a #builds Slack channel.

The one that stuck is embarrassingly simple: a Notion database with 6 columns and a filter.

Columns: Artifact name (the string above), Env, Version, SHA, Triggered by, Status. Filter: Env = production view for stakeholders, Env = preview view for QA, Status = failed view for post-mortems. That's it. No custom formulas, no linked databases, no rollups.

Why it beat the others:

Sheets — everyone can edit, so schema drifts. Someone adds a "Notes" column, someone else adds "Notes 2," convention dies in 3 weeks.
Airtable — great, until the free plan cap. Then you're paying $20/user/month for something a Notion page does.
Linear project view — Linear wants everything to be an issue with an assignee. Builds don't have assignees. Force-fitting them broke Linear's own workflows.
Slack #builds channel — worst for retrieval. Nobody scrolls back 6 weeks to find a build. Slack search is okay but rewards recency, not structure.

Notion database wins because it's schemaless-enough to start ugly and iterate, structured-enough to filter, and searchable enough that Cmd-F works.

One bonus: give the database a public read-only share link. Stakeholders stop DM'ing you "which build is prod on?" and start bookmarking the URL.

The meta-lesson

Build artifact organization is a design problem, not an engineering one. The engineering (naming, metadata, CI) is 20% of the value. The other 80% is picking one convention and enforcing it socially — nobody renames files, nobody ships without the tracker row, nobody sends builds via DM.

If you're setting this up for the first time, budget half a day for the convention and half a day for onboarding the team to it. If your team already has 400 unstructured artifacts, don't retroactively rename them — start clean from today's build. Sunk cost is real; back-labeling artifacts is not worth the hours.

What does your build artifact naming look like right now? Drop your convention in the comments — I'm still collecting variants, especially from teams running more than one app out of a monorepo.

Cutting React Native template support 70% with docs

Chris F A — Fri, 24 Jul 2026 12:42:15 +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 is 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. The one we ship in every Applighter template 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 (6 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

If you sell anything to developers, run the audit this week — tag your last hundred tickets and the shape of your docs problem will be obvious within an hour. Drop a comment with what your top ticket category turns out to be; curious whether install beats configure for everyone or just for us.

The Boring React Native Stack for New Founders

Chris F A — Wed, 22 Jul 2026 09:51:29 +0000

Every week, first-time React Native founders ask us the same question: what stack should I use?

Here's our copy-pasted answer, with the receipts.

TL;DR

Client:   Expo SDK 54 (managed) + Expo Router + TypeScript
Styling:  NativeWind v4
Data:     TanStack Query v5 + React Hook Form
Motion:   Reanimated 4.1
Backend:  Supabase (Postgres + Auth + Storage + Edge Functions + RLS)
Payments: Stripe (payment mode, one-time)
Builds:   EAS Build + EAS Update

No Redux. No Firebase. No custom auth. No Fastlane. No bare workflow.

Why "boring"

You have zero product-market fit information on day zero. Every stack decision you make on day zero is a bet without data. The correct bet is the one that:

Has the most Stack Overflow answers
Has the shortest "hello world → first user" path
Has the lowest switching cost when you learn you were wrong

That's a boring stack, definitionally.

The client

Expo SDK 54 (managed workflow)

npx create-expo-app@latest my-app
cd my-app
npx expo start

Don't expo prebuild. Don't eject. The managed workflow gives you EAS Build (cloud iOS builds without a Mac), expo-updates for OTA JS pushes, and pre-wrapped native modules for 90% of what you'll need.

Expo Router

File-based routing. If you know Next.js App Router, you know Expo Router.

app/
├── (tabs)/
│   ├── _layout.tsx
│   ├── index.tsx
│   └── profile.tsx
├── notes/
│   └── [id].tsx
└── _layout.tsx

Deep links, universal links, and typed routes come for free. Docs:

docs.expo.dev

NativeWind v4

Tailwind for React Native.

<View className="flex-1 bg-white dark:bg-neutral-900 px-4">
  <Text className="text-2xl font-semibold text-neutral-900 dark:text-white">
    Hello
  </Text>
</View>

Your team already knows Tailwind. Move on.

Data layer

TanStack Query v5 for anything that touches the network

const { data, isPending, error } = useQuery({
  queryKey: ['notes', userId],
  queryFn: () => supabase.from('notes').select('*').eq('user_id', userId),
})

Cache invalidation, background refetch, optimistic updates, offline persistence — all included. You do not need Redux.

React Hook Form for forms

const { control, handleSubmit } = useForm<Note>()

<Controller
  control={control}
  name="title"
  render={({ field }) => (
    <TextInput onChangeText={field.onChange} value={field.value} />
  )}
/>

Boring. Fast. Good TypeScript types. The end.

Motion: Reanimated 4.1

const offset = useSharedValue(0)
const animatedStyle = useAnimatedStyle(() => ({
  transform: [{ translateX: offset.value }],
}))

const gesture = Gesture.Pan().onUpdate((e) => {
  offset.value = e.translationX
})

Worklets run on the UI thread. 60fps by default. No bridging.

The backend: Supabase, all of it

The reason Supabase is boring in the good way: it's Postgres. When your query is slow at 11pm, you open the SQL editor and read the plan.

Row-Level Security (non-negotiable)

Enable RLS on every table before the table has data:

alter table notes enable row level security;

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

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

Now no client bug, no leaked JWT, no misconfigured API route can leak user A's rows to user B. The database refuses. This is the single highest-leverage security decision you make.

Edge Functions for secrets

Every third-party API key (OpenAI, Anthropic, Stripe, Deepgram) lives in an Edge Function. Zero secrets in the client bundle:

Deno.serve(async (req) => {
  const apiKey = Deno.env.get('OPENAI_API_KEY')!
  // ... call OpenAI, stream response back via SSE
})

Payments: Stripe (one-time, not subscriptions)

First-time founders default to subscriptions because that's what YC tells them to want. Ship one-time first — simpler dunning, faster checkout, no churn number to obsess over on Monday mornings.

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [{ price: priceId, quantity: 1 }],
  success_url: `${origin}/success?session_id={CHECKOUT_SESSION_ID}`,
  cancel_url: `${origin}/cancel`,
})

Webhook → product_licenses table → grant unlocked. Applighter itself ships in this exact pattern — every template in the catalog uses this one-time-purchase flow end-to-end.

Builds: EAS

eas build --platform ios --profile production
eas submit --platform ios --latest
eas update --branch production --message "fix: crash on launch"

Cloud iOS builds. No Mac required. OTA updates ship in minutes instead of days.

Comparison table

Piece	Boring pick	Trendy alt	Why v1 skips trendy
Framework	Expo managed	Bare RN	2 weeks re-wrapping native libs
Styling	NativeWind	Tamagui	Your team knows Tailwind
State	TanStack Query + useState	Redux / Zustand	95% of state is server state
Backend	Supabase	Firebase	Firestore's query model is a trap
Auth	Supabase Auth	Clerk	It's already bundled with the DB
Payments	Stripe one-time	RevenueCat subs	Subs are v2
Builds	EAS	Fastlane	Cloud-native, no Mac needed

What we deliberately omit

Redux / Zustand — see above
GraphQL — Postgres + PostgREST is enough
Sentry — recommended, but not day one
Monorepo — great for 3+ apps, overkill for one
Detox / Maestro — unit tests first, E2E after 6 months

The AI stack question

"But my app is an AI app — does the stack change?"

Almost not at all:

+ Supabase Edge Function (holds OPENAI_API_KEY)
+ Postgres table for chat history (RLS on)
+ SSE streaming back to client (rendered with Reanimated)

That's it. AI features are just features.

The playbook

npx create-expo-app on latest stable SDK
Add NativeWind + Expo Router + Reanimated + TanStack Query + RHF
Supabase project → schema in migrations → RLS before any rows
Every third-party key in Edge Functions
Stripe payment mode → webhook → product_licenses table
EAS → TestFlight in the first two weeks
Ship features. Reconsider stack in 18 months.

Or: skip steps 1–5

Our templates are this exact stack, wired end-to-end, with real Stripe flow and RLS on every table — the catalog is linked up in the payments section. If you'd rather start on hour one with a working app instead of hour thirty, that's what they're for.

Either way — pick a boring stack and ship. Reading yet another stack post is the enemy.

What's the stack you actually shipped with — and what would you cut from this list? Drop a comment.

The Design Handoff Changed — Here's What AI-Legible Specs Look Like

Chris F A — Wed, 22 Jul 2026 09:44:37 +0000

A year ago, the design handoff was: Figma file, Slack thread, engineer opens Figma, translates layout, spends 4 hours on one screen. Feedback loop measured in days.

Today, if the engineer is using Claude Code and your Figma has the right structure, one screen can go from design-approved to feature-branch in 20 minutes. But only if design changed how it hands off. Otherwise you get the AI-slop version.

Here's what changed.

The new handoff

The AI does the layout translation. What it needs from you:

A structured spec (not just a Figma link).
Named components and design tokens (not raw pixel values).
State variants explicit (loading / empty / error / success, all designed).
A working example somewhere in the codebase the AI can pattern-match against.

Give the AI these and the engineer's role shifts from 'implementer' to 'QA'.

What makes a spec AI-legible

Bad spec (what most teams still write):

'Login screen with email + password. Match the style of the signup screen.'

Good spec:

**Login screen** (`app/(auth)/login.tsx`)

**Layout:** Centered card, 24px padding, max-width 400px, radius 12px.

**Contents (top-down):**
- Logo (asset: `assets/logo.svg`, 64x64px)
- Heading: 'Welcome back' (typography token: `heading/md`)
- Email input (component: `<Input type="email" label="Email" />`)
- Password input (component: `<Input type="password" label="Password" />`)
- Primary button: 'Sign in' (component: `<Button variant="primary" fullWidth />`)
- Text link: 'Forgot password?' → `/(auth)/reset`
- Divider with 'or'
- Google OAuth button (component: `<Button variant="oauth" provider="google" />`)

**States:**
- Idle: as above.
- Loading: primary button disabled + spinner, other fields disabled.
- Error (invalid credentials): red banner above form, 'Invalid email or password.'
- Success: redirect to `/(protected)/home`.

**Existing pattern to match:** `app/(auth)/signup.tsx`.

The second spec, an AI can implement in one shot. The first spec, the AI guesses and you get random.

Where design still has to be in the room

Deciding what should exist on the screen. The AI can render anything; deciding what shouldn't be there is the design call.
Reviewing motion / interaction. Static screenshots don't communicate feel. Design still needs to test the interaction on-device.
Sign-off on brand-adjacent decisions. Illustrations, iconography, tone of empty-state copy. AI generates competent, not distinctive.
The system-level view. Any single screen an AI can build. The design system it's building against is your job.

The design-to-Claude-Code checklist

Before you hand a spec to be implemented via AI:

[ ] Every component named matches a real component in the codebase (or is explicitly new with an inline spec).
[ ] Every typography/color/spacing value is a design token, not a hex/px.
[ ] All five states (loading / empty / error / success / boundary) are designed.
[ ] Copy is finalised, not lorem ipsum.
[ ] Analytics events (what to track() on interactions) are listed.
[ ] The existing screen most similar to this one is linked.

That checklist is 10 minutes of design time. It saves the engineer an hour and gives you a much better first cut back.

Practical: what to put in your team's design workflow

Design deliverable is now a Markdown spec + Figma link, not just a Figma link.
The Markdown lives in the repo alongside the code (in /docs/screens/ or similar).
The AI reads both when implementing.
Design reviews the implemented screen, not the code — the AI wrote what you told it to; you check that you told it right.

If you want to see this spec-first workflow in action end-to-end, Applighter is built around exactly this loop — structured specs in, working screens out.

Design's role isn't shrinking with AI. It's shifting to more explicit specification and more rigorous review — the parts that were always undervalued when handoffs were 'just look at the Figma'. The tools finally reward doing them well.

What does your team's handoff look like right now — still Figma-link-and-pray, or have you started writing specs the AI can read? Drop a comment.

Sell Templates vs SaaS — 12 Months of Real Numbers

Chris F A — Mon, 20 Jul 2026 09:59:07 +0000

Sell Templates vs SaaS — 12 Months of Real Numbers

If you're an indie hacker on the "SaaS by default" hype train, this is the counter-post.

We ran a React Native template shop (Applighter) for twelve months instead of building the SaaS everyone told us to build. Below are the actual numbers, the trade-offs, and the decision framework we now use.

TL;DR

Templates: higher AOV per sale, ~zero infra, zero pager, bounded support, no compounding.
SaaS: compounding MRR, real churn, real pager, real infra bill, real feedback loop.
Neither is passive. Both are full-time jobs. Pick based on what kind of job you want.

The 12-month table

Metric	Templates (us)	Solo SaaS (previous project)
Avg deal size	$148	$19/mo (~$228 annualized)
Refund / early cancel	3.4%	~5%
Support tickets / sale	0.6	3.1 / active seat / yr
Monthly infra	~$40	~$620
Time to first $	Day 11	Day 47
Weekend incidents (12mo)	2	19
Churn	N/A	7.1% / mo

The template stack

Every Applighter template ships with the same base:

# Every template is:
# - Expo SDK 54
# - React Native + TypeScript
# - NativeWind styling
# - Supabase (postgres + auth + storage + edge fns)
# - Stripe for in-app monetization
# - EAS Build ready

The tech consolidation matters commercially. When every product uses the same base, upgrades are a single sweep, not a per-product project.

// modules/services/AIService.ts — swappable AI backend
export interface AIService {
  transcribe(audio: Blob): Promise<string>;
  chat(messages: Message[]): Promise<Message>;
}
// Concrete: OpenAIService, AnthropicService, etc.

That interface is the reason we can promise "swap GPT-4o for Claude with a config change" and mean it. It's also the reason support tickets stay bounded — we don't get "your AI provider is broken" tickets because the provider is the buyer's choice.

Where SaaS beats templates

Compounding revenue. A template sale today doesn't pay you next month. A SaaS seat sold today at 3% monthly churn pays you ~33 more times. That's the whole reason people build SaaS. It's real and it matters.

Feedback. SaaS users are in your product daily. Template buyers vanish into their own codebase. You learn less than you'd think.

Pricing power. Raise SaaS prices annually. Templates are mostly a one-shot pricing decision.

Enterprise ceiling. SaaS scales into six- and seven-figure ACVs. Templates cap somewhere around a few $k per license.

If your product genuinely requires a hosted component — real-time collab, an API you route traffic through, a data pipeline the buyer can't self-host — templates are not viable. Build the SaaS.

Where templates beat SaaS

Infra is a rounding error. ~$40/mo covers our site, DB, and email. A SaaS at even modest scale needs multiples of that before month one.

Support is bounded by the sale. SaaS support scales with active seats forever. Template support scales with new sales and drops off after week two per customer.

No pager. No servers = no wakeups. Our only two "on-call incidents" in a year were us breaking our own site.

Zero data liability. We hold no customer PII beyond orders. Breaches don't propagate.

Pricing that fits on a napkin. Buy once, own forever, get updates. Try writing that on a SaaS pricing page.

The revenue mix

Stream	Share
Template licenses	71%
Bundle upgrades	18%
Custom / enterprise	8%
Affiliate + referrals	3%

Notice: no SaaS component. We prototyped a hosted "template runner" for a week and killed it — the moment you host something, your infra + support burden explodes.

The uncomfortable parts

Revenue is spiky. No MRR floor means a slow week hurts. We use a rolling 4-week average for any decision that matters.

Marketing is the whole job. No retention means every dollar needs a new buyer. If you hate writing, posting, and networking, don't sell templates.

Piracy exists. Templates hit nulled sites within a month. Buyers who pay ≠ people who pirate. File DMCAs, move on.

The math

Solo dev: ~1920 productive hours/year.
Each template sale ≈ 30 min of amortized effort.
SaaS attempt with same input ≈ 45 seats × $19/mo × 12 = ~$10k ARR at month 12.
Template shop crossed that in month 3.

Templates front-load payoff. SaaS back-loads it. If your runway is short and your compounding assumption is optimistic, front-loading is safer.

External refs

Expo docs — the runtime under every template we sell.
Supabase RLS guide — the reason we can ship a real backend inside every template without hand-holding.
Basecamp's Once — the sharpest existing counter-argument to SaaS-forever.

Verdict

Sell templates if:

You can write code other developers will pay for on first look.
You're willing to be a full-time marketer.
You want the money now, not later.

If any answer is no, build the SaaS — and price for the pager.

The 60-Minute Boilerplate Strip-Down Test

Chris F A — Wed, 08 Jul 2026 08:52:55 +0000

TL;DR

Feature counts on a boilerplate landing page are the easiest thing to market and the least predictive of quality.
The real test: fork the repo, start a 60-minute timer, and try to cleanly remove the auth layer.
If it comes out cleanly, the seams are good and the rest probably follows. If it fights you, you'll be maintaining someone else's architecture forever.
Three pre-fork red flags: auth sprinkled across screens, DB queries that also do auth checks, and navigation coupled to auth state at the app root.
Audit for ergonomics ("what happens when I change it?"), not for features.

When a founder friend asked me how to pick a React Native boilerplate last month, I gave them a test that took me a decade of shipping apps to formulate. It doesn't involve counting features, reading the README, or watching the demo video.

Here's the test: fork the boilerplate, open a timer, and try to remove one thing in 60 minutes.

That's it. If you can, buy it. If you can't, walk away.

Why feature counts lie about boilerplate quality

Every boilerplate landing page reads the same: "Includes auth, payments, database, push notifications, analytics, dark mode, i18n, [15 more features]." Feature counts are the easiest thing to market and the least predictive of quality.

What features on a landing page can't tell you:

How coupled the auth layer is to the DB layer
Whether the payment integration assumes Stripe (fine) or hard-codes Stripe API calls throughout the app (not fine)
How the routing shape will interact with the screens you actually plan to build
What happens when you want to swap the analytics provider

All of these are ergonomic properties. They're invisible until you try to change something.

The strip-down test: remove one thing in 60 minutes

The test I use: fork the repo, then try to remove the auth layer entirely. Not disable, not stub — actually remove it, cleanly, so a new dev looking at the repo wouldn't know auth had ever been there.

Why auth? Because it's the layer boilerplates most often over-integrate. If it comes out cleanly, everything else probably will too. If it doesn't, you're looking at a boilerplate that will fight you every week the project lives.

The 60-minute clock is important. It's not "can you do this" — anyone can, given a week. It's "does the codebase make it easy." A good boilerplate should let you remove a major layer in less time than it takes to grab a coffee and read Hacker News.

Run the same test on payments, on database, on navigation. Whichever one you're most likely to want to swap in your actual project is the layer to prioritize.

What passing the test tells you

If you can strip the auth layer in 60 minutes:

The boilerplate has clean seams between layers
Someone thought about extensibility, not just about features
The codebase respects your future decisions instead of pre-empting them

If you can't:

Layers leak into each other in ways the README doesn't advertise
Your future "let me swap Clerk for Supabase" migration will be a two-week project
You'll be maintaining someone else's opinions about architecture forever

The first is a boilerplate. The second is a fork you'll regret.

Three signals a boilerplate will fail the test

Before you even fork, three signals that tell you the test will fail:

Auth logic sprinkled across screens instead of contained in a service/hook. If AuthContext is imported in 30+ files, removing auth means editing 30+ files. Contain it and the removal is a delete + import fix.
Database queries wrapped in "business logic" functions that also do auth checks. These read as clean at first — one function to fetch a user's data — but they're impossible to reuse if you swap the auth layer. The repository pattern (auth-agnostic data access + a separate auth layer) is what you want.
Navigation coupled to auth state via wrapper components at the root. If your App.tsx has <AuthGate><Router /></AuthGate> and every screen assumes an authenticated user is present, you'll rewrite the router when you strip auth. Auth-aware routing at the route level, not the app root, is more strippable.

These are all defensible design choices for a specific product. They're bad choices for a starter kit that has to work across many products.

Conclusion: audit for ergonomics, not for features

The question "what does this boilerplate include" is the wrong first question. The right first question is "what happens when I want to change it?"

Every boilerplate looks great on day one, when you're using it for exactly the product it was built for. The one you'll want in month three is the one that let you strip the auth layer in an hour when your Clerk trial expired.

Make that the audit. Feature counts will follow. Ergonomics won't.

What's the first layer you'd try to rip out of your current boilerplate — auth, payments, or navigation? Drop a comment with the one that would fight you hardest.