npx create-expo-app gets you a running Expo project in about thirty seconds. What it does not get you is a shippable product: no authentication, no subscriptions, no push, and usually no store build config. An Expo boilerplate (or starter kit) is the next layer—pre-wired product systems on top of Expo's scaffold—so your first real commit is a feature, not another week of plumbing.

This guide defines what "boilerplate" means in the Expo world, compares it to create-expo-app and to a full starter kit, and gives you a buyer checklist so you can tell integrated from marketing.

Key Takeaways

• create-expo-app is a scaffold, not a product: Expo Router, TypeScript, and demos—not auth, IAP, or push (Expo docs).
• An Expo boilerplate / starter kit should ship the recurring systems (auth, payments wiring, push, EAS) you would otherwise rebuild on every app.
• Judge kits on honesty: RevenueCat integrated (key + feature flag) is not the same as "subscriptions work out of the box."
• Treat "zero setup subscriptions" as a red flag; store products, sandbox, and dashboard config are still your job.
• CodeBaseHub's Expo kit fits when you want Firebase Auth and OneSignal wired, RevenueCat integrated behind a flag, and an honest path to first feature—not magic billing.

Expo boilerplate vs starter kit vs create-expo-app

People use these terms interchangeably. For buying decisions, keep them separate.

Official create-expo-app is the right first step when you want Expo's recommended toolchain without inheriting someone else's product assumptions. Expo documents templates such as default (multi-screen apps with Expo Router and TypeScript), blank / blank-typescript, tabs, and bare-minimum (create-expo-app reference). That is scaffolding excellence—not monetization.

A boilerplate sits between "empty repo" and "ship tomorrow." Some free options stop at architecture and tests. Others sell the word "boilerplate" while shipping a full kit. Always read the feature list against the table above, not the marketing headline.

A starter kit is the honest name when auth, payments wiring, and push are included. If you are comparing options at that level, the React Native starter kit overview is a useful lens for what "production-oriented" should mean on Expo.

