DEV Community: Nikolas M I

Our failed React Native template launch, dissected

Nikolas M I — Wed, 29 Jul 2026 10:16:55 +0000

TL;DR

v1 launch: $29 template, 180 hours of work, $87 revenue, 40% refund rate.
Root cause: shipped a UI kit, marketed as "full-stack."
Rebuild fixed: real Supabase backend, real docs, demo videos, agent-readiness, price tripled, refund policy surfaced.
Refund rate on v2: ~4%.

The setup

We built a React Native template. Twelve screens, Expo, TypeScript, NativeWind, tab navigation, auth screens that looked like Instagram's. What we did not ship:

// src/services/mockApi.ts
export async function getNotes(): Promise<Note[]> {
  return HARDCODED_NOTES;
}

export async function signIn(email: string, password: string) {
  return { user: FAKE_USER, session: FAKE_SESSION };
}

That was our "backend." A .env.example referenced Supabase but nothing in the app actually called it. The landing page used the phrase "full-stack" four times.

What happened at launch

Metric	Value
Launch surface	X, Indie Hackers, small subreddit
First-4-hour visits	231
Sales	5 at $29
Refunds	4
Revenue after refunds	$87
Hours invested	~180

Effective hourly rate: about $0.48.

The angry email

The refund email that mattered, paraphrased:

I thought this was going to save me a week. It saved me maybe an evening. The auth doesn't connect to anything, the API returns hardcoded data, and I still have to build the entire backend. Why did I pay $29 for what's basically a Figma export in TypeScript?

He was right. We had shipped a UI kit and called it full-stack.

The six fixes

1. Real backend, not `mockApi.ts`

The rebuild replaced every mock with real Supabase. Migrations, seed data, RLS policies, Auth flows (email + Apple + Google), Storage with signed URLs, and Edge Functions proxying AI calls.

-- Example: real RLS policy shipped with every table
create policy "Users read their own notes"
  on notes for select
  using (auth.uid() = user_id);

create policy "Users insert their own notes"
  on notes for insert
  with check (auth.uid() = user_id);

If your buyer has to write their first RLS policy after unzipping your template, you have shipped an unfinished product. Reference: Supabase RLS docs.

2. Tripled the price ($29 → $79)

Counterintuitive but repeatable across cohorts. $29 attracted price-shopping customers whose expectations were miscalibrated. $79 attracts senior indies buying back time at a $100+/hour opportunity cost. Refund rate dropped from ~40% to ~4%.

3. Demo video per template

40 seconds, silent, showing:

git clone git@github.com:applighter/ai-voice-notes.git
cd ai-voice-notes
pnpm install
npx expo start

Then sign-up, hero action, data landing in Supabase. Screenshots let skeptical devs assume the worst. Video removes the doubt.

4. 12,000-word docs per template

We wrote 800 words for v1 and 12,000 for v2. The 15× increase doubled conversion. Buyers do not care how many screens you ship. They care whether they can be shipping their version inside 24 hours. That's a docs problem.

5. Ship for agents

The single biggest architectural change. In 2026, buyers point Claude Code, Codex, or Cursor at your repo before they read a file themselves. If the repo doesn't ship:

A CLAUDE.md at the root
Slash commands / skills for the common workflows (add screen, add table, add AI provider)
Real TypeScript types (no any)
Predictable file layout an agent can grep

…the agent flails, the buyer concludes your template is bad. Every current Applighter template ships with skills and slash commands pre-installed, tested against Claude Code, Codex, Cursor, and Windsurf.

6. Refund policy above the buy button

"7-day refund, no questions asked." Refunds went up slightly (the ones we should have honored anyway). Chargebacks went to zero. Chargebacks cost more than refunds — both financially and to your Stripe account health.

v1 vs v2 at a glance

Dimension	v1 ($29)	v2 ($79)
Backend	`mockApi.ts`	Real Supabase (Postgres + Auth + Storage + Edge Functions)
RLS	None	Per-table policies + seed users
Docs	800 words	~12,000 words + video
Demo	Screenshots	40-sec walkthrough
Agent readiness	None	Skills + slash commands
Refund rate	~40%	~4%

What I'd tell 2025-me

