Sigma Stack
3 min read

The React Native Starter Setup I Use to Ship Apps in Days, Not Weeks

By Arslan Shaukat

React NativeExpoProductivity

Every time I start a new React Native app, the first two weeks look identical: wire up navigation, set up theming, add authentication, integrate payments, decide on a folder structure, and configure TypeScript strictly enough that it actually catches bugs. None of that is the product. It's tax.

After shipping a few apps I stopped paying that tax twice. I built a starter that has all of it solved on day zero, and now every new idea begins from a running, typed, themeable app instead of an empty create-expo-app.

What "day zero" should already include

A starter earns its place when it removes decisions you've already made a dozen times. Mine ships with:

  • Expo + TypeScript in strict mode, so the compiler catches the class of bugs you'd otherwise find in production.
  • Typed navigation with a screen structure that's ready to extend — no any route params.
  • Auth wired in (Supabase), including the loading and signed-out states most tutorials skip.
  • A paywall scaffold with RevenueCat, so monetization isn't an afterthought bolted on at the end.
  • A design-token theme system for light and dark — no magic numbers scattered across StyleSheet calls.

The point isn't the specific libraries. It's that each of these is a decision you only want to make once.

Architecture that survives feature #20

Most boilerplate rots because it's organized by type — a giant components/ folder, a giant screens/ folder — so by feature #20 nothing lives near anything it's related to.

A feature-based structure scales better:

src/
  features/
    auth/
    paywall/
    settings/
  components/   // truly shared, dumb UI
  lib/          // clients, helpers
  theme/        // tokens

Each feature owns its screens, components, and logic. Shared UI stays genuinely shared. When you delete a feature, you delete one folder — not a scavenger hunt across the repo.

Theming without magic numbers

Hardcoded hex values and padding: 16 everywhere are how apps drift out of consistency. Define tokens once and reference them:

export const theme = {
  color: { bg: "#0A0A14", text: "#ECECF5", accent: "#7C7AF5" },
  space: (n: number) => n * 8,
  radius: { md: 12, lg: 18 },
};

Now a redesign is a token change, not a find-and-replace across fifty files. Dark mode is just a second token set.

How much time this actually saves

The honest answer: one to two weeks per app. Not because the code is hard, but because the decisions are slow and the integration glue (auth states, paywall entitlements, navigation typing) is fiddly to get right. Getting it right once and reusing it is the entire game for a solo developer.

If you'd rather not rebuild this from scratch, it's exactly what my React Native Starter is — the same foundation, battle-tested on shipped apps, running on your machine in under ten minutes.

Takeaways

  • Treat the first two weeks of every app as a reusable asset, not repeated work.
  • Organize by feature, not by file type, so the codebase scales.
  • Centralize design tokens so consistency and theming are free.
  • Solve auth and payments once — they're where the fiddly edge cases live.

Skip the boilerplate

Production-ready React Native starters and UI kits — buy once, clone, and start on the feature that matters.

Browse the templates

More

Keep reading