DEV Community: Russel Dsouza

Best React Native Starter Templates in 2026 (Compared)

Russel Dsouza — Thu, 06 Aug 2026 11:55:59 +0000

Best React Native Starter Templates in 2026 (Compared)

One of the first questions every React Native developer asks is:

"What's the best React Native starter template?"

It's a fair question.

Nobody wants to spend the first week of a project configuring navigation, authentication, theming, folder structure, and dozens of reusable screens before building their actual product.

A good starter template should help you ship faster—not introduce more decisions.

After trying several popular React Native starter kits and boilerplates, here are the things that actually matter.

What makes a good React Native starter template?

Most comparison articles focus on the tech stack.

Expo vs React Native CLI
TypeScript
State management
Navigation
Authentication

Those are important, but they're only part of the picture.

A great starter template should also include:

Production-ready screen layouts
Dark mode support
Consistent design system
Reusable components
Clean project structure
Easy customization
Good documentation

The goal isn't just to start a project.

It's to reduce the amount of UI you have to rebuild.

What developers usually search for

Most developers aren't actually searching for a "starter template."

They're trying to solve a specific problem.

Common searches include:

React Native login screen
React Native onboarding template
React Native dashboard UI
React Native settings screen
React Native profile screen
React Native e-commerce UI
React Native chat UI
React Native admin dashboard

If your starter template doesn't include these, you'll probably end up building them yourself.

Popular React Native starter templates

Expo Router Starter

Perfect if you want the official Expo experience.

Pros

Officially maintained
Great developer experience
Excellent documentation

Cons

Minimal UI
You'll build most application screens yourself

Ignite

Ignite has been around for years and provides a solid architecture.

Pros

Opinionated structure
State management included
Great documentation

Cons

Focuses more on architecture than reusable UI.

React Native Boilerplates

There are dozens of community boilerplates.

Some are excellent.

Some haven't been updated in years.

Before choosing one, always check:

Last commit
Issue activity
Documentation quality
React Native version
Expo compatibility

gluestack-ui Pro

Unlike traditional starter templates, gluestack-ui Pro focuses on the part most templates leave out—production-ready app screens.

Instead of only giving you components, it includes reusable screens for common app flows such as:

Authentication
Onboarding
Dashboard
Settings
Profile
Commerce
Chat
Wallet
Media
Social

They're built with:

Expo 54
TypeScript
NativeWind v5
gluestack-ui v5
Design tokens
Light & Dark mode

Learn more

Questions to ask before choosing a starter template

Before adopting any template, ask yourself:

✅ Can I customize it easily?

✅ Does it support theming?

✅ Is the code easy to understand?

✅ Will it still work after upgrading React Native?

✅ Does it include the screens I'll end up building anyway?

These questions matter more than the number of GitHub stars.

Final thoughts

The best React Native starter template isn't necessarily the one with the biggest feature list.

It's the one that removes the most repetitive work.

Whether that's a lightweight boilerplate, a full architecture starter, or a reusable screen library depends on your workflow.

If your team repeatedly builds the same authentication flows, dashboards, settings pages, and onboarding experiences, starting with production-ready screens can save days of development on every project.

What starter template are you using today, and what's the first thing you always end up changing?

Gluestack-ui Pro: 55+ Production-Ready React Native Screens

Russel Dsouza — Wed, 05 Aug 2026 07:30:45 +0000

Hey everyone!

If you've ever built a React Native application, you've probably faced this problem. You start a new project, you're excited to build features, solve real user problems, and ship something amazing.

But before you get there, every application needs the same set of screens.

Authentication
Profile
Settings
Chat
Dashboards

Almost every project starts with these. The problem isn't that they're difficult to build. The problem is building them well.

Because this is where users get their first impression of your product. If these screens don't feel polished, the whole application doesn't feel premium. So developers spend hours perfecting layouts, spacing, typography, animations, responsiveness, and design consistency.

And that's where a lot of development time disappears. Not into building unique features, but into rebuilding the same UI foundation over and over again.

Introducing gluestack-ui Pro

That's exactly why we built gluestack-ui Pro.

Instead of starting every project from scratch, you get a collection of premium, production-ready React Native screens that are ready to integrate into your application. Simply customize them according to your brand, connect your own APIs and business logic, and focus on building the features that make your product unique.

55+ Ready-to-use Screens

Right now, it comes with 55+ of the most commonly used React Native screens.

Whether you're building a startup, an MVP, or a client project, you'll find most of the common screens already available.

The layouts are clean. The spacing is consistent. The typography feels polished.

We've also added smooth animations throughout the application, making the entire experience feel modern and premium. And these aren't just UI mockups. These are real React Native screens that you can integrate directly into your application and customize however you like.

The Codebase & Architecture

The codebase is clean and well-structured. The project is easy to navigate, making customization straightforward even for larger applications.

Design tokens are a big part of that. Instead of hardcoded values scattered throughout the project, everything is driven by tokens.

So if your designer decides to change the brand color later, you don't have to hunt through dozens of files updating components one by one. Just update the token once, and the changes are reflected across the entire application. The entire styling system is built using Tailwind, which keeps the code clean, readable, and easy to maintain.

Modern Tech Stack

gluestack-ui Pro is built with the latest React Native technologies:

Layer	Version
Expo	54
NativeWind	v5
Gluestack UI	v5
Language	TypeScript

Seamless Customization

Changing the primary color updates it across the entire application. Same for the background color. One small change updates every screen that uses those design tokens.

That's the advantage of a proper tokenized design system. You update your design in one place, and the entire application stays consistent.

There are also several beautifully designed themes included out of the box, and every theme works seamlessly with both Light Mode and Dark Mode.

Wrapping Up

One important thing before we wrap up. gluestack-ui Pro isn't trying to replace development. You still own your backend. Your APIs. Your authentication. Your business logic.

gluestack-ui Pro simply removes the repetitive UI work, giving you a strong foundation so you can focus on building your actual product.

If you're looking to build React Native applications faster, without spending weeks rebuilding the same UI over and over again, you know where to start. gluestack-ui Pro gives you a production-ready foundation that you can integrate, customize, and make your own.

Spend less time building common screens, and more time building the features that make your product unique.

We're launching on Product Hunt today. If any of this is useful to you, a look means a lot.

What's the screen you rebuild most often? Curious whether it matches ours.

How tinbase Reimplements Supabase's Wire Protocols in a Single Process (and Runs in a Browser Tab)

Russel Dsouza — Thu, 30 Jul 2026 07:47:14 +0000

