DEV Community: Nikolas M I

Our React Native Template Refund Policy: What It Cost

Nikolas M I — Fri, 14 Aug 2026 08:25:51 +0000

TL;DR

7-day, no-questions-asked refund on every React Native template, processed within 2 business days.
Industry standard in premium mobile templates is "all sales final."
Six-month refund rate: 3.8% of paid orders at a $79 price point.
Blended cost: roughly 4% of gross revenue.
Zero public complaints, zero chargebacks, and the highest-signal product feedback we get.

When we launched Applighter, we picked a refund policy that made two separate advisors tell us we were making a mistake: 7 days, no questions asked, processed in under 48 hours. The industry standard for premium mobile app templates is closer to "no refunds, all sales final."

This post is the honest accounting: what the policy says, what our refund rate turned out to be, what it cost in real dollars, and why we would ship the same policy again on day one.

What "no questions asked" actually means

Most refund policies for digital source code are written like a legal minefield. Ours fits on a single screen:

You buy a template. You get source code repo access instantly.
Within 7 days from the receipt date, you email support with the word "refund" and your order ID.
We process within 2 business days. Stripe takes another 5–10 for the money to land. That part is out of our hands.
We do not ask why. No survey. No "wait, let us fix it" retention flow. The template is refunded and access is revoked.

The one thing we do not refund is third-party API spend. If you already used the template with your OpenAI key and burned $12 of credits, that money is gone at OpenAI, not with us. We can't refund cash we never received.

That is the whole policy. There is no "unless you have downloaded the code" clause, because of course you have downloaded the code. That is what you paid for.

The industry standard is nothing like this

Vendor	Refund Window	Conditions
Applighter	7 days	None. No questions.
Instamobile	Case-by-case	No refunds on bundles. You lose rights to the code.
Typical CodeCanyon author	14 days	"Not as described"; Envato adjudicates
Typical Gumroad seller	Author-defined	Ranges from "none" to "30 days no-questions"
Typical premium boilerplate	0 days	All sales final

The most common posture is "no refunds." The second most common is "refund only if the code does not match the demo," which is unfalsifiable in practice because the demo can always be reframed to match whatever ships.

We picked 7-day no-questions anyway.

Why we did it

We sell to indie developers and small teams who have been burned by AI-generated boilerplate and want a foundation a senior engineer would ship. That buyer is not shopping on price. They are shopping on trust.

1. The buyer cannot inspect the product before buying. With a physical product you pick it up. With SaaS you start a trial. With a source-code template you get a demo video, a feature list, and a screenshot. You have no way to know until you clone the repo whether the code is production-grade or the same AI-shaped mess you were trying to escape. A generous refund policy is the only way we can honestly say "check for yourself" in a market where that check requires purchase.

2. Every objection works in our favor if we're right about the product. If the template is what we claim (layered architecture, RLS reviewed, Expo current, designer-vetted UI) the refund rate should be low. If it isn't, the refund rate tells us so quickly and painfully, and we fix the product. The only universe where the generous policy hurts us is the one where our product is bad, and in that universe we deserve to hurt.

3. Refund friction is negative marketing. Every "we don't do refunds" post from a template vendor generates a Reddit thread within 24 hours. We had no interest in being on the other side of that conversation.

What the refund rate actually was

Here is the number nobody wants to publish. Over the first six months, our refund rate against paid orders sat at 3.8%. That includes every request, valid or otherwise.

The most common reason (inferred from the handful of buyers who added a note despite us not asking) was "wrong template, meant to buy a different one." Second was "changed my mind before starting the project." Actual code-quality complaints were rare enough to count on one hand.

At a $79 price point that's roughly $3 lost per paid order before Stripe fees. Stripe does not refund its fixed per-transaction fee, so the effective cost is closer to $3.30. We treat it as a marketing line item. For every $30 spent on Google Ads, one refund costs the equivalent of ten click-throughs.

There's a known data point in the digital-products community: a Dev.to writeup from last year reports ~40% refund rates at $29 and ~4% at $79 for a comparable template. Our number lines up almost exactly with that curve.

The right customer for a premium template is not price sensitive but time sensitive, and price signals seriousness. Cheap templates get impulse buys and impulse refunds; a $79 sticker filters for the buyer who has actually decided to ship something.

