01 / The Opportunity

Why a small team can compete now.

The advantage is not that app development became effortless. The advantage is that the cost and time required to test a complete business dropped. A non-technical founder can now move from validated idea to live app before a funded team finishes their sprint planning.

02 / Why 2026 Matters

The stores changed the rules in 2026.

The store listing is no longer the final step after marketing. It is part of the content and discovery system. Both Apple and Google made material changes in 2026 that favour well-designed small apps over incumbents with large install bases.

App Store — what changed

Google Play — what changed

Sources: Apple Developer — "Getting featured on the App Store" and "Nominate your app for featuring." Android Developers Blog — "I/O 2026: What's new in Google Play," May 2026. "Battery Technical Quality Enforcement is Here," March 2026.

03 / Opportunity Selection

Choose a product that markets itself.

A good mobile opportunity has a sharp user pain, a visible transformation, and a repeat-use reason. A good mobile opportunity for a non-technical founder in 2026 also has one more quality: it can be demonstrated in 15 seconds without explanation.

The 4-of-6 rule: Do not proceed unless the concept scores strongly on at least four dimensions, including Demo and Payment. A clever feature without distribution or monetization is a project, not a business.

A one-sentence concept brief

For [specific user], the app turns [painful input] into [visible outcome] in [time], and becomes more useful through [repeat-use mechanism].

Validation before code

• Interview 10 target users. Ask for the last time the problem happened, not whether they like the idea.
• Build a clickable prototype and record a 15-second product demo.
• Publish 5–10 concept videos or run a small landing-page test.
• Ask for a commitment: beta signup, deposit, pre-order, or scheduled onboarding call.
• Target 50+ genuine signups before writing a line of production code. If you can't get 50 signups from a landing page, the app won't get downloads either.

04 / The Stack

The full stack.

These are the exact tools across every DreamLaunch build. No variation. Consistency is the shortcut — the stack is already configured, already documented, already debugged. You pick it up and build. Use tools that reduce coordination cost but keep ownership of the product spec, data model, security decisions, and release checklist.

Core layer

Backend layer

Product and revenue layer

Dev tooling

05 / AI Configuration

Cursor rules.

Cursor is only as useful as the rules you give it. Without a project rules file, it guesses at your stack, your conventions, and your preferences — and guesses wrong often enough to slow you down. With these rules, it generates components that drop into the project without correction.

Create .cursorrules in the root of your project and paste the following. Do not trim it — every line is there because we removed something that caused a problem on a real build.

# DreamLaunch Mobile Stack — Cursor Project Rules
# Stack: React Native + Expo SDK 52 + TypeScript (strict) + NativeWind v4 + Supabase + Expo Router v3

You are an expert React Native developer.
Always use TypeScript with strict mode. Never use 'any'.
Never use class components. Always use functional components with hooks.

## Framework rules
- Use Expo SDK 52. Never use bare React Native unless explicitly asked.
- Use Expo Router v3 for all navigation. No React Navigation.
- File-based routing lives in /app directory.
- Shared components live in /components. Screens live in /app.
- Use NativeWind v4 for all styling. No StyleSheet.create() unless unavoidable.
- Tailwind classes only — no inline style objects for layout.

## Data + auth
- Use Supabase for all database operations.
- Import the Supabase client from @/lib/supabase.
- Always use row-level security. Never expose the service role key client-side.
- Auth state lives in a context at @/context/AuthContext.
- Use Supabase realtime subscriptions for live data — not polling.

## Component conventions
- Component files use PascalCase. Utility files use camelCase.
- Export components as named exports, not default.
- Props interfaces defined above the component, named [ComponentName]Props.
- Use React.memo() for list item components only.
- No prop drilling beyond 2 levels — use context or Zustand.

## State management
- Local UI state: useState.
- Cross-component state: Zustand stores in /store directory.
- Server state: TanStack Query (React Query) with Supabase fetcher.
- Never store auth tokens manually — use Supabase session.

## Payments
- RevenueCat SDK is the only payment handler. Import from react-native-purchases.
- Paywall component lives at @/components/Paywall.tsx.
- Always check entitlement status before showing premium features.
- Never implement custom receipt validation.

## Error handling
- Use Sentry.captureException() for all caught errors in production paths.
- User-facing errors show a toast (via Burnt library), not an alert().
- Never swallow errors silently.

## Performance
- FlashList instead of FlatList for all scrollable lists.
- Images use expo-image, not the built-in Image component.
- Use useMemo and useCallback only when profiling shows it helps.
- Avoid anonymous functions in JSX render paths for list items.

## File generation
When creating a new screen, always include:
1. Types file alongside the screen
2. A loading state
3. An error state
4. A proper KeyboardAvoidingView if the screen has inputs

06 / Core Config Files

Core config files.

These files go into every project on day one. They take 20 minutes to set up manually. Copy the templates, adjust the three or four values specific to your app, and move on. Keep one source of truth — every screen has a defined success and failure behavior before anyone writes a component.

