Side projects are a real signal for self-taught developers trying to land their first job. They aren’t the only signal — open-source contributions, well-explained interview answers, and clean GitHub histories all matter — but for someone without commercial experience, a thoughtful side project is often the thing that gets the interview in the first place.

The mistake most aspiring devs make is picking the wrong project. Tutorials-with-a-twist projects (the to-do list app with a different colour scheme, the weather app calling a public API) don’t differentiate. Hiring managers have seen hundreds of these. The CV with a portfolio of three to-do apps signals that the candidate completed three tutorials, not that they can deliver software.

The projects that actually work are the ones that solve a real problem the candidate had, were built end-to-end including the unsexy parts, and demonstrate the trade-off thinking that production code requires. The specific problem matters less than the quality of the engagement with it.

A few project archetypes that work well: a tool the candidate uses themselves to solve a daily problem, a small SaaS that has at least one real user (even if that user isn’t paying), an integration between two services that the candidate found useful, or a contribution to a small open-source project that lets you point to actual merged PRs.

The opposite of the high-signal project is the over-ambitious clone. A “Twitter clone” or “Reddit clone” or “Spotify clone” demonstrates ambition rather than competence. The reasonable scope of a side project is much smaller than these — and the reasonable scope, executed well end-to-end, signals more about real engineering ability than half-built clones do.

What “end-to-end” actually requires: the project should run on real infrastructure (not just localhost). It should have at least basic CI. It should have meaningful README documentation. It should have at least a smattering of tests covering the most important code paths. It should handle the unsexy parts of software (configuration management, error handling, basic security) competently rather than ignoring them. The CV-padding side project skips all of these. The job-winning side project does them all.

Documentation matters more than candidates often realise. A project’s README is sometimes the only thing a busy hiring manager actually looks at. A clear README with a problem statement, design choices explained, and screenshots or a live demo link is doing real work for your application. A project without README — or with the default Create React App boilerplate README — fails this test even when the underlying code is good.

The deployment question is worth tackling. A project that lives on the candidate’s laptop is not deployable evidence. A project deployed somewhere reachable — a small VPS, a free tier on a cloud platform, a static site for the front-end and a free-tier backend — is. The deployment work itself is part of what employers want to see. If you can’t get your project running on real infrastructure, you can’t get a paid project running on real infrastructure either.

The technology choice is less consequential than people think. The project should use technologies appropriate to the problem and the candidate’s target jobs, but specific framework choices matter less than the depth of engagement with whatever was chosen. A cleanly-built Astro site with a small backend in Go is as impressive to most hiring managers as a similarly-clean Next.js full-stack project. The reasoning behind the choice is more important than the choice itself.

Code quality on side projects matters but isn’t the dominant signal. Hiring managers reading side-project code aren’t doing a code review. They’re looking for evidence that the candidate writes reasonable code, makes reasonable structural decisions, and isn’t producing copy-paste code from tutorials. The signal is “this person could be on my team” rather than “this person is brilliant.”

The project’s ongoing maintenance also signals. A project that has been worked on for a year, with consistent commits, design changes, and small improvements, signals more than a project finished in two weeks and abandoned. The maintenance signals that the candidate sticks with software past the initial-build excitement, which is most of what professional software work actually involves.

The post-project writeup is the multiplier most candidates miss. A blog post explaining the project — what it does, why you built it, what was hard, what you’d do differently — is gold for an application. The writeup demonstrates the communication skills that hiring managers care about as much as the code skills, and most candidates don’t do it.

For an aspiring dev with limited time, the practical recommendation is: pick one focused project, scope it tightly, build it end-to-end including the unsexy parts, deploy it somewhere reachable, document it well, write up the experience, and present it confidently. One project done this way is worth ten half-built clones in a portfolio. The hiring manager looking at one well-executed project will give you the interview that ten poorly-executed ones won’t.

The other practical advice: the project doesn’t need to be impressive in scope. It needs to be impressive in execution. A small, useful, well-built thing is the right starting point for a job-winning portfolio. Anything bigger is probably premature.