---
title: "The real problem isn’t the code. It’s knowing what to skip."
author: "Lax Mariappan"
date: "2025-12-03"
categories: ["Blogging"]
excerpt: "Fork or build from scratch? The real problem isn't the starter template. It's knowing what to keep and what to skip. Keep it lean and simple."
canonical_url: "http://laxmariappan.com/the-real-problem-isnt-the-code-its-knowing-what-to-skip/"
---

# The real problem isn’t the code. It’s knowing what to skip.

Fork or build? Here’s what most developers get wrong

Every developer faces this question at some point.

You’re starting a new project. Do you fork an existing repo? Use a boilerplate? Or write everything from scratch?

Most people treat this as a technical decision. It’s not. It’s a priorities decision.

If you want to learn, build from zero

Starting from scratch forces you to understand.

You write the auth flow yourself. You configure the database. You make routing decisions. You see how state flows through the app.

It takes longer. But every line teaches you something. You’re not just copying patterns. You’re forming opinions.

This is how you grow as a developer.

If you need to ship, fork

Sometimes learning isn’t the goal. Shipping is.

You have a product idea. A client deadline. A side project you want live by the weekend.

In those moments, fork a solid starter. Or use AI to help you adapt a reference template. Get 80% done in an hour instead of a week.

Speed matters when you’re validating an idea or keeping momentum.

But here’s the real problem

The struggle isn’t picking a starter template.

It’s knowing what to keep and what to throw away.

Most boilerplates are bloated. They include auth, analytics, payments, email services, admin dashboards, theming systems, and five different UI libraries.

You don’t need all of that.

You need the smallest thing that solves your actual problem.

Keep it lean

When you fork, resist the urge to keep everything.

Strip out what you’re not using today. Cut dependencies. Remove features you’re not shipping in v1.

Complexity kills momentum.

Simple projects move faster. They’re easier to debug. Easier to refactor. Easier to understand six months later.

The best code isn’t the smartest code. It’s the simplest thing that works.

My approach

I use both.

When I’m exploring a new framework or stack, I build from scratch. Slowly. With intention.

I fork or use AI to reference templates and adapt them. Then I delete half of it.

I keep what serves the user. I cut everything else.

That’s the balance.

Learn when you can. Ship when you must. And always keep it simple.