What it actually cost us

Refunded revenue. At 3.8% and an AOV of $79, roughly $3 per paid order. Over six months this was a four-figure number. Not nothing, but small compared to ad spend.

Stripe fees. Stripe keeps the fixed 30¢ per transaction on refunded orders and refunds the percentage portion. Small but real.

Support time. Five-minute email round trip plus one click in the Stripe dashboard. No self-serve refund flow. Maybe 90 minutes per month total.

Opportunity cost. The biggest hidden cost is the buyer who would have accepted store credit but took the cash and vanished. We do not push back. If the policy says "no questions," offering a store-credit alternative violates the spirit of it.

What it did not cost: brand trust, negative reviews, or Reddit threads. Six months, zero public complaints about the refund process, every request resolved inside the promised window.

Total blended cost: roughly 4% of gross revenue.

The counter-intuitive benefits

Refund requests are the highest-signal feedback you get. Nobody who is happy tells you why. Refund requests come with implicit information even without a question attached. Which template was refunded, whether the buyer opened the docs, whether they cloned the repo. When we saw two refunds in one week from buyers who never opened the setup docs, we knew the docs were too easy to miss, and we fixed the onboarding email.

A generous policy pre-qualifies your buyer. The buyer who thinks "seven days, that's plenty of time to know" is exactly who you want. The buyer who thinks "seven days isn't enough" is telling you they plan to sit on the code for months before evaluating it, which means they are not going to ship, which means they end up unhappy regardless.

The support inbox gets easier. When "I want a refund" is a two-word conversation instead of a negotiation, the emotional temperature drops. Zero hostile emails in six months. Vendors with strict policies routinely deal with disputes and chargebacks, and chargebacks are worse than refunds by every metric: Stripe fees, dispute time, reputational damage.

When a generous refund policy is wrong

We would not recommend this in every context.

Under $30. Cheap products attract impulse buyers who refund at rates approaching 40%. The math does not work. Raise the price or tighten the policy. We chose the former.

Significant marginal cost per sale. Digital source code is essentially zero marginal cost, which is why we can absorb the rate. A vendor shipping physical hardware could not.

When the buyer consumes full value inside the window. Course sellers offering 30-day refunds have to build anti-abuse (watching >50% voids it) or the rate approaches 100%. Source code is different. Value is realized over months of shipping the actual app, not in the first week of reading it.

When you can't hit the turnaround. A 7-day policy that takes 30 days to process is worse than no policy. We commit to 2 business days because we know we can hit it every time.

The policy only works because of the product

Refund policy is not the first line of defense. It is the last. Everything else is designed to reduce the need for it: full TypeScript source you can inspect, a Supabase backend with reviewed Row Level Security policies instead of leaving access rules as an exercise for the buyer, and Expo kept on the current stable release rather than pinned to a version from two years ago. You can see how that shakes out across the template catalog.

A generous refund policy without a product to back it up would bleed us dry. A great product without a generous refund policy would push part of the market to competitors who trust their buyers more. Neither alone is enough.

FAQ

Do you refund if I already deployed to production?
Yes. No clause tied to deployment. Within 7 days, you can refund. We ask that you stop using the code, but there is no technical mechanism forcing it.

Refunds after the 7-day window?
No, and this is the one place we hold the line. Extending case-by-case erodes the policy for everyone.

Do you refund third-party costs?
No. If you spent $50 on your OpenAI key, that money is at OpenAI, not with us.

Does refunding once block me from buying again?
No penalty. Each purchase is independent.

The bottom line

The policy costs roughly 4% of gross revenue. In exchange: a filter that pre-qualifies serious buyers, feedback signal we would not otherwise receive, a support inbox that stays calm, and a story we can tell publicly without flinching. We were told this policy was reckless. Six months in, it is one of the operational decisions we would change least.

If you sell a digital product: pick the most generous policy your unit economics can survive, publish it in plain language, and honor it without exception.

What's your refund policy, and what has it actually cost you? Drop the number in the comments. Almost nobody publishes theirs, and I'd genuinely like to see how 3.8% compares.

We Published 118 Blog Posts With Zero Writers. Here's the Pipeline.

Nikolas M I — Wed, 12 Aug 2026 07:58:09 +0000

TL;DR