tinbase is live on Product Hunt today — an open-source, Supabase-compatible backend that runs without Docker. Support the launch here: [https://www.producthunt.com/products/tinbase]

The problem

Local Supabase development means Docker: a 12-container stack and over 2 GB of images to get Postgres, PostgREST, GoTrue, Storage, and Realtime running on a laptop. The platform itself is excellent; the local loop is heavy. And in some environments it isn't just heavy — it's impossible. tinbase was originally built for lifo, a project that maps Linux APIs into the browser, to let Expo apps run fully in-browser with full-stack capability — database, auth, storage, realtime, no server. It's part of the RapidNative ecosystem, and Docker was never an option in that environment.

That raised the question: what if the entire Supabase API surface were just a process? One process, embeddable anywhere Node — or a browser tab — runs?

Why Supabase compatibility instead of yet another backend

tinbase deliberately avoids inventing another proprietary BaaS API. Supabase's real strength is that it functions as an open standard: PostgREST's REST conventions, GoTrue's auth flows, and a documented realtime protocol, all served by the most widely adopted SDK in the space. Implement those protocols faithfully, and every existing supabase-js app, tutorial, and starter template works with zero changes — and every project stays portable back to hosted Supabase.

That portability is the design constraint everything else follows from. tinbase reads the same supabase/migrations/*.sql files and follows the Supabase CLI's migration conventions, tracking them in supabase_migrations.schema_migrations. It's a different runtime, not a different platform.

The architecture

tinbase is a single TypeScript process with three layers.

1. Protocol layer. Every service is a pure (Request) => Response fetch handler: the PostgREST query grammar (filters, embeds — to-one, to-many, many-to-many via junction, !inner — JSON paths, upsert, RPC), GoTrue's auth endpoints (email/password, anonymous sign-in, OAuth with PKCE, session refresh with rotation), storage APIs with signed URLs, and realtime speaking the Phoenix protocol over a hand-rolled ~150-line RFC 6455 WebSocket server. Because these are plain fetch handlers rather than a bound HTTP server, they run behind node:http (or Bun.serve) on a machine — or get handed to supabase-js as a custom fetch and invoked directly in-process, with no server at all. That one decision is what makes browser mode possible.

2. Engine adapter layer. A thin interface over "a thing that runs Postgres SQL," with three implementations and honest tradeoffs:

Embedded native Postgres 17 — the default on macOS/Linux. First run downloads ~12 MB of platform binaries, then initdb with memory-lean settings: ~59 MB of RAM at boot, listening only on a private unix socket. Real RLS, triggers, foreign keys, jsonb.
PGlite (wasm) — ElectricSQL's Postgres compiled to WASM. Zero setup, runs anywhere Node runs and in the browser, and it's the default on Windows. The tradeoff is memory: its WASM heap sits around 575–650 MB.
pg-mem — a pure-JS in-memory subset at a 3.6 MB install, the lightest option for browser previews. No RLS or cron, but the REST CRUD surface, auth, edge functions, and realtime all work, with change events synthesized in JS by the REST layer.

3. Studio. A Supabase-Studio-style dashboard at /_/ — table editor with row CRUD, SQL editor, user management, storage, RLS policies — compiled to a single self-contained HTML file so it works even inside the single binary.

The hard parts

RLS across engines. Every REST and storage request runs inside a transaction with SET LOCAL role and request.jwt.claims, so a policy like using (user_id = auth.uid()) behaves identically to hosted Supabase — whether the SQL executes in native Postgres 17 or in WASM.

HTTP without HTTP. In a browser tab there is no listener socket. supabase-js expects a URL, so tinbase hands it a custom fetch that routes requests straight into the protocol handlers in-process:

const supabase = createClient('http://localhost', backend.anonKey, {
  global: { fetch: (input, init) => backend.fetch(new Request(input, init)) },
})

Realtime without WAL. Hosted Supabase reads the write-ahead log; tinbase feeds postgres_changes from triggers plus pg_notify, and even applies per-subscriber RLS filtering on INSERT/UPDATE events by re-checking the row as that user. (DELETE events can't be re-queried — the row is gone — which is documented as a known gap.)

Proving compatibility. Claiming "supabase-js works unchanged" is easy; keeping it true is a test-suite problem. 120 tests run the real @supabase/supabase-js against the backend — REST via in-process fetch, realtime over actual WebSockets, zero mocks — and pass on both the wasm and native engines. Overall coverage lands around 80% of the supabase-js SDK surface, and roughly 90% of what a typical CRUD + auth + storage + realtime app actually calls.

The numbers

The footprint benchmark (reproducible via bench/footprint.ts in the repo) against the same workload — boot, 1,000 inserts, 1,000 filtered reads:

	tinbase (single binary)	Supabase local	PocketBase
Memory at boot	49 MB	1,441 MB	15 MB
Memory after workload	66 MB	1,626 MB	24 MB
Install size	92 MB	2,291 MB	30 MB
Processes	2	12 containers + Docker	1
Database	real Postgres 17 + RLS	Postgres 17	SQLite

The honest read: versus Supabase local, ~16–24x less memory and a ~2s boot instead of a minute, with the same SDK and APIs. Versus PocketBase, roughly 2.7x the RAM — but running real Postgres with RLS behind Supabase's exact wire APIs, so code and migrations move to hosted Supabase unchanged.

What it looks like in practice

npx tinbase start

#   API URL: http://127.0.0.1:54321
#   anon key: eyJ...

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)
// everything below this line is unchanged app code
await supabase.auth.signUp({ email: 'me@example.com', password: 'secret123' })
const { data } = await supabase.from('todos').select('*, author:users(name)').eq('done', false)

Or skip the terminal and run the whole backend in a tab: [browser demo link]

Honest limits

tinbase is alpha (currently v0.6.x). It's built for local development, prototyping, and embedded/browser use — for production, hosted Supabase remains the recommendation, and a tinbase project migrates there unchanged, which is the point of protocol compatibility. Known gaps are documented in the README: no MFA/SSO/phone auth yet, no resumable (TUS) uploads or image transformations, no pgvector, and the engines currently serialize writes over a single connection — fine for dev tools and small apps, not high-concurrency production. The issue tracker is open and good first issues are labeled.

React Native Performance Monitoring: Tools and Techniques for 2026

Russel Dsouza — Tue, 28 Jul 2026 13:42:21 +0000

Flipper is gone (removed as default in RN 0.76). React Native DevTools is the sanctioned replacement.
Track eight metrics — the two most under-monitored are slow frames % and frozen frames %, the closest proxy for "feels laggy."
The pragmatic 2026 production default: Sentry for crashes + performance, optionally layered with Firebase Crashlytics (free redundancy) or Datadog RUM (if you're already on Datadog).
The New Architecture shifts the culprits: TurboModule calls blocking the JS thread, and Fabric commit contention on the UI thread.

The React Native performance monitoring landscape looks nothing like it did two years ago. Flipper is gone as the default debugger. The New Architecture — Fabric, TurboModules, and the bridgeless runtime — is on by default in every fresh app. Hermes is the assumed engine.

If you're shipping in 2026, you need a stack that reflects those changes: dev-time profilers that speak Perfetto and Hermes, production observability that captures slow frames per screen, and a workflow for turning that data into fixes before your App Store rating quietly drops from 4.6 to 4.1.

What "performance" actually means in React Native

React Native has a two-thread execution model, and every performance conversation lives inside it:

The JS thread — business logic, Redux reducers, Animated orchestration, most third-party code.
The UI (main) thread — layout, drawing, gesture recognition, native module execution, useNativeDriver animations.

A janky animation is almost always a UI thread problem. A slow list scroll under load is usually a JS thread problem. A screen that takes three seconds to appear after a tap is likely JS thread — unless it's blocking on a network call, in which case it's a waterfall issue. A frozen screen after login is often a JSI serialization stall.

Monitoring means tracking both threads, tying the data to specific user journeys, and being able to answer three questions:

Is it slow? — objective metrics on frame rate, TTI, startup.
Where is it slow? — which screen, component, native module.
Why is it slow? — flame graphs, network waterfalls, memory pressure.

If your setup only answers question one, you don't have monitoring — you have a smoke alarm.

The eight metrics that matter in 2026

Metric	What it measures	Healthy target
JS FPS	Frame rate on the JS thread	60 fps sustained (120 on ProMotion)
UI FPS	Frame rate on the native main thread	60 fps sustained (120 on ProMotion)
Cold start time	Icon tap to first interactive frame	< 2.0s on mid-tier Android
Warm start time	Time to interactive when backgrounded	< 400ms
TTI	Screen mount → first tap-responsive frame	< 1s per screen
Slow frames %	Frames rendered in > 16.67ms	< 5% per session
Frozen frames %	Frames rendered in > 700ms	< 0.1% per session
JS bundle size	Compressed bundle on first launch	< 2MB gzip

The two most under-monitored metrics are slow frames % and frozen frames % — the closest proxy for the qualitative "laggy." Sentry, Firebase, and Embrace expose them natively; if your stack doesn't, that's the first upgrade to make.

The 2026 tooling stack

Monitoring splits into two phases with different tools: dev-time profiling (finding the problem locally) and production observability (knowing it exists at all).

Development-time tools

Tool	Best for	Notes
React Native DevTools	JS profiling, network, component inspector	Default since RN 0.76. Replaces Flipper.
Hermes Sampling Profiler	Deep JS CPU flame graphs	Export as `.cpuprofile`.
Perfetto / Systrace	System-wide traces across all threads	Android. Best for bridge/native contention.
Xcode Instruments	iOS CPU, memory, energy, Core Animation	Time Profiler + Animation Hitches.
Android Studio Profiler	Java/Kotlin allocations, native memory	Pair with Perfetto.
React DevTools Profiler	Render counts, wasted renders	Ships with RN DevTools.

If a tutorial tells you to install Flipper, it's out of date. Flipper was removed as the default debugger in RN 0.76 and the community plugins are largely unmaintained. React Native DevTools is the replacement, and it's better for JS profiling.

Production observability

Platform	Strengths	Watch out for
Sentry	Crash reporting, integrated perf traces, native + JS stack merging	Sampling costs add up at scale
Firebase Performance	Free, Crashlytics integration, custom traces	Sparse UI, no session replay
Datadog RUM	Backend APM correlation, cohort analysis	Expensive at high MAU
Embrace	Session-first, full journey replay	Smaller ecosystem
Instabug	Bug reporting + perf in one SDK	Duplicates Sentry if you have it
New Relic Mobile	Enterprise-grade infra correlation	Heavier SDK

The pragmatic default for most teams: Sentry for crashes + performance + source-mapped traces, optionally with Firebase Crashlytics as a free redundant crash pipeline, or Datadog RUM if you're already on Datadog.

Minimum-viable production setup

1. Install Sentry with performance monitoring.

npx @sentry/wizard@latest -s -i reactNative

Set tracesSampleRate: 0.2 and enable enableNativeFramesTracking: true and enableAutoPerformanceTracing: true. Native frames tracking is what gives you slow/frozen frame percentages per screen.

2. Instrument navigation. Wrap your app with Sentry's navigation integration so every screen transition becomes a labelled transaction. Without this, traces are anonymous and useless.

3. Upload source maps on every release. Untranslated stack traces are worthless. Bake source map upload into CI so every TestFlight or Play build has readable traces waiting.

4. Add custom spans around slow operations. Any function over 100ms — cache hydration, a DB query, a large image decode — gets a manual span. This turns "screen X is slow sometimes" into "screen X is slow because recipe hydration takes 800ms on cold launch."

5. Set alerts for regressions:

Crash-free session rate below 99.5%
P75 cold start rising > 20% between releases
Slow frame % above 8% on any top-10 screen

A real diagnostic walkthrough: "the feed screen is laggy"

Step 1: Confirm in production data

Filter to the screen, look at P75 and P95 of slow frames per session. If P75 is fine and P95 is bad, it's a device-tier issue — likely mid-tier Android under a specific data condition. Note the device and OS distribution of the worst sessions.

Step 2: Reproduce on the right hardware

Never diagnose Android performance on an iPhone 15 Pro. Grab a Pixel 6a or a mid-tier Samsung and reproduce there. Enable the perf overlay for live JS FPS and UI FPS.

Step 3: Capture a trace

For JS-thread issues: React Native DevTools → Performance tab → record the interaction. Look for long JS tasks (> 50ms bars), high re-render counts, serialization work.

For UI-thread issues on Android: capture a Perfetto trace. Look for main-thread frames overflowing 16.67ms, and whether the overflow is in Choreographer#doFrame or in native module calls.

Step 4: Isolate the offender

Common culprits, ranked by frequency in 2026 codebases:

A FlatList with heavy renderItem work — no memoization, inline arrows. Fix: memoize the row, stabilize props, add getItemLayout if heights are known.
A large state slice re-rendering the whole tree — a selector returning new object identity every time. Fix: narrow the selector, add shallow comparison.
An image decode blocking the UI thread — full-res images in small views. Fix: server-side resize, expo-image with contentFit.
A synchronous AsyncStorage migration on cold start — reading 5MB before render. Fix: defer via InteractionManager.runAfterInteractions, or MMKV with lazy hydration.
A third-party analytics SDK spawning threads on startup — 200–400ms blocks. Fix: initialize lazily after first frame.

Step 5: Verify in a canary

Ship behind a flag or to a beta cohort. Compare P75 slow-frame % on the screen before and after. If the number doesn't move, the fix isn't the fix.

The New Architecture changes what you monitor

Under the old bridge, the biggest sinkholes were JSON serialization between JS and native, visible in traces as huge queues. The New Architecture's synchronous, typed JSI calls mostly remove that class of problem — but introduce two new ones:

Synchronous TurboModule calls that block the JS thread. A native module doing 50ms of I/O now blocks JS directly, where it used to buffer through the async bridge.
Fabric commit contention on the UI thread. Shadow-tree commits are more efficient on average but spike sharply when a large tree diff lands — watch navigation transitions where the whole screen tree re-mounts.

Modern Sentry SDKs instrument both Fabric commits and TurboModule calls when auto-performance tracing is on. On an older SDK, upgrade — you'll see spans you didn't have before.

Bundle size and startup — the fixes that compound

Startup time is the metric most correlated with day-1 retention, and the one most engineers stop optimizing after the first release.

Enable Hermes. If you're not on it, you're leaving 30–50% of cold-start performance on the table.
Precompile Hermes bytecode. Ship .hbc, not .js. RN does this for release builds — verify it.
Ship inline requires on Android. inlineRequires: true in Metro defers module evaluation until first use, cutting 200–500ms on large apps.
Split third-party SDKs. Anything not needed in the first second — analytics, remote config, feature flags — initializes after InteractionManager.runAfterInteractions.
Measure with production RUM, not local. Cold start on your dev machine is meaningless. Trust P75 from real devices.

Track JS bundle size release-over-release. A 100KB regression per release compounds fast.

FAQ

Best free monitoring tool in 2026? Firebase Performance + Crashlytics. Automatic startup and HTTP traces, custom traces, native crash reporting, all free up to a generous tier. Limitations: sparse UI, no session replay — most teams add Sentry for deeper diagnostics.

Is Flipper still usable? No — removed as default in RN 0.76, plugins unmaintained. Use React Native DevTools, plus Perfetto (Android) and Xcode Instruments (iOS) for native profiling.

How do I measure startup time in production? Sentry's enableAppStartTracking: true, or Firebase's automatic _app_start trace. Track P75 cold start — the average hides regressions behind a few fast flagship sessions.

What FPS should an app maintain? 60 fps sustained on both threads (120 on ProMotion). Track slow frames (> 16.67ms) as a percentage and aim under 5% per session.

Do I need separate monitoring for the New Architecture? Same metrics, different culprits — TurboModule calls and Fabric commit contention. Any modern SDK instruments both automatically; just don't run a pre-GA-era SDK.

The takeaway

The dev-time story is React Native DevTools plus platform-native profilers (Perfetto, Instruments). The production story is Sentry as the default, with Firebase Crashlytics as free redundancy or Datadog RUM for existing Datadog teams.

The bigger shift is philosophical: performance is a metric you monitor continuously, not a project you do once. The teams shipping the smoothest apps in 2026 have slow-frame alerts wired to Slack, source maps on every release, and a P75 startup dashboard someone actually looks at each Monday.

I write more about how we handle this in AI-generated React Native apps at RapidNative.

What's your current monitoring stack — and what's the worst "laggy screen" bug you've tracked down? Mine was a 5MB AsyncStorage migration running on every cold start.

Why Supabase local dev needs 2.3 GB of Docker — and how we got it to 58 MB

Russel Dsouza — Fri, 24 Jul 2026 10:38:36 +0000

supabase start runs the production architecture on your laptop: 12 containers, 2,291 MB on disk, 1,626 MB RAM under load
Those services are mostly protocol translators — and protocols can be reimplemented
We rebuilt the surface as one process: pure (Request) ⇒ Response handlers on a swappable Postgres engine
Result: a 58 MB executable, ~2 s cold start, and the official supabase-js SDK passing 168/168 integration tests unchanged
Side effect: the same backend runs inside a browser tab

Part 1: Where the 2.3 GB goes

Run supabase start on a fresh machine and watch docker ps fill up. What you're looking at is Supabase's cloud architecture, faithfully reproduced locally — which is precisely the problem. Each box in their production diagram becomes a container on your laptop:

┌────────────────────────────────────────────────┐
│  supabase start                                │
│                                                │
│  kong          → API gateway / routing         │
│  postgrest     → REST API over Postgres        │
│  gotrue (auth) → JWTs, OAuth, magic links      │
│  realtime      → WebSockets (Elixir/Phoenix)   │
│  storage-api   → file storage over Postgres    │
│  imgproxy      → image transforms              │
│  edge-runtime  → Deno functions                │
│  studio        → dashboard (Next.js)           │
│  postgres-meta → introspection API for Studio  │
│  logflare      → log aggregation               │
│  vector        → log shipping                  │
│  db (postgres) → the actual database           │
└────────────────────────────────────────────────┘

Each service ships as its own image with its own runtime — an Elixir VM here, a Deno runtime there, Node for Studio, Go for auth. None of it is waste in production: these are independently scalable services doing real jobs across a fleet.

But locally, every one of those runtimes is overhead for a single developer making requests from localhost. The measured cost:

	Install footprint	Memory under load
Supabase local (12 containers)	2,291 MB	1,626 MB
tinbase (single binary)	92 MB	66 MB
tinbase (native, via npx)	36 MB	100 MB

And that's before the Docker Desktop tax on macOS and Windows, or environments where Docker isn't available at all: CI sandboxes, cloud IDEs, school machines, a phone.

Part 2: The key observation — it's protocols all the way down

Here's what makes the whole thing tractable. Your app never talks to those containers directly. It talks to documented HTTP and WebSocket protocols through supabase-js:

/rest/v1 speaks the PostgREST grammar — ?select=*,author:users(name)&done=eq.false
/auth/v1 speaks GoTrue's API — signup, OTP, PKCE, refresh tokens
/storage/v1 speaks the Storage API
Realtime speaks the Phoenix channel protocol over WebSockets
/functions/v1 invokes edge functions

A protocol doesn't care what implements it. PostgREST is ~"take this URL grammar, compile it to SQL, run it with the caller's JWT claims applied." GoTrue is "manage users in auth.users, mint JWTs." These are translation layers over Postgres — and translation layers can be reimplemented in-process.

What you cannot fake is Postgres itself. RLS evaluation, auth.uid() in policies, jsonb operators, triggers, ON DELETE CASCADE — behavior differences there produce the worst kind of bug: works locally, breaks in production. So that became the design rule:

Reimplement the translation layers. Never reimplement Postgres.

Part 3: The architecture — one fetch handler

Every tinbase service is a pure function: (Request) ⇒ Response. No sockets owned, no ports assumed, no filesystem requirements baked in. The whole backend composes into a single handler:

supabase-js (unmodified)
        │
        ▼
one (Request) ⇒ Response handler
  ├─ /rest/v1      → PostgREST grammar → SQL
  ├─ /auth/v1      → GoTrue flows → auth schema
  ├─ /storage/v1   → Storage API
  ├─ Realtime      → Phoenix protocol
  ├─ /functions/v1 → in-process handlers
  └─ /_/           → Studio dashboard
        │
        ▼
DbEngine adapter
  ├─ native → embedded Postgres 17
  ├─ wasm   → PGlite (Postgres compiled to WASM)
  └─ pg-mem → pure JS, in-memory (subset)

The REST layer parses the PostgREST grammar and compiles it to parameterized SQL — embedded resources become joins, filters become WHERE clauses — then executes with the request's JWT claims set, so your RLS policies run exactly as Postgres intends:

-- every request runs with claims applied, e.g.:
SET LOCAL request.jwt.claims = '{"sub":"<user-uuid>","role":"authenticated"}';
-- so this policy Just Works, locally and in prod:
CREATE POLICY "own todos" ON todos
  FOR SELECT USING (auth.uid() = user_id);

Realtime does the same per-subscriber: change events are filtered through RLS before delivery, so a user only receives events for rows they're allowed to see.

Things production Supabase does with Postgres extensions get reimplemented natively instead, because a single process can just... do them:

database webhooks — no pg_net
cron.schedule() — no pg_cron
a pgmq subset — no pgmq

Part 4: The consequences of "pure fetch handler"

This constraint looked academic. It turned out to be the most productive decision in the project.

In Node, the handler binds to a port and becomes an ordinary HTTP + WebSocket server:

npx tinbase start
# ~2 seconds → http://127.0.0.1:54321, Studio at /_/

As a binary, it compiles to a single 58 MB executable — no Node, npm, or Docker on the target machine. That's the CI story: download one file, run it, test against real Postgres.

In a browser, you hand the same handler to supabase-js as a custom fetch:

import { createClient } from '@supabase/supabase-js'
import { createTinbase } from 'tinbase'

const tin = await createTinbase({ engine: 'wasm' })   // PGlite under the hood

const supabase = createClient('http://tinbase.local', ANON_KEY, {
  global: { fetch: tin.fetch }   // ← the entire backend is this function
})

// no server anywhere; Postgres is running inside the tab
await supabase.from('todos').insert({ title: 'hello from a browser tab' })

Database included, running in-process. No server, no cloud. (Live demo: tinbase.dev/browser.)

We didn't set out to build a curiosity — this was the original requirement. tinbase came out of building RapidNative, where we needed a full dev stack — database, auth, storage, realtime — running in browsers and on phones with no VMs behind it. The single-process backend fell out of that constraint; replacing local Docker was the happy accident.

Part 5: How we know it's compatible

Claiming "Supabase-compatible" is easy. Our test is blunt: run the official supabase-js SDK's integration suite against tinbase, unmodified.

Current score: 168/168 passing, across both the native Postgres engine and the WASM engine. That covers the REST grammar (filters, embedded resources, RPC), the auth flows (email/password, anonymous, OTP, magic links, recovery, OAuth with PKCE), storage, and realtime's postgres_changes / broadcast / presence.

Migration compatibility is the other half. tinbase reads supabase/migrations/*.sql and seed.sql exactly like the Supabase CLI, tracked in the same table — so the exit path is: push the same files to hosted Supabase and keep going. Compatibility that doesn't include leaving isn't compatibility.

What this doesn't claim

tinbase is alpha (v0.10.0), and honesty is cheaper than a disappointed issue tracker:

Not production-ready. It's for local dev, prototypes, and embedded/browser use.
Not 100% of the surface. It covers the common paths (the test suite defines "common"); edges remain.
Not a Supabase replacement. It's the local half of a workflow that ends at hosted Supabase. Real Postgres in production is still the right call.
pg-mem is a subset. The pure-JS engine trades fidelity for zero-WASM environments; use native or PGlite when you can.

Try the numbers yourself

npx tinbase start

Repo (MIT): github.com/tinbase/tinbase — the benchmark methodology is on the site if you want to reproduce the table above.

If you've solved local-Supabase pain a different way — Nix, compose tricks, pg_regress heroics — I genuinely want to hear it in the comments. And if you try the browser engine, tell me what you build with it.

Introducing tinbase — local Supabase without Docker (one process, real Postgres)

Russel Dsouza — Thu, 23 Jul 2026 10:04:50 +0000

Supabase local dev = a 12-container, 2.3 GB Docker stack. tinbase serves the same APIs from one 58 MB process. No Docker.
It's real Postgres 17 — RLS, auth.uid(), jsonb, triggers, foreign keys all behave like hosted Supabase.
The official supabase-js SDK works unchanged (168/168 integration tests pass).
The whole backend — database included — can run inside a browser tab.
Open source, MIT. Try it: npx tinbase start

The problem

You know the drill. supabase start, then Docker pulls Postgres, PostgREST, GoTrue, Storage, Realtime, Studio... twelve containers, 2.3 GB on disk, ~1.6 GB of RAM under load. All you wanted was to run your app locally.

I love Supabase. I did not love paying a 2 GB tax to write a todo app on the train.

What tinbase does instead

One process. Same wire protocols:

	Install footprint	Memory under load
Supabase local (12 containers)	2,291 MB	1,626 MB
tinbase (single binary)	92 MB	66 MB
tinbase (native)	36 MB	100 MB

npx tinbase start

~2 seconds later you're serving requests. There's also a single 58 MB executable that needs no Node, npm, or Docker on the target machine.

Your code doesn't change

This is the whole point. tinbase implements the PostgREST query grammar, GoTrue auth flows, the Storage API, and the Realtime Phoenix protocol — verified by running the official SDK against it:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)

await supabase.auth.signUp({ email, password })
await supabase.from('todos').insert({ title: 'hello' })

const { data } = await supabase
  .from('todos')
  .select('*, author:users(name)')
  .eq('done', false)

supabase.channel('feed')
  .on('postgres_changes',
      { event: 'INSERT', schema: 'public', table: 'todos' },
      handleNewTodo)
  .subscribe()

No fork of the SDK. No wrapper. No different query language. RLS runs with your JWT claims applied, so auth.uid() policies work as-is — and Realtime does per-subscriber RLS filtering, so users only get change events for rows they can see.

Auth covers email/password, anonymous, OTP, magic links, password recovery, and OAuth (Google/GitHub + generic) with PKCE. Edge Functions run in-process via supabase.functions.invoke(). Webhooks, cron.schedule(), and a pgmq subset are in there natively — no pg_net/pg_cron/pgmq extensions to install. And a Supabase-Studio-style dashboard ships at /_/.

The weird part: it runs in a browser tab

Every service in tinbase is a pure (Request) ⇒ Response fetch handler on top of a swappable DB engine:

supabase-js (unmodified)
        │
        ▼
one (Request) ⇒ Response handler
  ├─ /rest/v1      (PostgREST)
  ├─ /auth/v1      (GoTrue)
  ├─ /storage/v1   (Storage)
  ├─ Realtime      (WebSocket)
  ├─ /functions/v1 (Edge Fns)
  └─ /_/           (Studio)
        │
        ▼
DbEngine adapter
  ├─ native  → embedded Postgres 17
  ├─ wasm    → PGlite (Postgres in WASM)
  └─ pg-mem  → pure JS, in-memory

In Node, that handler is an HTTP + WebSocket server. In the browser, you hand it to supabase-js as a custom fetch — and the entire backend, Postgres included, runs in-process in the tab. No server. No cloud. You can play with it at tinbase.dev/browser.

It's not a dead end

tinbase reads supabase/migrations/*.sql and seed.sql exactly like the Supabase CLI, tracked in the same table. Outgrow it? Push the same files to hosted Supabase and keep moving. You can also point it at a Postgres you already run with --database-url.

Why we built it

tinbase came out of building RapidNative and lifo, with a stubborn goal: run an entire dev stack — database, auth, storage, realtime — in the browser and on phones, with no VMs and no cloud behind it. Cutting the backend down to a single process was step one; making that same process run inside a tab was step two. Somewhere along the way it turned into a genuinely useful Docker-free replacement for local Supabase dev, so we open-sourced the whole thing (MIT).

Honest caveats

It's alpha (v0.10.0). Built for local dev, prototypes, and embedded/browser use — not production. 168/168 integration tests pass across both engines, but if you hit an API edge we haven't covered, open an issue.

Try it

npx tinbase start

GitHub: github.com/tinbase/tinbase

What would you build if your whole backend fit in a browser tab? Drop a comment — especially if you try the browser engine, I want to see what you make with it. 🚀

How to Publish Your Lovable App to the App Store (Without Rebuilding It Yourself)

Russel Dsouza — Wed, 22 Jul 2026 09:43:09 +0000

Lovable builds a web app. The App Store distributes native apps. That's a category gap, not a skill gap.
WebView wrappers feel wrong (scroll momentum, transitions, haptics, back gesture) and risk rejection under App Store Guideline 4.2.
The real fix is a React Native + Expo rebuild — plus certificates, provisioning profiles, signing keys, screenshots, and metadata.
If your Lovable app uses Supabase, a native rebuild can point at the same project. No migration needed.

You built something in Lovable over a weekend. It works. You sent the link to friends and they said "wait, you built this?"

Then someone asked: "Is it on the App Store?"

That's where most Lovable projects stall.

Why you can't submit a Lovable app to the App Store directly

Building an app and shipping an app are two different projects.

Lovable is excellent at the first one. But the App Store distributes native apps, and Lovable produces a web app. That's not a skill gap — it's a category gap.

To publish, you need:

An Apple Developer account ($99/year)
A bundle identifier
A distribution certificate and provisioning profile
A signed .ipa binary
Screenshots at every required device size
A privacy nutrition label and data-usage disclosure
A human reviewer who might say no

None of that comes out of a web app builder.

Why wrapping it in a WebView doesn't work

The obvious shortcut is a wrapper: put the web app in a native shell and ship the shell. Two problems.

It feels wrong. Scroll momentum is off. Transitions don't match the platform. Text inputs behave like a browser instead of a native keyboard. No haptics. The back gesture doesn't do what a thumb expects. Users can't name it, but they register it as "website in a box."

Apple notices too. Guideline 4.2 exists specifically for repackaged websites that don't provide enough native value. Plenty of wrappers slip through, but you're rolling dice on review — and each rejection costs a full cycle.

What a real conversion actually involves

The honest answer is a native rebuild: React Native + Expo, real navigation, real gestures, real device APIs (camera, push, the rest).

Technically that's the right call. Practically it's where projects die — you spent two days building the product and you're now looking at learning the entire Apple release toolchain, or paying someone who already has.

That mismatch is the whole problem. The building was fun and fast. The shipping is neither.

If you'd rather hand that part off, RapidNative converts Lovable apps to React Native and handles the full submission — signing, screenshots, metadata, the lot. You get a preview build on your device first, the full Expo source code afterward (no lock-in), and rejections are handled at no extra cost until you're approved. Typical turnaround is 1–2 weeks.

Worth noting for anyone doing this themselves too: if your Lovable app already talks to Supabase, you don't need to migrate anything. Point the React Native app at the same project and your data layer is done.

The takeaway

Building and shipping are separate problems. Being good at one tells you nothing about how hard the other will be.

Lovable made building dramatically easier. Apple's requirements haven't moved — and Google added a 12-tester closed-testing gate on top.

If your app is stuck one wall away from the store, that's not a verdict on your product. It's just a different category of work than the one you finished.

Been through App Store submission yourself? Which screen broke you? Mine was the privacy nutrition label.

5 Places Sensitive Data Leaks in a React Native App (and How to Plug Them)

Russel Dsouza — Tue, 21 Jul 2026 07:49:01 +0000

The leaks that matter usually aren't in production code — they're in the workflow around it.
Five common ones: AsyncStorage for tokens, real user data in design mockups, multi-stage AI pipelines, logs and crash reports, and bundled permissions.
Two greps that find real bugs today: AsyncStorage.setItem near token, and console.log(user / console.log(token / console.log(prompt.
Model consent by purpose, not by OS permission. Camera consent is not AI-summarization consent.

Data protection posts usually focus on the shipped binary. Encrypt this, pin that certificate, wrap the API client. All correct, all necessary — and all too late if the leak happened three weeks earlier in a design mockup.

We build AI-generated React Native apps at RapidNative, and the interesting security bugs almost never live in production code. They live in the space between code, design, and AI workflows. Here are five leak points we've watched teams miss.

1. AsyncStorage for anything sensitive

The classic. AsyncStorage is convenient, unencrypted key-value storage. A user session token in AsyncStorage is one rooted device or one iCloud backup extraction away from being replayed.

Fix: use expo-secure-store (Keychain on iOS, Keystore on Android) for anything that unlocks an account.

import * as SecureStore from 'expo-secure-store';

export async function saveSessionToken(token) {
  await SecureStore.setItemAsync('session_token', token);
}

If your codebase greps positive for AsyncStorage.setItem and token, that's your first PR.

2. Real user data in design prototypes

A designer opens Figma, needs a realistic list, and pastes 20 rows from the production customer export. Now customer names sit in the design file, which sits in a Figma team folder, which was shared to a contractor's personal email nine months ago.

Fix: a synthetic data script committed to the repo. npx generate-mocks users 20 should be faster than exporting production data. Make the fast path the safe path.

3. Multi-stage AI workflows

Voice memo lands. Transcription service returns text. A second model extracts tasks. Teammates get pinged.

That's four handoffs, and the security review probably only covers the API endpoint at step 1.

Fix: draw the pipeline as boxes, list what data each box sees, and confirm each hop has access controls tied to the user's actual consent — not a bundle. Camera consent is not AI-summarization consent.

4. Logs and crash reports

Sentry, Bugsnag, Datadog, or whatever log aggregator you use sees everything the app hands it. Session tokens in Authorization headers. AI prompt bodies with user text. Full user IDs in breadcrumbs.

Fix: scrub before you send. Most SDKs support a beforeSend hook.

Sentry.init({
  beforeSend(event) {
    if (event.request?.headers) delete event.request.headers.Authorization;
    return event;
  },
});

Grep your codebase for console.log(user, console.log(token, and console.log(prompt. That's your second PR.

5. Bundled permissions

You ask for camera on onboarding: "we need this for document capture." The user agrees. Six months later a new AI-summarization feature ships that also uses camera frames.

Same permission, different purpose. Legally shaky (GDPR Article 25 asks for data minimization by design), and practically a betrayal of what the user thought they said yes to.

Fix: model consent as a first-class type, keyed on purpose rather than on OS permission:

type ConsentEvent = {
  userId: string;
  action: 'granted' | 'withdrawn';
  policyVersion: string;
  purpose: 'document-capture' | 'ai-summary' | 'marketing';
  surface: 'onboarding' | 'settings' | 'feature-gate';
  timestamp: string;
};

Ship a new feature, ask again for that purpose. A one-line inconvenience for the user beats the €7.1B in GDPR fines the EU has issued as of January 2026.

The pattern

Notice what the five have in common: none of them are broken TLS, weak crypto, or a mangled JWT signature. They're all workflow leaks.

Encryption and pinning are table stakes. The bugs that leak your customer's data in 2026 are the ones nobody put in the security review — because they happen in Figma, in a Slack DM, in a Sentry payload, or in an AI pipeline diagram that was never drawn.

Draw the diagram. Grep the logs. Model consent. Ship.

Full source with the OWASP and NIST references: rapidnative.com/blogs/data-protection.

Which of the five would your codebase fail right now? Mine failed #4 the first time I checked.

You Don't Need 10 Refactoring Tools. Pick 2 From This Decision Tree.

Russel Dsouza — Tue, 21 Jul 2026 07:35:58 +0000

Answer three questions — scope of change, how type-heavy your codebase is, and who runs it — and the tool choice collapses to two.
Solo TS-heavy repo: VS Code + ts-morph. Small team, one repo: WebStorm + jscodeshift. Multi-repo org: ast-grep + Sourcegraph Batch Changes.
You can skip Babel, Comby, OpenRewrite/Moderne, and ReSharper unless you're in their specific ecosystem.
Tool sprawl is a symptom: if you're debating 10 tools, the real gap is that nobody's defined what's worth automating.

Every "best refactoring tools" post in 2026 gives you the same 10 names and lets you sort them out.

But 51% of developers now use AI coding tools daily, and the refactoring-tools market is on track from $1.74B to $5.82B by 2033. That growth means more tools, not clearer choices.

Here's a smaller frame. Answer three questions, pick two tools, ignore the rest.

The 3 questions

Scope of the change?

One file, minutes of work: your IDE
Same rewrite across many files: a codemod
Same rewrite across many repos: a batch orchestrator

How type-heavy is your codebase?

Loose JS or mixed languages: AST / pattern tools
Strict TypeScript: type-aware transforms

Who runs it?

Solo: CLI is fine
Team: you need a shared recipe and review flow

The 2-tool stacks

Solo dev, TypeScript-heavy React Native repo. Pick VS Code (rename, quick fixes, everyday cleanup) and ts-morph (type-aware programmable rewrites for the times VS Code's rename gives up). Two tools, both free, both scriptable.

Small team, one repo, repetitive structural changes. Pick WebStorm (symbol-aware preview so nobody merges a broken rename) and jscodeshift (AST codemods for the "convert 200 class components to hooks" problem). WebStorm covers day-to-day, jscodeshift covers migrations.

Multi-repo org, needs consistency. Pick ast-grep (structural search-and-replace fast enough to run in CI) and Sourcegraph Batch Changes (turns a codemod into PRs across every repo). One writes the change, the other ships it everywhere.

What you can skip

Babel, if you're not building a plugin. It's a compiler with a refactoring side-quest, not a refactoring tool.
Comby, if your repo is mostly one language. Its edge is cross-language pattern matching.
OpenRewrite and Moderne, if you're not on the JVM. Excellent recipes, wrong ecosystem.
JetBrains ReSharper, if you're not shipping .NET backends. If you are, you already own it.

The real lesson

Tool sprawl is a symptom.

If your team is debating which of 10 refactoring tools to standardize on, the actual problem is that nobody has defined what kinds of changes are worth automating.

Pick a scope, pick a scale, pick two tools. Ship a codemod. Learn what breaks. That's the loop.

If you want the full 10-tool breakdown with when-to-use-each, we wrote it up here.

What's your two-tool stack? Drop it in the comments — curious what people actually settle on.

Prompt-to-App Is a Lie — Here's What Actually Happens

Russel Dsouza — Wed, 15 Jul 2026 13:02:07 +0000

You type a sentence. Twenty seconds later there's a "React Native app." That's the pitch every prompt-to-app tool ships with in 2026 — Lovable, Bolt, v0, Replit Agent, and the rest. This post is about what actually happens after the demo screen.

Prompt-to-app tools generate a live-reloading UI in a sandbox against a mocked backend. They do not generate:

A real auth system with sessions, password reset, and OAuth
A database you own with migrations and RLS
Stripe wiring with real webhooks and Apple IAP handling
An .ipa or .aab you can submit to a store
The Apple Developer certificate needed to ship

Which is roughly 90% of the actual work.

What the demo shows vs. what production needs

Demo	Production
UI in a web preview	Signed `.ipa` + `.aab` submitted to two stores
Mocked API + sample data	Postgres with migrations, backups, RLS
One screen	Deep linking, push, background tasks, offline sync
Preview URL	Real accounts, OAuth, password reset
No integrations	Stripe, IAP, RevenueCat, Sentry, analytics
No secrets	Secret storage, key rotation, review notes

The three walls

Auth. The "Sign In" button works in the preview. It doesn't do anything real. Wiring actual OAuth + sessions + RLS is a rewrite of the data layer.

Payments. On iOS, selling anything digital requires Apple IAP, not Stripe. The tools don't know or care. You'll write this yourself, and it's a two-week job when you factor in webhook handling and license grants.

Submission. No agent creates an Apple Developer certificate. No agent captures screenshots at five device sizes. No agent replies to reviewer feedback. This is 30% of any app.

Why the demo works and the app doesn't

Architecture drift. AI-heavy codebases show 39% higher code churn — code reverted or heavily rewritten within two weeks. LLMs have no persistent memory of the constraints they set twenty prompts ago. They redefine User in three files.

Hidden state. The "backend" is a black-box datastore the tool provisions. You can't run migrations. You can't add a trigger. You can't set up Supabase-style RLS.

Stack lock-in. Most tools are aggressively opinionated. v0 outputs React + Tailwind. If you need Expo, native modules, or actual app store distribution, you're outside the happy path.

No distribution story. Docs for eas submit exist because submission is a real, human-mediated process. No prompt generates it.

The workflow that actually ships

# 1. Start from a template that owns the boring stuff
git clone <template-repo> my-app
cd my-app
bun install

# 2. Point your agent at the repo
# Claude Code, Codex, Cursor, whatever
# Templates ship with .claude/skills/ so the agent knows the conventions

# 3. Extend, don't invent
# "Add a photo upload feature to the events screen"
# "Wire the settings screen to the existing Stripe customer portal"

# 4. Ship
eas build --platform all
eas submit

The agent is in this workflow. It just isn't inventing the architecture.

The split that works

// The template owns things like this:
import { supabase } from "@/lib/supabase";
import { requireAuth } from "@/lib/auth";

export async function uploadNote(userId: string, blob: Blob) {
  await requireAuth(userId);
  return supabase.storage.from("notes").upload(`${userId}/${Date.now()}`, blob);
}

// The agent adds features on top:
export async function shareNoteAsPdf(noteId: string) {
  const note = await getNote(noteId);
  const pdf = await renderPdf(note);
  return uploadNote(note.userId, pdf);
}

The template's supabase, requireAuth, and storage.from("notes") are load-bearing infrastructure. They already work. They already have RLS. The agent's job is the last function, not the first three.

When prompt-to-app is actually fine

Marketing pages and landing sites (v0 is great for this)
Prototypes for design review
One-off internal tools without auth or payments
Learning what components look like

Prompt-to-app is a rendering technology. It's not a shipping technology. Use it for what it's good at.

FAQ

Q: Are prompt-to-app tools useless?
No. Great for prototypes and marketing pages. Poor fit for shipping real mobile apps.

Q: Won't they get better?
Some of it, over years. Code signing and App Store review aren't things LLMs prompt their way through. Bet on agents inside real projects, not agents inventing them.

Q: What stack should I pick?
Expo, TypeScript, Supabase, NativeWind, Stripe (+ Apple IAP for digital goods). Boring, well-documented, agent-friendly.

I keep a set of Expo + Supabase templates wired for exactly this workflow at Applighter.

What's the wall that cost you the most time — auth, payments, or submission? Drop it in the comments.

AI Coding Agents Need a Foundation, Not a Canvas

Russel Dsouza — Wed, 01 Jul 2026 13:10:48 +0000

Same prompt, two repos: blank Expo repo → 47min / $5.20 / un-mergeable; wired foundation → 11min / $0.85 / mergeable.
The model didn't get smarter. The repo got more legible.
AGENTS.md helps ~4% (hand-written) or hurts 2–3% (LLM-generated), per a 138-repo / 5,694-PR study. Both add >20% to token cost. It's not the fix.
A real foundation ships one visible convention per cross-cutting concern, typed boundaries, one way to do each thing, pre-installed skills, and a working end-to-end path.
The evaluation heuristic: "Open the repo and ask Claude Code to add a screen. If the first thing the agent does is install three packages, the foundation is decorative."

Cold open

I had a working theory that the gap between coding agents that "feel useful" and coding agents that "feel like a coworker" was a model gap. Smarter base model, better tool use, longer context window. The usual story.

Then I ran the same prompt against two different repos and the theory died on contact.

The prompt was: "Add a weekly summary screen that fetches the last seven days of data from Supabase and renders a bar chart." Mid-tier feature, nothing exotic. I ran it against a fresh npx create-expo-app and against a fully wired React Native / Expo / Supabase foundation.

Same model. Same prompt. Two completely different sessions.

On the blank repo, the agent installed three chart libraries, picked one, then quietly imported a different one in the second file it wrote. It hardcoded the Supabase URL. It invented an api/ folder, then later invented a services/ folder, then never used either. After 47 minutes and roughly $5.20 in tokens, it produced 600 lines of code I would not merge into anything.

On the foundation, the agent did something that, at first, felt anticlimactic. It opened one existing screen, read it, and then wrote one new screen that looked exactly like the existing one. Same chart primitive. Same data fetcher. Same file structure. 11 minutes. About 85 cents in tokens. Mergeable on the first read.

The model hadn't gotten smarter. The repo had gotten more legible.

The blank-canvas problem, named

Every coding agent — Claude Code, Cursor, Codex, Windsurf, the lot — is doing roughly the same thing under the hood. It reads the repo, then writes code that "fits." When the repo has shape, "fits" means matching the shape. When the repo has no shape, "fits" means matching the median of the public internet.

The public internet is a thousand React Native tutorials, each of which makes different micro-decisions. State library: Redux, Zustand, Jotai, Recoil, Context. Data fetching: TanStack Query, SWR, raw fetch, Supabase client wrappers. Navigation: Expo Router, React Navigation, stack vs. tabs vs. drawer. Theming: NativeWind, styled-components, StyleSheet, restyle. The "median" picks one of each, often differently per file.

This is the blank-canvas problem. The agent does not fail because it is dumb. It fails because every choice is open and the choices don't compose.

The AGENTS.md cul-de-sac

The current industry answer is AGENTS.md — a Markdown file at the root of the repo describing your conventions. I have written several. They help, in the way that a sticky note on the fridge helps. They do not solve the problem.

The numbers are unkind. A study earlier this year analyzed AGENTS.md impact across 138 repositories and 5,694 pull requests. The headline:

LLM-generated AGENTS.md files hurt agent performance by 2–3%.
Hand-written AGENTS.md files improved performance by 4%.
Both raised token costs by 20%+.

4% is not the breakthrough you were hoping for. It's noise.

The intuition behind why is straightforward once you sit with it: prose about code is a weaker signal than code itself. An agent that reads three screens which all use the same data fetcher infers, very confidently, that the fourth screen should use the same fetcher. An agent that reads a sentence in AGENTS.md saying "use the data fetcher in lib/" sometimes does, sometimes doesn't.

The pattern is the prior. The AGENTS.md is a cache.

What an actual agent-ready foundation contains

The phrase "agent-ready" is doing a lot of work in boilerplate marketing. Here is what it should mean, concretely:

1. Visible conventions

Every cross-cutting concern — auth, data fetching, navigation, theming, state, payments, push — appears in at least one fully wired screen. The agent has a working example to copy. Not three contradictory examples. Not one half-finished example. One canonical example.

2. Typed boundaries

// Supabase generated types — the agent cannot fake its way past these
export interface Database {
  public: {
    Tables: {
      daily_summaries: {
        Row: {
          id: string;
          user_id: string;
          date: string;
          total_calories: number;
          // ...
        };
        Insert: { /* ... */ };
        Update: { /* ... */ };
      };
    };
  };
}

