← All posts

Starting a React Native app with Claude Code or Cursor: why a template beats a blank project

AI coding agents are far more reliable when they work inside an existing codebase with conventions to follow. How to use Claude Code or Cursor with an Expo template, what to put in CLAUDE.md, and the prompts that work.

September 14, 2026 · Thomino

If you've tried building a mobile app with Claude Code, Cursor or a similar agent, you've probably seen both outcomes. Sometimes it produces a working screen in one prompt. Sometimes it invents a component library that doesn't exist, hardcodes colors in six places, installs three packages you didn't ask for, and leaves you with a project you don't understand.

The difference is rarely the model. It's what the model has to work with. An agent given an empty npx create-expo-app project has to make every decision from scratch and will make them differently on each prompt. An agent given a real codebase with conventions written down will follow them.

This post is about the second approach: starting a React Native app from a template and letting the agent extend it.

What goes wrong on a blank project

The failure modes are predictable:

  • No conventions to follow. Should styling be StyleSheet, styled-components or Tailwind classes? The agent picks one per file.
  • Nothing to reuse. Every screen gets its own button, its own card, its own header. The tenth screen looks nothing like the first.
  • Dependency drift. Each new feature is an excuse to install something. You end up with two date pickers and two icon libraries.
  • No theme. Dark mode gets bolted on at the end, and the agent has to touch every file.
  • Wrong versions. Models learned from a snapshot of the ecosystem. Left alone they'll target Expo SDK 50 conventions on SDK 57 and hit deprecations.

None of these are hard to fix individually. Together they turn a weekend project into a cleanup job.

What a template changes

A good template gives the agent three things it can't get from a prompt:

  1. Working examples of every pattern. Forty screens that all use the same Header, the same Card, the same navigation calls. The agent copies what's there instead of inventing.
  2. A component library that already exists. When you ask for a settings screen, the agent finds ListLink, Switch and Section in the components folder and uses them.
  3. A written contract. A CLAUDE.md or .cursor/rules file that says how the codebase works and what the rules are.

The third one is the multiplier. Here's what ours look like.

What's in CLAUDE.md

Our templates ship with a CLAUDE.md at the project root. Claude Code reads it automatically at the start of every session; Cursor picks up the equivalent from .cursor/rules. It's about 300 lines and covers:

The stack, stated plainly. Expo SDK version, React Native version, NativeWind v4, Expo Router with drawer and tabs, Lucide icons, TypeScript. And just as important, what's not included: no Supabase, no RevenueCat, no i18n. Data is local mock content. That one paragraph stops the agent from installing a backend you didn't ask for.

The folder map. Where screens, tabs, contexts, hooks and components live, and how to import them.

Critical rules with examples. These are the ones that matter most:

1. Always use ThemedText for text.
2. Never hardcode colors. Use theme classes (bg-background, text-subtext,
   bg-highlight) or useThemeColors() for JS values.
3. Check /components before creating a new one. Table of "UI need ->
   component to use".
4. Always use CardScroller for horizontal scrolling.
5. Every screen gets a Header. Nested screens get showBackButton.
6. Use the shadow utility, not inline shadow styles.

Each rule has a correct and an incorrect code sample. Agents follow examples better than prose.

A screen layout pattern. One canonical example of a screen, with the imports, so a new screen looks like every other screen.

A testing checklist. TypeScript compiles, lint passes, works in light and dark mode, no hardcoded colors, uses existing components.

You can read the full file in any of our templates after purchase, and the structure is easy to copy for your own projects.

The workflow

Here's how a session actually goes, using Claude Code. Cursor is the same idea with a different chat window.

1. Clone and run it first.

git clone <your-template-repo> my-app
cd my-app
npm install
npx expo start

Open it in Expo Go or a simulator and tap through it. You need to know what's there before you ask for changes, and so does the agent. Two minutes.

2. Start the agent in the project root.

claude

It reads CLAUDE.md. Ask it to summarise the project structure as a warm-up. If the summary is right, the context is loaded.

3. Ask for one screen at a time.

Good prompt:

Add a "Favorites" screen under app/screens that lists the user's saved products. Reuse the Card component and the existing mock products. Add a heart icon to the Header on the product detail screen that navigates to it. Follow the conventions in CLAUDE.md.

Bad prompt:

Build the favorites feature.

The good prompt names the file location, the components to reuse, the data source and the entry point. The agent has nothing to guess.

4. Verify the same way the checklist says.

npx tsc --noEmit
npm run lint

Then open both light and dark mode. Hardcoded colors show up immediately in dark mode as white boxes.

5. Review the diff before moving on.

Read what changed. Look for three things: new dependencies in package.json (ask why), any hex color in a component (ask for the theme class instead), and any new component that duplicates an existing one (ask it to use the existing one).

6. Commit, then next screen.

Small commits per feature mean you can throw one away when the agent goes sideways without losing the rest.

Prompts that work well on a template

  • "Add a screen at app/screens/x.tsx that does Y. Use existing components. Add a Header with a back button."
  • "Change the highlight color to #FF6B00 in both theme files." The CLAUDE.md tells it there are two files to update.
  • "Create a components/forms/PhoneInput.tsx following the conventions in components/forms/Input.tsx."
  • "Replace the mock products in data/products.ts with a fetch from this endpoint. Keep the same shape."
  • "Run npx tsc --noEmit and fix the errors."

Prompts that go badly anywhere

  • "Make it look better." No agent knows what that means.
  • "Add authentication." Which provider? Which screens? The template already has login and signup as UI; say which service to wire them to.
  • "Refactor the app to use Redux." Don't. The template's state is deliberately simple. Add state management where you need it.

Which template to start from

  • If you know what you're building, start from the closest match: ecommerce, marketplace, dating, fitness, social, wallet, booking, AI chat and more. You get the screens, and the agent gets the examples.
  • If you're building something new, start from the Front-End Starter. It's the component library and navigation shell without a specific app on top.
  • If you already know Tailwind from web work, the Uniwind starter uses Tailwind v4 syntax, and your existing muscle memory transfers.
  • Not sure yet? The free template is real code, not a demo, and a good place to try the workflow before buying anything.

Every template is TypeScript, on Expo SDK 57.0.22 as of September 2026, and built and verified on the current Xcode. The agent starts from a project that compiles, which is the whole point.