Your First Side Project
From Picking an Idea to Launch

90% of people get stuck on "I don't know what to make", and the other 10% get stuck on "scoped it way too big and never finished". This breaks it all down ─ 5 rules for picking an idea, how to cut scope, a 4-week launch timeline, and the 7 traps you'll fall into. For career-changers, students, side-hustlers, and indie hackers.

Why the first project is so hard

There are 3 reasons:

1. No constraints → overthinking ─ nobody's forcing you to build X, so you want to build everything and spend 3 months stuck on "what should I make"
2. No reference points → can't cut scope ─ you decide to build an "Instagram clone" and underestimate the work by 5x
3. No community → one block and you're done ─ you debug all night with nothing to show, and you quit the next day

What this post is here to fix isn't "writing code" ─ it's "picking the right idea + cutting the right scope + sticking it out to the finish".

The 5 rules for picking an idea

01 You'd use it yourself

This is the most important rule, and 80% of people ignore it.

Build something you'd actually use yourself. The upside:

• You have real motivation (when you see a bug you want to fix it, instead of thinking "eh, whatever")
• You know how the features should work (you ARE the user)
• When it's done, someone actually uses it ─ at least you

Build something you "think is cool but would never use yourself" and you'll abandon it halfway 99% of the time.

02 Solve 1 specific pain point, not 10

Wrong: "I want to build a productivity tool"
Right: "I want to build a little tool that automatically turns my weekly commits into a status report"

The more specific, the better. The more specific, the better. The more specific, the better. Worth saying 3 times.

03 You can finish it in 4 weeks

If it takes more than 4 weeks, you'll quit 99% of the time.

So ─ no matter how cool your idea is, cut it down to the smallest version you can finish in 4 weeks.

Want to build a "Discord bot that auto-organizes meeting notes + AI summaries + multi-language support + export to Notion + Slack integration"? Cut 4 of them, keep just 1.

Add the rest after you launch.

04 It involves 1-2 things you know + 1 thing you want to learn

Pure practice of stuff you already know → no growth, boring.
Everything brand new → you get stuck and quit.
2 things you know + 1 new thing → the perfect ratio.

For example: you know React + Node and want to learn "AI API integration" ─ build a little tool that uses the OpenAI / Claude API, spending 80% of your time on what you know and 20% learning the new thing.

05 It can become "something you're proud to put on your resume"

This rule decides whether your project is "practice" or an "asset".

A resume-worthy project:

• Can be visited in a browser (not just screenshots)
• Has a README that explains "why I designed it this way"
• Lets a stranger understand what it does in 30 seconds

A "demo that only runs on your own machine" ─ that's practice, not an asset.

20 ideas that are great for a first project

If you have no idea at all, pick from these 20:

Cutting Scope ─ the 3-step method

Step 1: Write the "perfect version"

First, let yourself dream: "If I had a full year, what would the complete version of this project look like?"

Write it all down ─ no self-censoring, list whatever comes to mind.

Step 2: Find the 1 core feature that "has no meaning without it"

From that list, find the 1 feature where "without it, the whole project is pointless".

Example: the core of an expense-tracking app is "enter a transaction + see your spending total". Without that, it's not an expense tracker.
Everything else (categories, reports, budgets, multi-currency) is nice-to-have.

Step 3: The launch version does only this 1 thing

The first version does only the 1 core feature + a UI that lets people "see what this thing does".

That's your 4-week version.

Everything else ─ add it after launch, and add it only once people are actually using it.

The 4-week launch timeline

The 7 traps 90% of people fall into

01 Getting stuck on "which framework should I use"

Don't spend a week researching "should I use Next.js or SvelteKit" ─ grab the one you know best and start writing.

The framework for your first project doesn't matter ─ finishing it matters more.

02 Endlessly adding features, never launching

Every "while I'm at it" feature you add pushes your launch +1 week.

Give yourself a mantra: "Launch first, add features later". A project that never launched doesn't exist.

03 Thinking the UI has to be beautiful before you launch

Ugly UI is fine. An ugly version you can demo > a perfect version forever stuck in design.

Recommendation ─ use an off-the-shelf component library like Tailwind UI / shadcn/ui / Mantine. 10 minutes to make the UI look OK.

04 Not writing a README

A GitHub repo with no README = it doesn't exist.

At minimum, write ─ "what this is", "how to run it", "why I built it". 3 paragraphs, 5 minutes of work.

05 Not deploying

"It runs on my machine, let me demo it for you" VS "click the URL and it works" ─ the latter is worth 10x the former.

Vercel / Cloudflare Pages deploys are free and take 5 minutes to set up. No reason not to deploy.

06 No tests + no monitoring

Your first project doesn't need 100% coverage, but at least:

• 1 test (testing the core feature)
• 1 error tracker (Sentry's free tier)

These 2 things take your project from "practice" to an "engineering piece".

07 Finishing it but never going public

Done ≠ over. A project nobody knows about = a dead line on your resume.

After you launch, you absolutely must:

• Write 1 short post (Threads / LinkedIn / Blog)
• Put the URL on your GitHub profile
• Put it on your resume + describe it in one sentence

Public = people can see it = opportunities can find you.

One last reminder

The goal of your first project isn't to be perfect ─ it's to be finished.
Finishing 1 ordinary project > planning 10 great ones.
Once it's done, you'll find the second one goes 3x faster than the first.

Over these 4 weeks, you'll find you've changed ─ not because you learned a new technology, but because "turning an idea into something you can actually demo for the first time" changes how you see yourself.

Once you've built something once, you know you can build it again.

This is an engineer's biggest unfair advantage.