If the agent calls a column that doesn't exist, tsc fails. The foundation makes the type system enforce the prior.

3. One way to do each thing

If your foundation has both Redux and Zustand, the agent will use both. If it has only Zustand, the agent will use Zustand. Foundations make choices the agent doesn't have to.

4. Pre-installed skills and slash commands

.claude/skills/
  add-screen.md           — knows where screens go, how they're wired
  wire-supabase-rpc.md    — knows how RPCs are exposed
  add-stripe-product.md   — knows the webhook layout

A skill is a scoped operation the agent can invoke directly. It is not prompt engineering. It is the foundation describing what it lets you do.

5. A working end-to-end path

Auth → database read → typed UI → push notification, all wired up once. The agent reads the whole chain in a single context window and now has a template for every future feature that touches the chain.

What a real foundation looks like on disk

Here's what a real React Native + Expo + Supabase foundation looks like when an agent opens it:

your-app/
├── app/                        # Expo Router screens
│   ├── (tabs)/
│   │   ├── index.tsx           # Home + today's entries
│   │   ├── add.tsx             # Camera + analysis flow
│   │   └── stats.tsx           # Daily summary chart
│   └── auth/
│       └── login.tsx           # OAuth + email + Apple
├── modules/
│   ├── db/
│   │   ├── supabaseClient.ts
│   │   └── supabaseServer.ts
│   ├── auth/
│   │   └── useAuth.ts
│   └── vision/
│       └── analyzeFood.ts      # Vision API integration
├── supabase/
│   └── migrations/             # Real, dated, ordered migrations
├── components/                 # NativeWind primitives
└── .claude/
    └── skills/                 # Scoped agent operations