Publishing surface is a REST endpoint, not a CMS. POST /api/outrank/webhook, bearer token, schema validated, revalidateTag() on write.
Automate the mechanical, keep humans on judgment. Most content ops teams do this backwards: humans proofreading for length, machines picking topics.
Ground drafts in your actual repo. A post that cites real file paths reads completely differently from a generic AI post. This is the whole trick.
Allow the AI crawlers in robots.ts. GPTBot, Claude-Web, PerplexityBot.
Honest caveat: the first three months of building this cost more than three months of hiring a writer.

Applighter has published 118 blog posts, ranks for hundreds of long-tail queries, and does not employ a single content writer.

This is not a growth-hack post. It's what SEO for developer tools actually looks like when you're a two-person team selling React Native templates and the marketing budget is whatever is left after Stripe fees.

Why we couldn't just hire a writer

Every "SEO for SaaS" guide assumes a content team, or at minimum a fractional writer at $500 a post. Selling templates at $99–$299, that math never worked. At 4 posts a month we'd need to sell one extra license per week just to break even on writers. That's before agency margins, before editorial overhead, and before the reality that most freelance writers cannot tell the difference between EAS Build and expo prebuild.

The alternative most indie teams pick is "no blog," and then they lose to competitors who show up when a developer searches "supabase vs firebase for react native."

So we rebuilt the operation around what we already had: engineers, a Next.js app, a Supabase database, and a Claude subscription.

The swap-out table

Function a content team does	What we replaced it with
Editorial calendar	A markdown queue in `scripts/blog-automation/blog-tracker.md`
Writer drafting a post	Claude Code invoked with a `/write-blog` skill, `--max-turns 25`
Editor reviewing tone/facts	House-style prompt with hard constraints plus a grep pass
CMS entry	A `POST /api/outrank/webhook` call with a bearer token
SEO metadata handoff	`generateMetadata()` in `app/blog/[slug]/page.tsx` reads from Supabase
Cross-posting	A Slack thread that pings a human to paste the pre-adapted version
Analytics reporting	Supabase view-count RPC plus a nightly query

Nothing here is unusual on its own. What made it work was treating the pipeline like an internal API instead of a workflow. The endpoint is versioned. The tracker is in git. The skill prompt is code-reviewed. A blog post is a POST request, not a Notion doc that gets forgotten.

Your publishing surface should be a REST endpoint

No CMS. No admin panel. The single write path is POST /api/outrank/webhook, defined in app/api/outrank/webhook/route.ts, guarded by a bearer token, processed by modules/services/OutrankArticleService.ts.

The service extracts author tags from the payload, dedupes by slug, and inserts into blog_posts. Immediately after the insert it calls:

revalidateTag("blog-posts", { expire: 0 });

So Next.js drops the cached list within seconds instead of waiting out the TTL.

Publishing looks like this from anywhere:

curl -X POST https://yoursite.com/api/outrank/webhook \
  -H "Authorization: Bearer $PUBLISH_TOKEN" \
  -H "Content-Type: application/json" \
  -d @post.json

Three downstream benefits no CMS gives you:

Anything can publish. A Claude Code agent, a curl from your laptop, a Zapier flow, a colleague's script. No proprietary editor to learn.
Schema enforced at the boundary. Bad payloads get a 400. You cannot ship a post with a missing meta description, because the service rejects it before the row is written.
Republishing is idempotent. The same slug hitting the endpoint twice updates the row rather than creating a duplicate. Failed publishes replay cleanly.

A WordPress instance, a Ghost blog, a Contentful workspace: each is a second system to maintain, another set of credentials to leak, and a UI you have to teach a future collaborator. For a small studio the CMS is a liability, not an asset.

Automate the mechanical, keep humans on judgment

The most useful reframing we did was sorting every step into two buckets: mechanical (rules-based, reproducible) and judgmental (needs taste, opinion, or product context).

Mechanical, fully automated:

Slug generation from title
Meta description length checks (under 160 chars)
Frontmatter validation for Dev.to and Hashnode adaptations
Image URL validation (Unsplash or Pexels only, no local /public/ paths)
Internal link UTM parameter enforcement
JSON-LD schema generation via components/json-ld.tsx (BlogPosting, FAQPage, VideoObject auto-extracted from embedded videos)
Sitemap regeneration on publish, in app/sitemap.ts