Write the docs first. If they're hard to write, the product is wrong.
Price at $79 minimum for anything with a real backend.
Ship a real backend from day one. Mock nothing a buyer would reasonably expect to be real.
Record one 40-second video per template. Silent. Happy path.
Ship for agents. CLAUDE.md, slash commands, real types. This is a moat.
Refund policy above the buy button.

The gap between "nice UI I built in a week" and "template a senior indie will pay $79 for" is roughly three months of unglamorous infrastructure work. Skip any of it and the launch dies quietly.

The longer version of this postmortem — including the comparison against building from scratch — is on my Hashnode blog.

What's the worst launch you've had, and what did it teach you? Drop it in the comments — misery loves company and I'd genuinely like to read them.

Fixture-first prompting: how seed data changes what the model builds

Nikolas M I — Wed, 29 Jul 2026 09:49:42 +0000

TL;DR

The model skims your prompt, reads your types carefully, and treats your seed data as gospel.
Three short happy-path rows produce a demo UI. Twenty messy rows produce a real one.
Write the fixture before the Figma frame and before the prompt.
Ship four fixture variants per entity: populated, empty, loading, error.
Same prompt + different seed = different product.

The single biggest change to my design-to-code workflow this year wasn't a new tool. It was moving the seed data file from the end of a feature ticket to the front. Once the fixture leads, the model starts building the UI the fixture implies — and the fixture, unlike a Figma frame, is something engineers, PMs, and designers can all edit in the same file without merge pain.

Here's the workflow, why it works, and the specific shapes of seed data that make the model produce good vs. bad output.

The design brief the model actually reads is your seed data

When you ask an LLM to build a dashboard, it doesn't read your prompt as tightly as you think it does. It reads:

The prompt (skimmed)
The type definitions (carefully)
The seed / mock data (as gospel — this is what the UI has to accommodate)

If your mockUsers.ts has three users, all with 4-character first names and no avatars, the model builds a UI that assumes short names and shows initials. If your mockUsers.ts has 40 users with a mix of "Amélie", "李", "Björn-Alexander", and one 60-character corporate email address, the model builds a UI that truncates, wraps, and reserves space for avatars — because the data forced it to.

Same prompt. Different seed. Different product.

Before / after: same prompt, two seed files

Prompt (identical in both runs): "Build a customer list page with a search bar and a table."

Seed A (what most people ship as a fixture)

export const customers = [
  { id: 1, name: "Alice", email: "a@x.com", plan: "pro" },
  { id: 2, name: "Bob", email: "b@x.com", plan: "free" },
  { id: 3, name: "Cara", email: "c@x.com", plan: "pro" },
];

What the model built: a table with 4 columns, left-aligned, no empty state, no pagination, no plan badge styling — just plain text.

Seed B (fixture designed to stress-test the UI)

export const customers = [
  {
    id: "cus_9f3a2b",
    name: "Alice Chen",
    email: "alice@acme.co",
    plan: "pro",
    mrr: 149,
    lastActiveAt: "2026-07-28T14:20:00Z",
    signupAt: "2024-03-11T09:00:00Z",
    avatarUrl: "https://...",
    tags: ["enterprise-lead", "champion"],
  },
  {
    id: "cus_1c8d",
    name: "Bob",  // deliberately short — tests min-width
    email: "bob.a.verylonglocalpart@somecompany.example.com",  // tests truncation
    plan: "free",
    mrr: 0,
    lastActiveAt: "2025-11-02T03:11:00Z",  // stale, tests "inactive" styling
    signupAt: "2025-10-30T09:00:00Z",
    avatarUrl: null,  // tests fallback initials
    tags: [],
  },
  // ... 38 more, including one with a right-to-left name, one with a null email
];

What the model built off Seed B: a table with plan badges (because plan was one of a known set), a relative-time formatter for lastActiveAt (because dates were varied and some were old), avatar fallbacks with initials (because one was null), email truncation with a tooltip (because one was long), and a tag chip row under each name.

Same prompt. The seed did all the design work.

A seed-first workflow: fixtures before figma, fixtures before prompt

The order I now run:

Write the fixture first. Before Figma, before a prompt, before a ticket description — write the 15-20 rows of seed data that represent the full messy reality of the domain. Long names. Missing fields. Stale timestamps. One extreme outlier.
Show the fixture to the PM and the designer. This is faster than a mock. Everyone can look at the JSON, argue about whether "tags" is actually a thing, whether MRR should be integer cents or a float, whether we care about right-to-left names. Alignment happens in 20 minutes instead of 2 days.
Then draft the Figma / write the prompt. Both now reference the fixture as the source of truth. Designer sizes components to accommodate the longest string in the seed. Prompt says "build the UI implied by fixtures/customers.ts, using the design tokens in theme.ts."
Model generates. Because the fixture is comprehensive, the UI is comprehensive on the first pass. Iteration count drops.

On our team the average "draft to reviewable UI" time went from ~3 hours to ~50 minutes once we moved to this order. Not because the model got faster — because the inputs got denser.

Anti-patterns: the 3 seed shapes that make AI output collapse

Seeds that reliably produce bad AI code:

The three happy rows. Every field populated, every string short, every date recent. The model builds a UI that only works for demos.
The single-row seed. Model can't infer variability, so it builds no empty state, no pagination, no sort. You'll fix all of these later.
The lorem-ipsum seed. Placeholder text with no semantic hints. "lorem ipsum dolor sit amet" doesn't tell the model whether this is a title, a bio, or a comment. Ambiguous input, ambiguous output.

Good seeds are boring to write and dramatic in effect. Budget 30 minutes per feature for them. It's the highest-ROI 30 minutes in the whole cycle.

A repeatable folder structure

What we settled on across three products:

src/
  fixtures/
    customers.ts          # 15-20 rows, messy realism
    customers.empty.ts    # explicit empty state fixture
    customers.loading.ts  # skeleton fixture (shape only)
    customers.error.ts    # error object fixture
  ...

Every fixture file has four variants: populated, empty, loading, error. The prompt then reads "build the four states for customers using the fixtures in src/fixtures/customers.*" and gets all four screens in one generation pass, instead of one screen that assumes data always exists.

Storybook picks up the fixtures automatically for visual regression. Playwright picks them up for E2E. Designers can open the JSON in a code sandbox and edit values live. One artifact, four consumers, and it lives in the repo where it can be code-reviewed.

If you're setting up a new project and don't want to reinvent this scaffolding, the fixture-per-state pattern is the kind of workflow default that lives inside a good template starter — see the ones on AppLighter for how the fixtures/, stories/, and e2e/ folders wire together on day one so the model has good bones to build against from your first prompt.

The general principle is simple enough to fit on a sticky note: the model doesn't design your product from your prompt. It designs it from your data. So design your data first.

What does your fixture file look like right now — three happy rows, or the messy version? Drop a comment with the nastiest edge case you deliberately seed in.

The design work you must finish before Google Play's 14-day closed test

Nikolas M I — Wed, 22 Jul 2026 09:58:14 +0000

Google Play's 14-day closed test isn't just an ops requirement — it's 14 days when real people will use your app for the first time. If your design isn't ready for that scrutiny, you're getting expensive feedback on the wrong things.

Here's what design should have shipped before day one of the closed test.

Why 'good enough for testers' isn't

The temptation: 'they're just testers, we'll polish for production launch.' What actually happens:

Testers give feedback on rough UI, not the product. You lose the signal.
Screenshots make it to social. First impression matters.
The 14-day counter resets if engagement dips. Rough UX = lower engagement.

Ship the closed test with launch-quality design or you're paying the 3-week price for lower-quality data.

The five artefacts

1. Onboarding flow. Every tester's first 90 seconds. Empty states, permissions requests, initial value proof — all designed, not 'I'll clean it up later'.

2. All error states. Network fail, permission denied, invalid input. Real users hit these on day 1. Placeholder 'something went wrong' text loses trust fast.

3. Play Store listing assets. Screenshots, feature graphic, description. Play requires them before you can even publish to closed testing. Don't leave this for day 13.

4. Empty states for every screen. 'You have no [thing] yet' + 'here's how to get started'. Most closed-test users are seeing your app the first time with zero data — every empty state matters.

5. A visible feedback mechanism. In-app 'Send feedback' button or shake-to-report. Testers WILL find bugs; make it easy to report while they're in the moment.

Designing the in-app feedback loop

Testers who have to remember to email you get around to it maybe half the time. Testers who can tap 'Send feedback' from inside the app respond 5-10x more often.

Design this before day 1:

Persistent 'feedback' entry point (settings screen, help menu, floating button in beta builds).
Feedback form is 3 fields max: (1) What were you trying to do? (2) What happened? (3) Screenshot (auto-attached).
Sends to a dedicated inbox / Slack channel where you triage daily.

Do NOT gate this behind 'rate our app' prompts — those trigger active hostility and are usually a Play policy issue.

Play Console assets — before day 1

Play requires all of the following BEFORE you can start a closed test:

App icon (512x512)
Feature graphic (1024x500)
Minimum 2 phone screenshots
Short description (80 chars)
Full description (4000 chars)
Privacy policy URL

The screenshots specifically catch teams — most don't realise closed testing requires them too, then scramble on day 0. Design should have all six of the above done and reviewed a week before the closed test starts. If wrangling the release pipeline itself is eating your prep time, tools like LetsDeployIt can take the deployment side off your plate so design gets those days back.

Screenshot tip: the closed-test screenshots don't need to be the launch-day marketing screenshots. Ship functional screenshots for the closed test; iterate to marketing-quality between day 7 and day 14 (Play allows updating).

What to change based on 14 days of data

If you built the feedback loop above, you'll have 20-50 feedback items by day 14. Categorise them:

Bugs: engineering fix, don't wait.
Confusion (user didn't know how to do X): design fix, ship a copy or flow change in the next build.
Missing feature: roadmap item, note but don't ship in the 14-day window.
Nice-to-have: roadmap item, deferred.

Aim to ship 3-5 design fixes during the 14-day window. Testers seeing 'oh you fixed my thing' triples their engagement and improves the meaningful-engagement metric Play looks at. Free win.

Practical: the design pre-launch checklist for Play

Before opening the closed-test signup form:

[ ] Onboarding flow: designed, prototyped, reviewed.
[ ] All error states: designed with real copy.
[ ] All empty states: designed with 'get started' guidance.
[ ] In-app feedback mechanism: implemented + tested.
[ ] Play Console assets: all six items ready.
[ ] Screenshots + short description: reviewed for tone.
[ ] Privacy policy URL: live and accurate.

That's 2-3 days of focused design work. Do it before the 14-day counter starts and the closed test becomes what it should be: a high-signal user research phase. Skip it and it's just a 14-day wait.

What's your Play closed test looking like — drop a comment with where you are in the 14 days.

Why "Just Use Claude Code" Isn't a Mobile Strategy

Nikolas M I — Wed, 08 Jul 2026 09:18:10 +0000

TL;DR

Claude Code is a tool, not a mobile app strategy — the strategy is the substrate it runs on.
The parts that break aren't code generation: EAS Build credentials, Supabase RLS contracts, Stripe webhook correctness, and AI keys leaking through EXPO_PUBLIC_*.
An agent can implement any of these correctly — it just won't know it should until the pattern already exists in the repo.
Give Claude Code a well-shaped repo (CLAUDE.md, visible patterns, typed boundaries) and it's 10x faster. Give it a blank folder and it's a liability with autocomplete.

Every React Native thread on Reddit right now has some version of the same take: "why would I buy a template when Claude Code exists?"

Fair question. Wrong framing.

Claude Code is a tool. A mobile app strategy is a substrate. Confusing the two is why so many AI-generated Expo apps die in the TestFlight queue.

Let me be specific about the failure modes.

Where Claude Code alone breaks on mobile

EAS Build is stateful

eas build --platform ios --profile production

That command needs:

Apple ID + team ID
Distribution certificate
Provisioning profile matching the bundle ID
App Store Connect API key
A working eas.json with the right production profile
Metro bundler config that plays nice with your assets

None of this is code. It's account state and CLI ritual. Claude Code can generate a plausible-looking eas.json, but it can't create your certificates, can't upload them to Apple, and can't recover when your provisioning profile expires mid-build.

Supabase RLS is a contract, not a vibe

Ask an agent to "add auth" and you'll often see:

create policy "allow all" on public.users
  for all using (true);

That's not a policy. That's a data breach with a create policy statement in front of it.

Real RLS looks like:

create policy "users read own row"
  on public.users for select
  using (auth.uid() = id);

create policy "users update own row"
  on public.users for update
  using (auth.uid() = id)
  with check (auth.uid() = id);

And that's just the trivial case. Multi-tenant apps, invitation flows, sharing, admin roles — all require policy design before the agent starts writing. The agent can implement your contract. It shouldn't invent it. Docs: Supabase RLS reference.

Payments do not tolerate hallucination

A Stripe webhook handler generated by an agent:

export async function POST(req: Request) {
  const body = await req.json();
  if (body.type === 'checkout.session.completed') {
    await grantLicense(body.data.object.customer_email);
  }
  return new Response('ok');
}

Everything is wrong. req.json() breaks signature verification (you need the raw body). There's no idempotency check. Email is a bad key for entitlement. There's no error handling. And where's the signing secret validated?

Correct version — abbreviated:

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const sig = req.headers.get('stripe-signature')!;
  const raw = await req.text();

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      raw,
      sig,
      process.env.STRIPE_WEBHOOK_SECRET!,
    );
  } catch {
    return new Response('bad signature', { status: 400 });
  }

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object as Stripe.Checkout.Session;
    await upsertLicense({
      stripeCustomerId: session.customer as string,
      productId: session.metadata!.product_id,
      idempotencyKey: event.id,
    });
  }

  return new Response('ok');
}