When the agent opens this and you ask for a weekly-summary feature, it reads stats.tsx, reuses the chart primitive in components/, calls the same supabaseServer client, drops the screen in (tabs)/, and follows the same migration pattern if it needs a new column.

The agent never asks "what state library should I use?" because the repo answered the question.

The economics, in detail

I tracked twelve sessions across three teammates — six from blank repos, six from foundations — using the same model and same prompt categories. Averages:

Metric	Blank repo	Foundation	Delta
Tokens per shipped feature	$4.30	$0.95	4.5× cheaper
Wall time per feature	42 min	9 min	4.7× faster
Diffs requiring full rewrite	4 of 6	0 of 6	—
Hallucinated imports	11 total	1 total	11× fewer

This is not a controlled study. It is, however, consistent with what teammates and customers report. The gap is real and it is wide.

If you ship one app a year, the gap doesn't matter much — you'll spend a month either way. If you ship three or four, the gap is the difference between "we can" and "we can't."

What this does not mean

Two clarifications, because the foundation argument gets oversold.

A foundation does not replace judgment. The agent still ships things you have to review. The foundation just narrows what the agent can ship.

A foundation is not forever. Two years from now the model will be stronger, the framework will have shifted, and today's foundation will feel constraining. Throw it away when it does. Until then, it earns its keep every session.