Judgmental, human-in-the-loop:

Topic selection
Whether a draft is on-brand
Which templates get linked, with what anchor text
Whether a claim in the post is defensible

The mechanical bucket runs on a cron. The judgmental bucket happens over coffee.

If you're an engineer this split is intuitive. It's how you'd design any pipeline where humans and machines share work. The mistake most content ops teams make is putting humans on the mechanical work (proofreading for length) and machines on the judgmental work (auto-generating topics from keyword volume). Reverse it.

The trick that took us longest to figure out

An AI-written post that references real file paths from your codebase reads dramatically differently from a generic AI-written post.

The former sounds like it was written by someone who ships. The latter sounds like a content mill. Same model, same length, completely different reception.

We enforce this by giving the /write-blog skill a research step that reads the actual repo before drafting. When a post claims "the OutrankArticleService dedupes by slug," it's because a subagent read modules/services/OutrankArticleService.ts and confirmed it.

The house-style prompt has one hard rule: no "unlock the power of," no "in today's fast-paced world," no "game-changing solution." Not because those phrases are unprofessional, but because the audience is developers and developers spot LLM fluff instantly. If your first paragraph reads like a press release, the tab closes.

The internal link graph is the product

For a dev-tools company the internal link graph matters more than external backlinks, because the point of ranking for "React Native boilerplate" is routing that reader to a product page.

Our rule: every post links to at least one template with UTM parameters, and anchor text varies per post so the pattern doesn't look manipulative. lib/blog-tags.ts maps every slug to topical tags, and getRelatedSlugs() surfaces three related posts at the bottom of each article.

What's less common is treating the template catalog as a first-class node in that graph, not a destination sitting outside it. A post about Supabase auth links to the specific template that ships with that exact auth setup. Anchor text, product, and article all agree.

Our top-converting page is a blog post about push notifications, not the homepage.

Optimize for LLM crawlers, not just Google

Open app/robots.ts and you'll find something that would have made a 2022 SEO agency nervous: we explicitly allow GPTBot, ChatGPT-User, Claude-Web, PerplexityBot, and Applebot-Extended. We block admin routes and auth callbacks. AI crawlers are welcome.

The reasoning is boring math. When a developer asks ChatGPT or Claude for "best React Native template with Supabase auth," the answer comes from whatever the model has indexed. Being excluded from that retrieval set costs you a whole channel.

Concretely it changes what we write:

Explicit comparison tables that models can extract and quote
FAQ sections with schema-marked Q/A pairs
File paths and code fragments that are hard to hallucinate but easy to cite

What we deliberately don't do

No keyword-first planning. Picking a topic because it has 10,000 monthly searches is how you publish "What is TypeScript?" for the 400th time. We start with a real thing our templates do, then find the keyword that describes it.

No translated backfill. Localizing 100 posts to 8 languages produces 800 pages of mostly-noise and wrecks your crawl budget.

No featured-snippet chasing on non-transactional queries. A snippet for "what is a React component" is worth nothing when that reader isn't buying anything.

No off-the-shelf content generation tools. We evaluated several. They produce content that ranks briefly then dies, because it has no anchor into a real product. Our pipeline works because it's coupled to our repo, not because it uses a fancier model.

Steal this

In the order we'd do it if starting over:

Ship a /api/webhook publishing endpoint. Bearer auth, schema validation, revalidation on write. Two hours.
Write a house-style prompt. Product terminology, repo file paths you want referenced, hard rules like "no emojis, no marketing verbs, no unfounded claims." One afternoon.
Build a topic queue in git. One markdown file, one topic per line. Version-controlled, no vendor lock-in.
Wire your model to write, then bash-post to your webhook. Skip every SaaS "AI blog platform." They exist to make you rent something you can build in 200 lines of shell.
Do internal linking manually for the first 20 posts. You'll learn which anchor styles convert, then encode them into the prompt.
Track conversions per post, not traffic per post.

The honest caveat

The AI pipeline sounds too good. Here's the part the case studies leave out: the first three months of building it cost more than three months of hiring a writer would have.

We paid the setup cost because we were building once and running for years. If you're validating a product idea over the next 90 days, hire a writer. If you plan to still be publishing in three years, build the pipeline.