The point is not that Claude Code couldn't write the correct version. It's that it doesn't know it should until you tell it. That's the strategy — deciding what "correct" looks like before the prompt.

AI provider keys leak by default

If your Expo app imports:

import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: process.env.EXPO_PUBLIC_OPENAI_KEY,
});

You just shipped your OpenAI key to every user of your app. EXPO_PUBLIC_* env vars are bundled into the JS. Anyone can curl your bundle and read it.

The strategy answer: every LLM call goes through a Supabase edge function that holds the key.

// Client
const res = await fetch(`${supabase.functions.url}/summarize`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${session.access_token}` },
  body: JSON.stringify({ text }),
});

// Edge function
Deno.serve(async (req) => {
  const { text } = await req.json();
  const client = new OpenAI({ apiKey: Deno.env.get('OPENAI_KEY')! });
  const stream = await client.chat.completions.create({
    model: 'gpt-4o-mini',
    stream: true,
    messages: [{ role: 'user', content: text }],
  });
  return new Response(stream.toReadableStream());
});

Claude Code can write both halves. It won't know to write the second half unless the pattern is already in the repo.

Where Claude Code is genuinely great

Given a well-shaped repo, Claude Code is transformative. Some concrete wins:

Screen scaffolding. Point it at app/(tabs)/index.tsx and ask for a variant. It preserves imports, styling, and data-fetching patterns.
Migration writing. Give it two existing Supabase migrations. Ask for a third. It matches your style, including RLS.
Edge function templating. Given one AI provider, it can generate an equivalent for another.
Codebase Q&A. "Where does the license grant happen?" — with file:line accuracy.

The requirement: a repo where those patterns are visible. That's what a template gives you.

Comparison

Concern	Just Claude Code	Claude Code + Substrate
Time to first TestFlight	Days–weeks	Same day
RLS + auth	Invented per session	Pre-designed, tested
EAS Build config	You figure it out	`eas.json` profiles included
Payments	Hallucinated handlers	Verified webhook + entitlements RLS
Design	Mean-of-training-data	Brand-tokenized
Agent conventions	Reinvented every prompt	`CLAUDE.md`, slash commands
Long-term maintenance	Code drift	Documented architecture

What "having a strategy" actually means

Decisions made before you prompt:

Distribution — Expo + EAS, which profiles, which channels
Backend — Supabase tables, RLS design, edge functions
AI provider — model, streaming, cost cap, key location
Payments — Stripe web / IAP / hybrid
Design system — typography, tokens, dark mode, motion
Agent conventions — CLAUDE.md, slash commands
Store readiness — privacy manifest, subscription copy

You can build all of this yourself. It's 3–6 weeks of mid-level mobile engineering work per app. That's the honest baseline.

Or you start from a substrate that has it decided already — like the Applighter React Native + Expo templates, which ship with all of the above and a CLAUDE.md that turns Claude Code into a targeted execution engine rather than a random screen generator.

The one-line version

Claude Code is the leverage. A mobile app strategy is the fulcrum. You need both.

If you're building an AI feature, start with a substrate that ships the AI patterns already — AI Voice Notes and Chat with PDF are the two we recommend as starting points.

What are you building right now that hit one of these walls? Drop it in the comments — especially if it was the RLS one.