How to evaluate any foundation you're considering

Whether you're considering a paid template, a free GitHub template, or something a friend shipped — the test is the same:

Open the repo and ask Claude Code to add a screen. If the first thing the agent does is install three packages, the foundation is decorative.

Other tests, in order:

Count real screens. Five or more, all using the same conventions, is the bar.
Grep for any. If the data layer leaks any, the agent has no priors.
Find the skills directory. No skills, no scoped operations, the foundation is half-built.
Read the migrations folder. Real, dated migrations are a foundation signal. A single init.sql is a boilerplate signal.
Run the first session. Token cost and wall-clock time will tell you everything within 15 minutes.

FAQ

Is a foundation just a fancy boilerplate?
No. A boilerplate is the packaging. A foundation is the wiring. Most boilerplates are not foundations.

Why doesn't a great AGENTS.md fix this?
It helps about 4%, per the 138-repo study. The pattern is a much stronger prior than prose about the pattern.

Does this only apply to React Native?
No. It applies to every stack. React Native is the worst case because its ecosystem is the most fragmented, so the gap is largest there.

Should I buy or build the foundation?
Build if you'll ship three or more apps on the same stack. Buy if this is your first or second.

If you take one thing away: do not hand an AI coding agent an empty room and ask it to build a house. Give it a foundation. Then ask it to add the rooms.