What's your setup? If you're running content for a dev-tools company, drop your volume and stack in the comments. I'm most curious whether anyone has shrunk the judgmental bucket without the output going generic. That's the ceiling we keep hitting.

Supabase Row Level Security: The Policies That Actually Ship SaaS

Nikolas M I — Wed, 12 Aug 2026 07:44:59 +0000

TL;DR

RLS moves authorization from your app layer into your schema. Security becomes a property of the database, not a discipline every engineer has to remember on every new endpoint.
Four patterns cover ~95% of SaaS: owner-only, team-scoped, public-read/owner-write, and role-based on JWT claims.
A table with RLS enabled and zero policies is a black hole. Nobody reads or writes anything. This is the #1 "why is my query returning empty" cause.
Test with SET LOCAL ROLE authenticated, not in the dashboard SQL editor. The editor runs as superuser and will happily lie to you.
service_role bypasses RLS entirely. Keep it out of your application process.

Row Level Security is Supabase's most under-appreciated feature. It moves authorization from your application layer to the database, meaning security is a property of your schema rather than a discipline your team has to remember. Every dev on the team, every service, every background job automatically inherits the same guarantees.

This post covers the setup, the four patterns you'll actually use, testing, and the one footgun that has bitten every team I've shipped Supabase with.

Why RLS is the wedge

Consider two ways to build multi-tenant permissions.

App-layer (Django, Rails, Express):

def get_widgets(request):
    return Widget.objects.filter(user=request.user)  # every view, every time

Now write this in 30 places across your codebase. Onboard a new engineer. They add a new endpoint. They forget the .filter(user=...). Data leak.

RLS (Postgres/Supabase):

CREATE POLICY "own_rows" ON widgets USING (auth.uid() = user_id);

Now every service, every query, every dev, every background job that touches widgets automatically respects the boundary. There's no discipline to forget.

That's why Supabase leans on RLS so hard. It's the reason "solo dev ships SaaS in a weekend" is a repeatable pattern instead of a security-audit-later disaster.

Setup

Every user-scoped table needs two things:

-- 1. Enable RLS (default: policies apply)
ALTER TABLE widgets ENABLE ROW LEVEL SECURITY;

-- 2. Add at least one policy. Without a policy, the table is inaccessible.
CREATE POLICY "users see own widgets"
  ON widgets
  FOR SELECT
  USING (auth.uid() = user_id);

Two gotchas:

RLS is off by default on new tables. Add a lint rule or migration check that fails CI if a table lacks ENABLE ROW LEVEL SECURITY.
A table with RLS enabled but zero policies is a black hole. Nobody can read or write anything. If your table suddenly returns empty results, check that a matching policy exists for the operation. SELECT, INSERT, UPDATE, and DELETE all need separate policies unless you use FOR ALL.

The 4 patterns that cover 95% of SaaS

1. Owner-only

The bread and butter. A user reads and writes only their own rows.

CREATE POLICY "owner select" ON widgets
  FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "owner insert" ON widgets
  FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "owner update" ON widgets
  FOR UPDATE USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id);

CREATE POLICY "owner delete" ON widgets
  FOR DELETE USING (auth.uid() = user_id);

Notice the distinction:

USING filters which rows the operation can see (SELECT, UPDATE, DELETE).
WITH CHECK validates rows being written (INSERT, UPDATE). It prevents users from creating rows with someone else's user_id.

2. Team-scoped (multi-tenant SaaS)

Users belong to teams via a memberships table. They see all rows in their team.

CREATE POLICY "team members read" ON documents
  FOR SELECT
  USING (
    team_id IN (
      SELECT team_id FROM memberships WHERE user_id = auth.uid()
    )
  );

CREATE POLICY "team members write" ON documents
  FOR INSERT
  WITH CHECK (
    team_id IN (
      SELECT team_id FROM memberships WHERE user_id = auth.uid()
    )
  );

Two performance notes:

Add an index on memberships(user_id, team_id). The subquery runs on every row check.
For high-throughput reads, denormalize: add user_ids UUID[] to each row and index it with GIN. The RLS check becomes auth.uid() = ANY(user_ids), which is much faster than a subquery.

3. Public-read, owner-write (profiles, blog posts)