What create-expo-app gives you (and what it doesn't)

What you get

From Expo's own tooling, a fresh project can include:

• Expo CLI and a working managed (or bare-minimum) workflow
• Expo Router and TypeScript on the default/tabs-style templates
• Demo screens and a modern React Native / React pin for the current SDK
• Optional --example apps that demonstrate a single integration pattern
• As of recent SDKs, agent context files such as AGENTS.md / CLAUDE.md so AI editors understand Expo conventions (Expo create-expo-app docs)
• A path to store builds via EAS Build once you add identifiers and profiles yourself

That is a strong foundation for learning and for greenfield UI. It is also why teams underestimate the remaining work: the app looks real on day one.

What you still have to build

A paid consumer app almost always needs the same systems the official template does not ship:

1. Authentication — sign-up/sign-in, session persistence, protected routes, account deletion when accounts exist (Apple App Review Guidelines cover account deletion and login requirements)
2. Payments / paywall — store products, receipt/entitlement handling, restore purchases (often via a layer such as RevenueCat)
3. Push notifications — provider, credentials, permission UX, token ↔ user binding
4. Data / backend — storage, security rules, and a clear client vs server boundary
5. Builds & store config — bundleIdentifier / package, eas.json, icons, splash, signing
6. Compliance paperwork — privacy policy, data disclosures, age rating, screenshots

We audited a default Expo project in detail in From create-expo-app to App Store: What's Still Missing: demo screens and tooling yes; auth, payments, and push code no; store identifiers and eas.json typically missing until you add them. Use that post when you want the greppable inventory; this one focuses on when a boilerplate or kit is the rational next step.

Bottom line: create-expo-app answers "how do I start an Expo app?" An Expo boilerplate or starter kit answers "how do I stop rebuilding the same six systems?"

Checklist: what a serious expo boilerplate should include

Before you buy or fork anything labeled an expo boilerplate, score it against this list. Prefer evidence in the repo (imports, env examples, feature flags) over landing-page adjectives.

Must-have (for a paid Expo app)

Nice-to-have

• Localization / RTL scaffolding
• Dark mode already themed beyond the Expo default
• Crash reporting / analytics hooks
• AI editor context (AGENTS.md, MCP configs) beyond what create-expo-app already generates
• Cloud Functions or Remote Config for server-side and flags

Payments honesty check (do not skip)

For RevenueCat-style setups, the trustworthy claim is:

RevenueCat / paywall integrated — open with your API key + feature flag.

That means the SDK, paywall component, and gating path exist in the codebase. It does not mean App Store / Play products, RevenueCat offerings, or sandbox purchases work without your dashboard work. If you need the step-by-step after the kit, use How to Add RevenueCat Paywalls to an Expo App.

How to evaluate before you buy (red flags)

Use this pass after the checklist. It catches kits that look complete in screenshots and fall apart in week two.

1. SDK currency

Expo ships new SDKs on a regular cadence and supports each for roughly a year. An unmaintained boilerplate is not a head start—it is a migration you inherited. Confirm the advertised Expo SDK and React Native pin match something you are willing to upgrade from.

2. Claim honesty: integrated vs live

"Zero setup subscriptions" should never be a positive claim you believe. Store review, product IDs, sandbox testers, and entitlement mapping are not optional. A kit that admits key + feature flag is usually the more senior product.

3. License and commercial use

Can you ship client apps? Unlimited apps? Attribution required? Agency work forbidden? Read the license before the feature matrix.

4. Update policy

Lifetime updates? Expo SDK upgrades included? Slack/email support? A one-time purchase with vague "updates forever" and no changelog is riskier than a clear policy.

5. Diff cost

Open the repo (or trial) and ask: how many days to delete what you do not need vs how many days to build what is missing from create-expo-app? Kits win when your app resembles the kit's assumptions (accounts + subscriptions + push). Kits lose when you would rip out half the stack.

6. AI-context is table stakes now

Because official create-expo-app can generate agent markdown and related settings, "works with Claude Code / Cursor" alone is no longer a differentiator (Expo docs). Prefer kits that add service-aware tooling (real MCP servers against your Firebase / RevenueCat / EAS) on top of docs files.

When CodeBaseHub fits (honest CTA)

Choose CodeBaseHub when you already know you will ship accounts, a subscription paywall, and push, and you would rather inherit those systems than re-implement them.

What the Expo starter kit is:

• Firebase Auth wired — email, Google, and Apple sign-in patterns with protected routes
• OneSignal wired — push integration in the app, ready for your credentials
• RevenueCat + paywall integrated — add your API keys, enable the feature flag, configure products/offerings in RevenueCat and the stores
• Expo Router, TypeScript, EAS Build profiles, localization scaffolding, and AI editor context plus MCP servers for day-to-day work

What it is not:

• Not "zero setup subscriptions" — you still own store products, RC dashboard setup, and sandbox testing
• Not a claim that deep linking or every edge-case notification path is finished for your product
• Not a substitute for App Store / Play Console work, privacy disclosures, or review

If your app does not charge money and does not need accounts, stay on create-expo-app and build only what you need. If you are learning React Native, build auth and push yourself once on purpose. If you need exotic native modules as the core product, validate those first—then decide whether a managed Expo kit still fits.

For teams that do fit: start from the wired Expo app at www.codebasehub.pro/expo-starter-kit, then spend your time on the feature that makes the product yours.

FAQ

Is an Expo boilerplate the same as a React Native boilerplate?

Not always. An Expo-first kit assumes the managed workflow, Expo Router, and EAS. A generic React Native boilerplate may target the bare RN CLI, different navigation, and native folders you maintain yourself. Prefer Expo-specific kits if you are committed to Expo.

Do I still need App Store and Google Play work after buying a kit?

Yes. Bundle IDs, signing, store listings, screenshots, privacy labels, and subscription product setup remain yours. A kit shortens engineering; it does not replace store accounts or review.

Can create-expo-app replace a paid starter kit?

For learning, prototypes, and apps without auth/payments/push—often yes. For subscription consumer apps, the kit's value is the pre-wired systems and documented go-live path, not the empty App.tsx.

What does "RevenueCat integrated with a feature flag" mean in practice?

The purchases SDK and paywall UI are in the codebase and gated so you can develop without charging. Going live means adding keys, enabling the flag, and finishing RevenueCat + store configuration—not installing billing from scratch. Details: RevenueCat paywalls on Expo.

Should I buy a kit only for AGENTS.md?

No. Official templates increasingly ship agent context. Buy for auth, payments wiring, push, and EAS—or do not buy.

Conclusion

An Expo boilerplate is only useful when it closes the gap create-expo-app leaves open: authentication, subscription wiring, push, and store-ready builds. Expo's official CLI remains the best scaffold (docs); it is not a product shell. Use the checklist above, reject "zero setup subscriptions" marketing, and prefer kits that say integrated + key + feature flag when they mean it.

If that is the gap you are staring at, the honest next step is a wired Expo base—not another blank template. See the CodeBaseHub Expo starter kit when Auth and OneSignal should already be connected and RevenueCat should be one flag away from testing.

References

1. Expo — create-expo-app
2. Expo Router introduction
3. EAS Build introduction
4. Apple — App Review Guidelines
5. RevenueCat — Expo installation
6. CodeBaseHub — From create-expo-app to App Store: What's Still Missing
7. CodeBaseHub — How to Add RevenueCat Paywalls to an Expo App
8. CodeBaseHub — Expo starter kit
9. CodeBaseHub — React Native starter kit