For the longer breakdown — including the specific "one way to do each thing" heuristics I use to audit a foundation — see the Applighter blog.

What's the weirdest thing an AI coding agent has done in your blank repo? Drop it in the comments — I'm collecting the failure modes for a follow-up. (Bonus points for a token-cost screenshot.)

Buy a React Native Template or Build From Scratch in 2026?

Russel Dsouza — Tue, 30 Jun 2026 09:59:09 +0000

You've run npx create-expo-app, and three days later you're configuring NativeWind v4 PostCSS, debugging Supabase deep-link callbacks, and writing your fifth token-refresh useEffect. The decision hits: keep grinding, or buy a $79 React Native template and skip to the actual product?

This post is a decision framework with the actual numbers. No marketing — the math leans toward buying, and the rest of this post explains exactly when it doesn't.

Buy when:

The app is a recognizable pattern (auth + DB + payments + a vertical UI)
You're solo or a two-person team
Your time is worth more than $50/hour

Build from scratch when:

The UX is genuinely novel
You have hard compliance (HIPAA, PCI L1, SOC 2)
You're learning React Native and the setup is the point
You're at 1M+ user scale on day one

The setup tax

Foundation work, before any product code:

Expo + TS + ESLint + Prettier ......... 4h
Expo Router v4 (typed routes) ......... 6h
Supabase auth (email/Apple/Google) .... 14h
NativeWind v4 + dark mode ............. 8h
TanStack Query + Zustand .............. 6h
Stripe / RevenueCat ................... 16h
Push (APNs + FCM via Expo) ............ 8h
Supabase Storage + RLS ................ 6h
Sentry + PostHog ...................... 4h
EAS Build + iOS/Android signing ....... 8h
─────────────────────────────────────────
Total .................................. ~80h