Anyone can read. Only the owner can write.

CREATE POLICY "public read" ON profiles
  FOR SELECT
  USING (true);

CREATE POLICY "owner write" ON profiles
  FOR ALL
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

Perfect for user profiles, public blog posts, and discoverable pages.

4. Role-based (admin/user split)

Different behavior based on JWT claims. This requires you to set the role claim in your JWT. In Supabase you can do that via an auth hook or a custom claims function.

CREATE POLICY "admins see everything" ON widgets
  FOR SELECT
  USING (auth.jwt() ->> 'role' = 'admin');

CREATE POLICY "users see own" ON widgets
  FOR SELECT
  USING (auth.uid() = user_id);

Multiple policies on the same operation are OR'd. A request succeeds if any policy passes. So an admin sees all rows from policy 1, and a regular user sees their own from policy 2.

Testing policies locally

The trap most teams hit: policies work in the dashboard's SQL editor (superuser context) but fail in the app. Reproduce the app's context before shipping.

-- In psql or the SQL editor
BEGIN;

-- Simulate being an authenticated user
SET LOCAL ROLE authenticated;
SET LOCAL request.jwt.claims TO '{"sub":"550e8400-e29b-41d4-a716-446655440000","role":"authenticated"}';

-- Now run the query the app would run
SELECT * FROM widgets;

ROLLBACK;

SET LOCAL scopes the change to the transaction, so you don't accidentally leave your session with the wrong role.

Automate it in tests. Write a Vitest or Jest helper that opens a Supabase client with a specific test user's JWT and asserts the expected rows. Add a CI job that runs these against a fresh Supabase test instance on every PR.

The service_role footgun

Supabase issues you two keys:

anon key: public, safe to embed in your frontend. RLS applies.
service_role key: bypasses RLS entirely. Meant for server-side admin operations.

The footgun: the service_role key is usually pasted into .env files. Once a script (background job, migration, dev-only utility) runs with service_role and has a bug, it can drop production tables or leak data with no RLS to catch it.

Isolation rule I enforce on every project:

The service_role key never lives in the application process.
service_role is used only in explicitly separated code paths: a distinct microservice, a cron worker, a CI job, each with its own repo or clearly namespaced module.
Any code using service_role must have a code review checklist entry: "Does this actually need to bypass RLS, or would a policy work?"

The default answer should be "use a policy." Only reach for service_role when you genuinely need cross-tenant behavior, like an analytics rollup or an admin console.

Migrations, CI, and policy diffs

RLS policies are code. Treat them like code:

Store policies in migrations. Never edit via the Supabase dashboard for production. Use supabase db diff locally to generate migration files.
Version-control the migration output. Check the .sql files into git.
Diff policies on PR. A GitHub Action that runs supabase db diff against the target branch and comments the SQL delta prevents silent policy changes.
Snapshot test policies. Serialize pg_policies to JSON and diff it. This catches policies that were dropped or altered outside migrations.

If you'd rather start from a codebase that already has this wired up, the Applighter templates ship with RLS policies, auth, and payments preconfigured on Supabase and Expo. Worth a look if you're bootstrapping. The patterns above are simple enough that any team can adopt them by hand, though.

When RLS is the wrong tool

Not everything belongs in RLS:

Business rules that change often. "Only paying users can access X" is better as a Postgres function that RLS calls, so you can update the function without touching every policy.
Cross-tenant admin operations. Analytics dashboards and support tools should use service_role with server-side auth.
Rate limiting. Postgres is the wrong layer for request throttling.
Complex authorization graphs. If you have a permissions system with roles, resources, and inheritance, look at pgRBAC or push the logic into a dedicated authz service.

Ship it

The minimum viable RLS setup for a new SaaS:

Enable RLS on every user-scoped table.
Add owner-only or team-scoped policies from the templates above.
Isolate service_role from the app process.
Add a CI check that all tables have RLS enabled.
Write one test per policy pattern.

That's roughly 50 lines of SQL and 30 minutes of setup. Compared to weeks of building middleware-based authorization in an app framework, RLS is the wedge Supabase actually delivers on, and the reason indie SaaS teams ship security-hardened multi-tenant apps in weekends instead of quarters.

What's your setup? Drop a comment with the trickiest policy you've had to write. I'm especially curious how people are handling nested team hierarchies, since that's the case where the subquery approach starts to hurt.