app.config.ts

import { ExpoConfig, ConfigContext } from 'expo/config';

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  name: 'Your App Name',
  slug: 'your-app-slug',
  version: '1.0.0',
  orientation: 'portrait',
  icon: './assets/icon.png',
  scheme: 'yourapp',          // deep link scheme
  userInterfaceStyle: 'automatic',  // supports dark mode
  ios: {
    supportsTablet: false,
    bundleIdentifier: 'com.yourcompany.yourapp',
    buildNumber: '1',
  },
  android: {
    package: 'com.yourcompany.yourapp',
    versionCode: 1,
    adaptiveIcon: {
      foregroundImage: './assets/adaptive-icon.png',
      backgroundColor: '#ffffff',
    },
  },
  plugins: [
    'expo-router',
    'expo-notifications',
    ['@sentry/react-native/expo', { organization: '...', project: '...' }],
  ],
  extra: {
    supabaseUrl: process.env.EXPO_PUBLIC_SUPABASE_URL,
    supabaseAnonKey: process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY,
    revenueCatApiKey: process.env.EXPO_PUBLIC_REVENUECAT_KEY,
    eas: { projectId: 'your-eas-project-id' },
  },
});

lib/supabase.ts

import { createClient } from '@supabase/supabase-js';
import AsyncStorage from '@react-native-async-storage/async-storage';
import { AppState } from 'react-native';

export const supabase = createClient(
  process.env.EXPO_PUBLIC_SUPABASE_URL!,
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY!,
  {
    auth: {
      storage: AsyncStorage,
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: false,
    },
  }
);

// Keep session alive when app returns from background
AppState.addEventListener('change', (state) => {
  if (state === 'active') supabase.auth.startAutoRefresh();
  else supabase.auth.stopAutoRefresh();
});

eas.json — build profiles

{
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview":     { "distribution": "internal" },
    "production":  { "autoIncrement": true }
  },
  "submit": {
    "production": {
      "ios":     { "appleId": "your@email.com", "ascAppId": "YOUR_APP_ID" },
      "android": { "serviceAccountKeyPath": "./google-play-key.json", "track": "internal" }
    }
  }
}

07 / Build Shortcuts

Build shortcuts.

Every command that runs more than twice a week gets a shortcut. These are the package.json scripts and shell aliases that make the day-to-day flow fast without memorising flags. Automate repeatable steps — but keep a manual preflight checklist for every release.

package.json scripts

{
  "scripts": {
    "start":          "expo start",
    "ios":            "expo start --ios",
    "android":        "expo start --android",
    "type-check":     "tsc --noEmit",
    "lint":           "eslint . --ext .ts,.tsx --fix",
    "build:dev":      "eas build --profile development --platform all",
    "build:preview":  "eas build --profile preview --platform all",
    "build:prod":     "eas build --profile production --platform all",
    "build:ios":      "eas build --profile production --platform ios",
    "build:android":  "eas build --profile production --platform android",
    "submit:all":     "eas submit --platform all",
    "update":         "eas update --branch production --message",
    "db:types":       "supabase gen types typescript --linked > types/supabase.ts",
    "db:push":        "supabase db push"
  }
}

Shell aliases

# Expo
alias es="expo start"
alias ec="expo start --dev-client"

# EAS
alias bp="eas build --profile production --platform all"
alias bios="eas build --profile production --platform ios"
alias band="eas build --profile production --platform android"
alias sub="eas submit --platform all"

# Supabase
alias dbt="supabase gen types typescript --linked > types/supabase.ts"

# OTA push (usage: ota "fix login bug")
ota() { eas update --branch production --message "$1"; }

OTA vs full build — the rule

08 / Core Product Loop

Build the loop before the app.

The best launch version gets a user to a meaningful result quickly, then creates a reason to return or share. Every screen that doesn't directly improve arrival, activation, or return has to earn its place — or wait until after launch.

Activation definition: Choose one event that means the app delivered its promise. Avoid vanity definitions such as account_created, onboarding_completed, or notification_enabled. Those are steps toward value. They are not the value.

Design for proof

The product should generate evidence of value: a result card, progress chart, comparison, personalised plan, transformed asset, or interactive moment. This artifact can power retention, referrals, store screenshots, and creator content. If the app doesn't produce something a user can see and share, add a feature that does — before worrying about anything else.

09 / Shipping System

The five-week plan.

The schedule protects the core loop. Every feature must earn its place by improving activation, retention, monetization, or demonstrability. Week 4 is where most founders want to start. Starting in Week 4 is why most founders are still building six months later.

10 / Store Launch

Package the release as a story.

Featuring is never guaranteed. The goal is to make the app easy for editors and users to understand, trust, and recommend. The store listing is part of the distribution system — not an afterthought after the product is built.

Nomination outline

