DEV Community: Chris F A

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.

DEV Community: Chris F A

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

TL;DR

The Finder problem: 400 artifacts, no naming convention

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

A naming + tagging scheme that survives 6 months

Release notes that write themselves from artifact metadata

The one Notion / Linear pattern that beat every other tool

The meta-lesson

Cutting React Native template support 70% with docs

The audit (do this first)

The four-mode structure

The five rules

Operational loop

Results

What we didn't do

Reference docs I used

The Boring React Native Stack for New Founders

TL;DR

Why "boring"

The client

Expo SDK 54 (managed workflow)

Expo Router

NativeWind v4

Data layer

TanStack Query v5 for anything that touches the network

React Hook Form for forms

Motion: Reanimated 4.1

The backend: Supabase, all of it

Row-Level Security (non-negotiable)

Edge Functions for secrets

Payments: Stripe (one-time, not subscriptions)

Builds: EAS

Comparison table

What we deliberately omit

The AI stack question

The playbook

Or: skip steps 1–5

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

The new handoff

What makes a spec AI-legible

Where design still has to be in the room

The design-to-Claude-Code checklist

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

Sell Templates vs SaaS — 12 Months of Real Numbers

Sell Templates vs SaaS — 12 Months of Real Numbers

TL;DR

The 12-month table

The template stack

Where SaaS beats templates

Where templates beat SaaS

The revenue mix

The uncomfortable parts

The math

Related reads on this blog

External refs

Verdict

The 60-Minute Boilerplate Strip-Down Test

Why feature counts lie about boilerplate quality

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

What passing the test tells you

Three signals a boilerplate will fail the test

Conclusion: audit for ergonomics, not for features