The 60-Minute Boilerplate Strip-Down Test

#reactnative #boilerplate #architecture #indiehackers

TL;DR

Feature counts on a boilerplate landing page are the easiest thing to market and the least predictive of quality.
The real test: fork the repo, start a 60-minute timer, and try to cleanly remove the auth layer.
If it comes out cleanly, the seams are good and the rest probably follows. If it fights you, you'll be maintaining someone else's architecture forever.
Three pre-fork red flags: auth sprinkled across screens, DB queries that also do auth checks, and navigation coupled to auth state at the app root.
Audit for ergonomics ("what happens when I change it?"), not for features.

When a founder friend asked me how to pick a React Native boilerplate last month, I gave them a test that took me a decade of shipping apps to formulate. It doesn't involve counting features, reading the README, or watching the demo video.

Here's the test: fork the boilerplate, open a timer, and try to remove one thing in 60 minutes.

That's it. If you can, buy it. If you can't, walk away.

Why feature counts lie about boilerplate quality

Every boilerplate landing page reads the same: "Includes auth, payments, database, push notifications, analytics, dark mode, i18n, [15 more features]." Feature counts are the easiest thing to market and the least predictive of quality.

What features on a landing page can't tell you:

How coupled the auth layer is to the DB layer
Whether the payment integration assumes Stripe (fine) or hard-codes Stripe API calls throughout the app (not fine)
How the routing shape will interact with the screens you actually plan to build
What happens when you want to swap the analytics provider

All of these are ergonomic properties. They're invisible until you try to change something.

The strip-down test: remove one thing in 60 minutes

The test I use: fork the repo, then try to remove the auth layer entirely. Not disable, not stub — actually remove it, cleanly, so a new dev looking at the repo wouldn't know auth had ever been there.

Why auth? Because it's the layer boilerplates most often over-integrate. If it comes out cleanly, everything else probably will too. If it doesn't, you're looking at a boilerplate that will fight you every week the project lives.

The 60-minute clock is important. It's not "can you do this" — anyone can, given a week. It's "does the codebase make it easy." A good boilerplate should let you remove a major layer in less time than it takes to grab a coffee and read Hacker News.

Run the same test on payments, on database, on navigation. Whichever one you're most likely to want to swap in your actual project is the layer to prioritize.

What passing the test tells you

If you can strip the auth layer in 60 minutes:

The boilerplate has clean seams between layers
Someone thought about extensibility, not just about features
The codebase respects your future decisions instead of pre-empting them

If you can't:

Layers leak into each other in ways the README doesn't advertise
Your future "let me swap Clerk for Supabase" migration will be a two-week project
You'll be maintaining someone else's opinions about architecture forever

The first is a boilerplate. The second is a fork you'll regret.

Three signals a boilerplate will fail the test

Before you even fork, three signals that tell you the test will fail:

Auth logic sprinkled across screens instead of contained in a service/hook. If AuthContext is imported in 30+ files, removing auth means editing 30+ files. Contain it and the removal is a delete + import fix.
Database queries wrapped in "business logic" functions that also do auth checks. These read as clean at first — one function to fetch a user's data — but they're impossible to reuse if you swap the auth layer. The repository pattern (auth-agnostic data access + a separate auth layer) is what you want.
Navigation coupled to auth state via wrapper components at the root. If your App.tsx has <AuthGate><Router /></AuthGate> and every screen assumes an authenticated user is present, you'll rewrite the router when you strip auth. Auth-aware routing at the route level, not the app root, is more strippable.

These are all defensible design choices for a specific product. They're bad choices for a starter kit that has to work across many products.

Conclusion: audit for ergonomics, not for features

The question "what does this boilerplate include" is the wrong first question. The right first question is "what happens when I want to change it?"

Every boilerplate looks great on day one, when you're using it for exactly the product it was built for. The one you'll want in month three is the one that let you strip the auth layer in an hour when your Clerk trial expired.

Make that the audit. Feature counts will follow. Ergonomics won't.

What's the first layer you'd try to rip out of your current boilerplate — auth, payments, or navigation? Drop a comment with the one that would fight you hardest.