At $75/hr indie rate that's $6,000 of your time. At $150/hr US contract, $12,000. Most of those hours are commodity work — you are not building a moat, you are configuring app.json.

Template price tiers in 2026

$0–29     screen kits, free boilerplates (no backend, stale fast)
$49–99    full-stack with real backend (Supabase/Firebase/Node)
$199–499  vertical clones (food delivery, marketplace, dating)

If a $79 template saves 60 of those 80 hours, the effective hourly rate for from-scratch to win is under $1.32/hour. Don't be that cheap.

Buy vs. build at a glance

Factor	Build	Buy
Time to deployable build	3–6 weeks	1–2 days
Cash cost	$0	$49–499
Time cost	80–200h	2–8h customization
Code understood day 1	100%	60–80% (100% after a week)
Architecture quality	Your choices	Template's choices
Security posture	What you remember	What was shipped
Best for	Novel UX, learning, compliance	MVPs, vertical clones, agency work

The buyer's checklist

Before you buy, verify:

# 1. Is the backend real or mocked?
grep -r "mockApi\|fixtures" src/

# 2. React Native + Expo version
cat package.json | grep -E "react-native|expo"
# Floor in 2026: RN 0.81, Expo SDK 54

# 3. Leaked keys
git log -p | grep -iE "sk_live|service_role|AKIA"

