- I asked ~40 indie React Native devs one question: "What do you wish your boilerplate did differently?"
- Three wishes dominated: less opinionated navigation (28/40), TypeScript without wrapper-type overhead (24/40), and real dark-mode wiring, not just a CSS toggle (19/40).
- Nobody asked for more features. Not one. Every wish was subtractive.
- The next wave of boilerplates will win by shipping less, cleaner, with better exit points.
Over the past two months I've been talking to indie React Native developers about the boilerplates they use. The question that got the most useful answers wasn't "which boilerplate do you use?" — it was "what do you wish your boilerplate did differently?"
I've now heard back from about 40 devs across a handful of communities (r/reactnative, the Expo Discord, some Twitter DMs). The pattern is clear enough to be worth writing down.
How the survey ran and who answered
Informal, DM-based, ~10 minutes each. Sample skews toward:
- Solo devs and 2-3 person teams (35 of 40)
- Shipping paid apps, not free (~28 of 40)
- Using either an off-the-shelf boilerplate or one they'd built themselves (~half and half)
So the sample is biased toward serious builders — people whose CI/CD choices matter to their revenue. That's the right audience for a survey about tooling ergonomics.
The top three wishes, in order
1. Less opinionated navigation (28 of 40 mentioned this, often first)
Most boilerplates ship a navigation shape — tab bar with a stack per tab, a modal presentation pattern, a drawer for settings — and it's the choice devs said they most often had to unwind. The frustration wasn't the specific shape; it was that the boilerplate had committed to one before knowing the product.
What they wanted: a navigation layer they could rip and replace in an afternoon. What they got: a navigation layer that other screens assumed, so ripping it meant refactoring every screen.
2. TypeScript throughout, without wrapper types getting in the way (24 of 40)
Everyone wants TS. What they don't want is a boilerplate whose author defined 40 custom wrapper types on top of standard SDK types (Supabase, Stripe, Expo APIs) because they wanted stricter typing.
// ❌ What devs are complaining about
import type { AppUser } from '@/lib/types/user'
import type { AppSession } from '@/lib/types/session'
// You have to learn the boilerplate's vocabulary
// before you can find what you need in the SDK docs.
// ✅ What they want instead
import type { User, Session } from '@supabase/supabase-js'
// The SDK's own types. No translation layer.
The wish is TS-native, TS-first, but using the SDK's own types wherever possible. Wrap only when the SDK types are genuinely painful.
3. Real dark-mode wiring, not just a CSS toggle (19 of 40)
This one surprised me. Many boilerplates advertise "dark mode included" and what they mean is a theme toggle that swaps a color palette. What devs actually want:
- System-color-scheme detection that respects OS-level user preference
- Persistence of user override across app restarts
- Correct behavior for platform-specific dark-mode surfaces (iOS blur, Android edge-to-edge)
- Status bar + navigation bar following the theme
- Charts, images, and third-party components that don't fight the theme
"Dark mode included" should mean all of the above. Mostly it means a toggle.
The features nobody asked for
Equally interesting: nobody asked for more features. Not one respondent said "I wish my boilerplate had more built-in screens" or "I wish it included analytics + i18n + AI chat + [something]." Every wish was subtractive: less friction, less coupling, less opinion.
The implication is unusual for a product category: feature-heavy boilerplates are competing on the wrong axis. The market wants fewer, better, cleaner-seamed layers.
What that tells us about product/market fit for starter kits
Boilerplates are a maturing category. The first wave sold on feature counts because that was legible. The current audience has been burned by feature counts enough times that they now audit for extensibility. The next wave of boilerplates will win by having a smaller surface area and cleaner exit points.
That's a hard product story to tell. "We include less than the competition" doesn't sell landing pages. But it's what devs 6 months into a project actually want.
Conclusion: subtractive design wins in tooling
The finding I keep coming back to: developers judge tools by how well they get out of the way, not by how much they do. Boilerplates are no different.
If you're building a starter kit, the next feature to add is probably a layer to remove. If you're picking one, run the 60-minute strip-down test. Either way, subtractive design is the axis of quality.
Feature counts are dead. Long live ergonomics.
What did you wish your React Native boilerplate did differently? Drop it in the comments — I'm collecting responses for a follow-up survey and yours might be the pattern that makes the shortlist next time.
Top comments (0)