Build vs Buy: What Founders Get Wrong About Templates

Nikolas M I — Mon, 10 Aug 2026 07:10:19 +0000

Every week a founder DMs me the same question: "Should I build my React Native app from scratch or buy a template?" Here's the framework I use to answer it, plus the five wrong assumptions that make the debate louder than it needs to be.

TL;DR

Differentiation lives in the product (AI pipeline, marketplace mechanics, workflow)? Buy a template and spend your engineering budget on the differentiation.
Differentiation lives in the infrastructure (custom protocol, native audio pipeline, novel storage engine)? Build from scratch.
Roughly 90% of consumer and prosumer apps live in bucket one and pretend to live in bucket two.
"Build or buy" is really four separate questions wearing a trench coat. Answer them separately or the debate never resolves.

The question you're actually asking

"Build or buy" is a stand-in for four separate questions:

Will my app look like shovelware?
Will I get stuck when I need to change something?
Is a $79 template recycled GitHub code?
Am I "cheating" if I didn't write every line?

Each has a different answer. Bundling them together is why the debate never resolves.

Five wrong assumptions

1. "Building from scratch = full control"

Both paths start from the same primitives: React Native, Expo, a DB, an auth provider. A template just made 200 opinionated decisions for you: the same 200 you'd make identically after two months of research.

# What a template saves you from doing yourself
npx create-expo-app my-app
# ... then 60 hours of:
# - navigation library selection
# - auth flow
# - form validation
# - RLS policies
# - Stripe webhook handlers
# - EAS build config
# - push notification setup
# - offline handling
# - error boundaries
# - image caching

You still have full control. Templates ship source code. You just skip the mandatory chores.

2. "Templates make apps look generic"

Take away the color, logo, and copy from the App Store's top 100. What's left? Tab bar, list, detail, modal, auth. Uniqueness comes from brand, motion, and product concept, not from the base template.

A React Native template that uses NativeWind can be re-themed in an afternoon:

// tailwind.config.js: the entire re-branding surface for a NativeWind template
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: "#FF5722",   // your brand
        surface: "#0B0F14",
        accent:  "#00D4AA",
      },
    },
  },
};

3. "Building it teaches me more"

Reading a well-written template teaches you faster than writing one from scratch. You're editing production patterns on day one instead of inventing bad ones over three months.

4. "Templates are toys, real code is on the backend"

Full-stack templates like Applighter ship the entire vertical:

Postgres schema + migrations
RLS policies (see Supabase's RLS docs)
Edge functions for server-side logic
Storage buckets with signed URLs
Auth (email, OAuth, Apple)
Streaming AI responses
Push notifications

If a "template" doesn't ship all of that, it's a UI kit. Charge accordingly.

Here's the difference in practice. A UI kit hands you this:

// components/TodoList.tsx
const TODOS = [
  { id: "1", title: "Buy milk", done: false },
  { id: "2", title: "Ship app", done: false },
];

export function TodoList() {
  return <FlatList data={TODOS} renderItem={({ item }) => <Row {...item} />} />;
}

A full-stack template hands you this, plus the migration and the policy that make it safe:

-- supabase/migrations/0001_todos.sql
create table todos (
  id         uuid primary key default gen_random_uuid(),
  user_id    uuid not null references auth.users on delete cascade,
  title      text not null,
  done       boolean not null default false,
  created_at timestamptz not null default now()
);

alter table todos enable row level security;

create policy "owner reads own todos"
  on todos for select
  using (auth.uid() = user_id);

create policy "owner writes own todos"
  on todos for insert
  with check (auth.uid() = user_id);

// hooks/useTodos.ts
export function useTodos() {
  return useQuery({
    queryKey: ["todos"],
    queryFn: async () => {
      const { data, error } = await supabase
        .from("todos")
        .select("*")
        .order("created_at", { ascending: false });
      if (error) throw error;
      return data;
    },
  });
}

That gap (mock array vs. schema + RLS + typed client) is the entire difference between $29 and $200.

5. "I'll save money by building it myself"

The math:

Approach	Cost	Time
Full-stack template	$79–$200	2–6 weeks
Solo contractor build	$6k–$12k	8–12 weeks
Agency build (median)	$18k+	3–6 months
DIY founder from scratch	$0 cash / 3–6mo	3–6 months

The template pays for itself the day you download it.

The honest comparison

Dimension	Build from scratch	Buy a template
Time to first App Store submission	3–6 months	2–6 weeks
Upfront cash	$0–$30k	$50–$200
Full source ownership	Yes	Yes (with legit templates)
Time on "solved problems"	60–80%	5–10%
Backend included	No	Yes (full-stack)

When to actually build from scratch

You're building infrastructure, not a product.
Your app's core primitive doesn't fit React Native (real-time sub-16ms, custom Metal shaders, on-device model runtime).
You have engineers on payroll already and no launch pressure.
Compliance requirements (SOC 2, FedRAMP, HIPAA) demand ownership of every line.

For every one of these, we see 50 apps that fit none of them but choose to build from scratch anyway. That's a hobby, not a decision.

When to buy

App is a variant of a solved category (chat, notes, tracker, marketplace, AI wrapper)
Differentiation is UX or product logic, not architecture
You want to spend month one on your unique value, not on auth boilerplate

Picking a template that isn't junk

Source code included and readable (not obfuscated, not a paid-SaaS wrapper)
Backend included (not just UI screens)
Commits in the last 90 days
Refund policy in plain English
The author uses their own product

The pattern that actually works

Almost every successful indie mobile app in the last three years followed this loop:

Buy a full-stack template
Ship branded MVP in 3–6 weeks
Get real user data
Rewrite the two or three modules that turned out to matter

They didn't "buy" or "build." They bought the boring 80% and built the interesting 20%.

The framework, one line

Where is my differentiation, and what's the fastest path to it?

Spend your engineering budget where it differentiates. Everything else is a chore, and chores have a market price now, usually under $200.

Disclosure: I write templates for a living at Applighter (Expo + Supabase, full source, no vendor lock), so I'm not neutral here.

What did you start your last app from, scratch or a template, and would you make the same call again? Drop it in the comments.

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.

DEV Community: Nikolas M I

Our React Native Template Refund Policy: What It Cost

TL;DR

What "no questions asked" actually means

The industry standard is nothing like this

Why we did it

What the refund rate actually was

What it actually cost us

The counter-intuitive benefits

When a generous refund policy is wrong

The policy only works because of the product

FAQ

The bottom line

We Published 118 Blog Posts With Zero Writers. Here's the Pipeline.

TL;DR

Why we couldn't just hire a writer

The swap-out table

Your publishing surface should be a REST endpoint

Automate the mechanical, keep humans on judgment

The trick that took us longest to figure out

The internal link graph is the product

Optimize for LLM crawlers, not just Google

What we deliberately don't do

Steal this

The honest caveat

Supabase Row Level Security: The Policies That Actually Ship SaaS

TL;DR

Why RLS is the wedge

Setup

The 4 patterns that cover 95% of SaaS

1. Owner-only

2. Team-scoped (multi-tenant SaaS)

3. Public-read, owner-write (profiles, blog posts)

4. Role-based (admin/user split)

Testing policies locally

The service_role footgun

Migrations, CI, and policy diffs

When RLS is the wrong tool

Ship it

Build vs Buy: What Founders Get Wrong About Templates

TL;DR

The question you're actually asking

Five wrong assumptions

1. "Building from scratch = full control"

2. "Templates make apps look generic"

3. "Building it teaches me more"

4. "Templates are toys, real code is on the backend"

5. "I'll save money by building it myself"

The honest comparison

When to actually build from scratch

When to buy

Picking a template that isn't junk

The pattern that actually works

The framework, one line

Our failed React Native template launch, dissected

TL;DR

The setup

What happened at launch

The angry email

The six fixes

1. Real backend, not mockApi.ts

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

3. Demo video per template

4. 12,000-word docs per template

5. Ship for agents

6. Refund policy above the buy button

v1 vs v2 at a glance

What I'd tell 2025-me

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

The design brief the model actually reads is your seed data

Before / after: same prompt, two seed files

Seed A (what most people ship as a fixture)

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

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

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

A repeatable folder structure

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

Why 'good enough for testers' isn't

The five artefacts

Designing the in-app feedback loop

1. Real backend, not `mockApi.ts`