# 4. TypeScript strict mode
cat tsconfig.json | grep strict

# 5. Last commit recency
git log -1 --format=%cd

# 6. License terms
cat LICENSE

If a template fails on (1) — backend is mocked — you don't have a template, you have a screen kit. You will rebuild the entire backend.

What "production-ready" should actually mean

Six bars a template should clear before it can use the phrase:

A Postgres schema with RLS you can supabase db push — see Supabase RLS docs
Auth flows that pass App Store review (Apple Sign-In mandatory if any other social)
Server routes for anything sensitive (no API keys on device)
Error / loading / empty states wired everywhere
EAS Build profiles producing signed iOS + Android binaries — see EAS Build docs
AI agents (Claude Code, Cursor) can extend it without breaking the architecture

The sixth is the 2026 bar that didn't exist in 2023. AI agents do their best work on known-good repos. Templates that confuse agents lose to ones that don't.

When buying wins

Your app is "X for Y" where both X and Y already exist
Solo / two-person team
Agency / contractor billing a client (license permitting)
You want a security baseline you didn't write at 1 AM
You're driving development with AI agents

When building wins

Novel UX with no obvious analog
Hard compliance constraints
Learning React Native — the setup is the point
Extreme scale on day one
Template stack is wrong for you (e.g., you need Firebase, template is Supabase)

A two-minute decision framework

Screen architecture obvious in 5 min of whiteboard? → buy
App describable as "X for Y"? → buy
Timeline < 60 days? → buy
Billing a client > $5,000? → buy
Learning React Native? → build the first, buy the second

Two or more "buy" answers and you don't need a calculator.

Disclosure

I work on production-grade React Native templates ($49–99 on RN 0.81 / Expo SDK 54 / Supabase). Bias acknowledged. The math still leans toward buying for most indie apps — and when it doesn't, the post above tells you exactly why.

Whatever template you evaluate, run the buyer's checklist above. A real template ships a real backend (schema, RLS, server routes), passing App Store review, with EAS Build profiles ready to go. If it doesn't ship those, the price you spent on it bought you nothing.

If none of the templates on the market match your app shape, build from scratch. That's the only honest answer to the buy-vs-build question.

For the longer breakdown — the FAQ and the line-by-line "what a real template ships" inventory — see the Applighter blog.

What's the foundation work that ate the most hours on your last React Native project? Drop it in the comments — I'm collecting the unglamorous setup tasks indie devs underestimate for a follow-up.

DEV Community: Russel Dsouza

Best React Native Starter Templates in 2026 (Compared)

Best React Native Starter Templates in 2026 (Compared)

What makes a good React Native starter template?

What developers usually search for

Popular React Native starter templates

Expo Router Starter

Ignite

React Native Boilerplates

gluestack-ui Pro

Questions to ask before choosing a starter template

Final thoughts

Gluestack-ui Pro: 55+ Production-Ready React Native Screens

Introducing gluestack-ui Pro

55+ Ready-to-use Screens

The Codebase & Architecture

Modern Tech Stack

Seamless Customization

Wrapping Up

How tinbase Reimplements Supabase's Wire Protocols in a Single Process (and Runs in a Browser Tab)

The problem

Why Supabase compatibility instead of yet another backend

The architecture

The hard parts

The numbers

What it looks like in practice

Honest limits

Links

React Native Performance Monitoring: Tools and Techniques for 2026

What "performance" actually means in React Native

The eight metrics that matter in 2026

The 2026 tooling stack

Development-time tools

Production observability

Minimum-viable production setup

A real diagnostic walkthrough: "the feed screen is laggy"

Step 1: Confirm in production data

Step 2: Reproduce on the right hardware

Step 3: Capture a trace

Step 4: Isolate the offender

Step 5: Verify in a canary

The New Architecture changes what you monitor

Bundle size and startup — the fixes that compound

FAQ

The takeaway

Why Supabase local dev needs 2.3 GB of Docker — and how we got it to 58 MB

Part 1: Where the 2.3 GB goes

Part 2: The key observation — it's protocols all the way down

Part 3: The architecture — one fetch handler

Part 4: The consequences of "pure fetch handler"

Part 5: How we know it's compatible

What this doesn't claim

Try the numbers yourself

Introducing tinbase — local Supabase without Docker (one process, real Postgres)

The problem

What tinbase does instead

Your code doesn't change

The weird part: it runs in a browser tab

It's not a dead end

Why we built it

Honest caveats

Try it

How to Publish Your Lovable App to the App Store (Without Rebuilding It Yourself)

Why you can't submit a Lovable app to the App Store directly

Why wrapping it in a WebView doesn't work

What a real conversion actually involves

The takeaway

5 Places Sensitive Data Leaks in a React Native App (and How to Plug Them)

1. AsyncStorage for anything sensitive

2. Real user data in design prototypes

3. Multi-stage AI workflows

4. Logs and crash reports

5. Bundled permissions

The pattern

You Don't Need 10 Refactoring Tools. Pick 2 From This Decision Tree.

The 3 questions

The 2-tool stacks

What you can skip

The real lesson

Prompt-to-App Is a Lie — Here's What Actually Happens