DEV Community

Cover image for Build vs Buy: What Founders Get Wrong About Templates
Nikolas M I
Nikolas M I

Posted on • Originally published at applighter.com

Build vs Buy: What Founders Get Wrong About Templates

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:

  1. Will my app look like shovelware?
  2. Will I get stuck when I need to change something?
  3. Is a $79 template recycled GitHub code?
  4. 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
Enter fullscreen mode Exit fullscreen mode

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",
      },
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

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} />} />;
}
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode
// 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;
    },
  });
}
Enter fullscreen mode Exit fullscreen mode

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

  1. You're building infrastructure, not a product.
  2. Your app's core primitive doesn't fit React Native (real-time sub-16ms, custom Metal shaders, on-device model runtime).
  3. You have engineers on payroll already and no launch pressure.
  4. 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:

  1. Buy a full-stack template
  2. Ship branded MVP in 3–6 weeks
  3. Get real user data
  4. 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.

Top comments (0)