What Project to Build to Land Your First Job (And Which to Avoid)
You've got the basics. You've finished a course or two. Everyone repeats the same thing: "build a portfolio project." But no one tells you which one. So you build a to-do app, a calculator, and a clock — because those are the tutorial projects — and then you wonder why no one calls you for an interview.
The problem isn't you. The problem is the choice of project. Let's fix that.
Why to-do apps, calculators, and clones don't work
It's not that they're bad for practice — quite the opposite, they're useful while you're learning. The problem is that tens of thousands of people have built them, step by step, following the same video. When an employer sees a to-do app on your profile, they don't see you — they see a tutorial they recognize by heart.
The same goes for an "Instagram clone" or a "Netflix clone." They show that you can follow someone else's steps. They don't show what an employer is actually after: whether you can solve a problem no one solved for you in advance.
What an employer actually looks for in a project
When someone hiring opens your project, they're unconsciously checking four things:
- Does it run live? A link I can open in a browser is worth ten times more than a screenshot or code I have to run myself.
- Does it solve a real problem? Even a small one, even a personal one — but real. "An app that tracks how much I spend on coffee" beats yet another generic clone.
- Does it have the whole chain? A frontend talking to a backend talking to a database. That shows you understand how software actually works, not just one slice of it.
- Is it clean? A tidy README, code you can read, a commit history that makes sense. Those are signals that you'll be a colleague people can work with.
Notice that none of these say "it has to be big" or "it has to use ten technologies." Small and finished beats big and half-done — every time.
Three projects that work
They're not spectacular — and that's the point. Each has the whole chain (frontend + backend + database) and each solves a real problem:
- A tool you're missing yourself. An expense tracker, a workout planner, a reading log, a small shared budget for flatmates. Because you use it, you know exactly what it needs — and that shows in the result.
- A small tool for someone you know. A booking page for a local barber, an order menu for a café, a member log for a gym. A real user = real requirements = a project that looks like a job, not an exercise.
- An app around data you care about. Pull data from a public API (sports, weather, prices), store it in your own database, and present it in a useful way. Shows you can work with real, messy data.
Pick one. Not three. One, all the way to the end.
The rule that changes everything: one project, finished
Five projects finished 80% are worth less than one finished 100%. That last 20% — the part that looks boring: fixing bugs, making it look right on a phone, writing the README, deploying — that's exactly the part most people skip. And exactly the part that reveals the difference between a beginner and someone ready for a job.
A finished, modest project tells a complete story: "I knew how to start, get stuck, work my way out, and ship." That's literally the job description of a developer.
Deployment isn't a bonus — it's part of the project
This is the part that costs the people who skip it the most. A project that only sits on your laptop, to an employer, practically doesn't exist. They can't open it, they can't try it, and they have to take your word for it.
A project with a link changes the whole conversation. "Here, open it — it runs live" is the strongest sentence a beginner can say in an interview. And deployment teaches you things tutorials never do: domains, DNS, HTTPS, servers, CI/CD. Employers notice that, because it means you can ship something to production, not just write code on your own machine.
The rule: a project isn't done until it has a link you can send.
If you'd like help
The hardest part isn't writing the code — it's choosing the right project, not quitting halfway, and getting it all the way to deployment. That's where 1-on-1 lessons help most: together we pick a project that makes sense for you, work through it like a real task (with code review, like on a team), and ship it live — on your own domain, with a Kotlin/Java backend, a PostgreSQL database, and a React frontend, deployed to AWS or Hetzner.
In the end you don't have "one more tutorial" — you have a project with a link you can put on your CV.
The first lesson is free. We can even use it to figure out which project makes the most sense for you to build.