• One sentence: the user problem and differentiated outcome.
• What is launching: new app, significant enhancement, or timely content.
• Why now: cultural moment, seasonal relevance, new platform capability, or meaningful innovation.
• Proof of quality: design, accessibility, privacy, localisation, and early user feedback.
• Exact availability date and regions.

Submit early. Apple recommends at least two weeks of lead time and suggests up to three months for wider featuring consideration. Submit the nomination before the app is even in review.

Custom product pages — the 2026 organic opportunity

Create a distinct CPP for each major search intent your app serves. Each needs: a unique headline that matches the search term, a screenshot set showing the relevant use case, and an app preview tailored to that intent. These now rank organically — the same as optimising a landing page for a keyword, but inside the App Store.

11 / Product-Led Distribution

Content that demonstrates the product.

The highest-quality organic content does not hide the app until the final frame. The product is the entertainment, the proof, or the transformation. A video is successful when the viewer understands what the app does, who it is for, and why they should try it. Optimise for attributed installs and activated users — not views alone.

The best organic content loops back to the store. Every video should end with a clear next action: a link in bio, a comment CTA, or a pinned creator post. Track every source with attribution links so you know which format produced installs, not just views.

12 / Creator Operating System

Run creators like an experiment portfolio.

A small group will usually produce a disproportionate share of results. The system must identify, coach, and scale them quickly — before the content gets stale or the window closes. The goal is not the best single video. It is a consistent pipeline of demonstrations across multiple creators, languages, and formats.

Minimum creator CRM

Track the following for every creator, every week:

• Identity: creator, language, country, audience geography, niche, follower band.
• Performance: posts, views, saves, comments, store visits, installs, activated users, paid users.
• Creative: format family, hook type, product moment, CTA, posting date, notes.
• Status: sourcing / trial / active / coached / scaled / paused / exited.

Compensation principle: Pay enough base compensation to respect production work, then use clearly defined bonuses for outcomes you can verify. Avoid rewarding raw views when your real objective is activated or paying users.

13 / Monetization

Revenue setup and subscription design.

The difference between an app that generates revenue and one that doesn't is usually not the product. It's whether the revenue infrastructure was built in Week 3 or Week 7. Users often reject a trial because the commitment feels unclear. A strong paywall explains the outcome, timing, price, renewal, reminder, cancellation, and plan choice — without hiding material terms.

RevenueCat setup checklist

Paywall design — what actually converts

Show the paywall after the first successful core-loop completion. The user has just received the value — motivation to pay is highest at exactly this moment. Never gate onboarding. Offer a 3-day free trial. Trial users convert at 2–3× the rate of direct purchases.

14 / Geography and Localisation

A viral country is not always a valuable country.

Track where attention lands, whether users can pay, what the app costs to serve, and whether the content promise survives translation. The creator's location does not guarantee the audience's location. A video that generates 500K views from a geography where your paywall converts at 0.1% is noise — not a signal to scale.

Localisation sequence

Start with the store listing and creator language, then localise onboarding, pricing presentation, support, and the product itself. Translate meaning and cultural context — not only strings. The localisation sequence follows the funnel: fix discovery first, then activation, then retention.

• Require a country-level cohort that shows activation and acceptable unit economics before scaling spend.
• Do not scale a format internationally because it produced views once.
• Set a clear threshold: minimum 100 activated users in a geography before committing to that market.

15 / Measurement

The weekly app growth scorecard.

A single operating view should connect distribution, product behaviour, monetization, retention, and cost. One winning metric is not enough — a paywall test that lifts trial starts but damages paid conversion, refunds, or retention is not a winner.

Experiment card template

Hypothesis: If we change [one variable] for [one segment], then [primary metric] will move from [baseline] to [target] because [reason]. Guardrails: [retention, refunds, quality, cost]. Decision date: [date].

One experiment at a time. One segment at a time. One primary metric. Track guardrail metrics alongside the primary — if any guardrail moves adversely, the experiment is not a winner regardless of the primary metric result.

If you're below benchmarks in Week 8

Below a 2% trial-to-paid rate in Week 8 is almost always one of three things: paywall timing (too early or too late), pricing anchor (monthly shown first or priced wrong), or trial length (too short for users to experience the core value). Change one variable at a time. PostHog's funnel view shows exactly where users drop.

16 / Launch Control

The 72-hour launch checklist.

The launch is a controlled release with fast observation and clear rollback decisions. The first 72 hours are for learning whether the system behaves under real demand. Do not manufacture scale before the funnel is observable and safe.

Stop-the-line conditions

• Purchases or entitlements fail, users are charged incorrectly, or restore purchase is broken.
• A privacy disclosure is inaccurate or sensitive data is exposed.
• Crash, latency, moderation, or AI safety failures prevent the promised outcome.
• Creator content makes claims the product cannot support.
• A geography generates high AI inference cost with no plausible monetization path.

DreamLaunch Studio — dreamlaunch.studio — System built from 10+ production app launches, 2024–2026. Sources: Apple Developer documentation on App Store featuring. Android Developers Blog, I/O 2026 announcements, May 2026.