To show a side project on your resume, include it only when it's relevant to the job you want, put it in a Projects section (or list it like a job if it has real users or revenue), and describe it in one line plus two or three bullets: the problem, what you built, and a real outcome. Make the proof clickable with a live demo, a short README and a one-minute walkthrough. In interviews, tell a two-minute story about why you built it, one hard decision, what broke and what you'd change. Never inflate the title or invent numbers.
This guide is for developers, designers, PMs and indie makers with a day job or a job search who built something on nights and weekends and want it to count. Platform details were checked against GitHub Docs and LinkedIn Help in October 2026. The example near the end is made up, and so are its numbers.
Does a side project belong on your resume?
Relevance decides it, not size. A small tool that shows exactly the skill the job asks for beats a big app in a field nobody at that company cares about.
A quick test I use: if a hiring manager for this specific role read the entry, would they learn something about how you'd do the job? If yes, it goes on. If they'd just learn you have hobbies, it probably doesn't, at least not on a tight one-page resume.
Side projects earn their space when they do one of these:
Fill a gap. You're a QA engineer applying for backend roles, and the project is the only backend code you've shipped.
Show a skill your job title hides. Your title says "support specialist" but you built and run a small web app.
Have real users. Even a dozen people who use it every week tells a reader the thing works outside your laptop.
Give you a story. You can talk about it for ten minutes without notes, including the parts that went wrong.
Leave it off when it's a tutorial you followed step by step, when it's unrelated and you're short on space, or when you'd struggle to explain how it works. Anything on your resume is fair game for questions, so only list what you can defend.
Where does a side project go on a resume?
For most people, a Projects section is the right home. Put it below your work experience if your jobs already show the skills, or above it if you're switching careers or early in your career and the projects are your strongest evidence.
List it like a job only when it behaves like one: real users or paying customers, ongoing upkeep, and decisions you made under real constraints. Even then, label it honestly. Something like "Creator and solo developer, Ropeshelf (side project), Mar 2025 to present" (from the made-up example below) tells the truth and still reads well.
What you shouldn't do is turn it into a fake company. "Founder and CEO" of a one-person app with eleven users invites exactly the follow-up question you don't want, and a reader who checks will stop trusting the rest of the page. If you genuinely run it as a small business with customers, "Founder" is fair. Otherwise "Creator", "Builder" or "Solo developer" is accurate and nobody will think less of you for it.
A few format details that save reader effort:
Month and year for dates, and "present" if it's still live.
One short link per project, not three.
Two or three projects at most. Pick the ones that match this role.
How do you write the description and bullets?
Start with one plain line: what it is and who it's for. "A web app my climbing club uses to track shared gear" beats "A scalable full-stack platform for asset management."
Then two or three bullets, each doing one job:
The problem. What was annoying, slow or broken before you built it.
What you built. The main thing it does and one decision that shows judgment, with the stack mentioned in passing.
A real outcome. Something that happened because it exists.
If you want a formula, Laszlo Bock, Google's former head of people operations, shared one in a LinkedIn post that Quartz republished as how to write a resume that gets you hired at Google: "Accomplished [X] as measured by [Y] by doing [Z]." He explains it as starting with an active verb, measuring what you accomplished, giving a baseline for comparison, and saying what you did to get there.
It works for side projects too, with one adjustment: your Y will be smaller than at a day job, and that's fine. "Cut the club's monthly gear check from about an hour to 15 minutes by replacing a paper sign-out sheet with a shared web app" is a strong bullet. It doesn't need a million users to be specific.
Keep the stack to a short "Built with" line at the end of the entry. A list of fourteen technologies reads like keyword stuffing. Three or four that you actually used, and could answer questions about, is plenty.
What counts as an outcome when you only have a handful of users?
More than you'd think. Outcomes don't have to be growth charts. Any of these is real and checkable:
It shipped and it's live. "Live since March 2025" already beats most unfinished repos.
A real user count. Twelve weekly users is a fine number if it's true. Use the actual count.
A process got faster. From N minutes to M minutes, if you measured it or can explain how you estimated it.
A public launch. A launch page with a date shows you finished something and put it in front of strangers.
A stack the role uses. "First production app in Django and Postgres" matters when the job is Django and Postgres.
It survived something. You kept it running for a year, fixed a real outage, or handled a data migration.
The hard rule: never invent a metric. If a number is an estimate, say "about" and be ready to explain how you got it. Expect "how did you measure that?" for any number you list. A small true number holds up. A big made-up one falls apart on the first follow-up.
How do you make the proof clickable?
The link is half the entry. A reader who clicks and finds something working believes the bullets. A reader who clicks and finds an error page doubts them. Give them something that works in under a minute:
A live demo that stays up. Check the link the week you start applying and keep checking it, because a hiring manager might click it weeks later. A few simple checks that tell you when a side project goes down during your day job cover this.
A short README. One sentence on what it does, who it's for, how to run it, the stack, and what you'd build next. Five short sections, not a novel.
A 60-second walkthrough video. One take, showing the main job from start to finish. It's the fallback when the demo is down.
A demo login with sample data, so nobody has to create an account to see it work.
If the code is public, the repo becomes part of the proof, so make sure it's something you're happy for a stranger to read. Before you flip a private repo public just for job hunting, go through what to check before you open-source a side project, especially old commits.
And use a link that will still work in six months. A random preview URL from your host can change. A domain or a stable project page won't.
How should a side project show up on LinkedIn, GitHub and a portfolio?
Some readers will check your profiles too, so make the same project tell the same story everywhere.
LinkedIn has a dedicated Projects section. Its help page on adding sections to your profile lists Projects under the Recommended sections you can add from "Add profile section" in your intro. One quirk worth knowing: the same page says the Project URL field isn't available for newly added projects, so to add a link you use Add media, then Add a link. Reuse your resume line and bullets so the two match.
GitHub
If you're a developer, pin the repo. GitHub Docs on pinning items to your profile say you can choose up to six repositories and gists combined, and the profile reference adds that you can pin a public repo you own or have contributed to in the last year. Once you pin something, the Pinned section replaces Popular repositories on your profile, so you decide what a visitor sees first.
A portfolio page
One page per project works better than a grid of thumbnails. Cover the problem, your role, one decision you made, the outcome, and the links. For designers and PMs, it's where your thinking shows.
How do you talk about a side project in an interview?
Prepare a two-minute version and practise it out loud. Here's the structure I'd use. The timings are a rule of thumb, not a science:
Why you built it (about 20 seconds). The real reason. "My club lost a rope and nobody knew who had it last" is better than "I wanted to learn React."
What it does and who uses it (about 20 seconds). One sentence each.
One hard decision and the trade-off (about 40 seconds). The part interviewers remember. What you chose, what you gave up, and why.
What broke (about 25 seconds). A real bug, outage or bad assumption, and how you found and fixed it.
What you'd change (about 15 seconds). Shows you can look at your own work critically.
If the interviewer asks a behavioural question, the same material fits the STAR format (Situation, Task, Action, Result). MIT's career office guide to using the STAR method in behavioral interviews suggests spending most of your answer, around 60 percent, on the actions you personally took, and keeping the situation and task short. Side projects are handy here because every action really was yours.
Then prepare for the follow-ups, because that's where the interview actually happens:
Why that stack and not another one?
How many people use it, and how do you know?
What would you do with another month?
Can you show me the code or the app?
For that last one, have it ready: the app open in a tab, logged into the demo account, with a two-minute path through the main job. If the connection is flaky, switch to the walkthrough video rather than apologising for a spinner.
What if they worry it will distract you from the job?
Some interviewers will ask, directly or not, whether the project will eat your focus. Answer honestly and specifically. Say how much time it takes now ("a couple of hours a week, mostly upkeep"), what stage it's in, and what it taught you that helps in this role. If you're hoping it becomes a business one day, don't pretend otherwise, but be clear about what you're committing to this job.
One practical note: if you build while employed, check your employment agreement and company policy on outside projects. That's a general pointer, not legal advice.
Do failed or abandoned side projects still count?
Yes, often more than you'd expect. A project you stopped on purpose shows you can read evidence and make a call, which is a skill most jobs need.
Label it honestly ("paused", "archived" or "shut down") and make the bullets about what you learned and why you stopped. "Stopped after six weeks when five interviews showed teams already solved this with a spreadsheet" is a perfectly good bullet. If you made that call with a clear process, like the one in deciding whether to kill, pause or double down on a side project, say so in the interview. It sounds like judgment, not failure.
Keep something clickable even for dead projects: an archived repo with a one-paragraph note at the top, or a short write-up.
How honest should you be about AI-assisted work?
Completely. If AI tools wrote a chunk of the code, say what you did and what the tools did: you designed the data model, made the trade-offs, reviewed and tested everything, and the tool drafted boilerplate. Interviewers will ask you to explain your own code, and "I'm not sure, the assistant wrote that part" ends the conversation badly. If you can explain every part and defend every decision, the help you had isn't a problem.
A made-up example: Tamsin and Ropeshelf
Everything here is made up: the person, the project and every number.
Tamsin is a QA engineer at a logistics company applying for junior backend developer roles. On weekends she built Ropeshelf, a small web app her climbing club uses to track who borrowed which shared ropes and harnesses. It replaced a paper sign-out sheet that kept going missing. Twenty-three members use it, and the monthly gear check went from about an hour to about 15 minutes (she timed the last two checks with the paper sheet and the first two with the app).
Here's her first draft next to the version she sent:
Part | Weak version | Strong version |
|---|---|---|
Title line | Founder and CEO, Ropeshelf | Creator and solo developer, Ropeshelf (side project), Mar 2025 to present |
Description | Scalable full-stack asset management platform | Web app my climbing club uses to track shared ropes and harnesses |
Bullet 1 | Built a revolutionary gear solution | Replaced a paper sign-out sheet that went missing twice in one season |
Bullet 2 | Used React, Django, Postgres, Docker, Redis, Kubernetes, AWS and more | Built a Django and Postgres back end with a borrow history per item, so overdue gear shows up automatically |
Bullet 3 | Thousands of users love it | Used weekly by 23 club members; monthly gear check down from about an hour to about 15 minutes |
Link | None, or a dead preview URL | Live demo with a demo login, plus a public repo with a short README |
Her two-minute interview version: the club lost a rope and nobody knew who had it (why). The app logs every borrow and return and flags anything out for more than two weeks (what). She chose a plain server-rendered app over a separate front end because she'd maintain it alone on weekends, and gave up some polish to do it (decision). The first version let two people borrow the same harness at once, which she found when a member emailed her, and fixed with a database constraint and a test (what broke). Next time she'd write the tests before inviting anyone (change).
Nothing in that story is big. All of it is specific, true and easy to ask about.
A pre-send checklist
Check | What good looks like |
|---|---|
Relevance | Each listed project matches a skill in this job description |
Title | Honest role and "(side project)" label, no inflated titles |
Description | One plain line: what it is and who it's for |
Bullets | Problem, what you built, a real outcome |
Numbers | Every number is true, and you can explain how you got it |
Stack | Three or four tools you actually used |
Link | Clicked today, loads in seconds, demo login works |
Backup proof | README and a 60-second walkthrough video exist |
Consistency | Resume, LinkedIn Projects entry and pinned repo tell the same story |
Interview story | Two-minute version practised out loud, follow-ups prepared |
Common traps
Listing ten tiny tutorials. A to-do app, a weather app and a calculator say less than one project with real users. Pick your best two or three.
Dead demo links. The fastest way to undo a good bullet. Click every link before every application batch.
Buzzword stacks. If you can't answer a question about a tool, take it off the line.
Inflated titles. "CEO" of a solo weekend project costs you more trust than it buys.
Fake metrics. One invented number makes a reader doubt the true ones next to it.
FAQ
Should I put an unfinished side project on my resume?
Only if part of it works and you can show that part. Describe what's live, not what's planned, and mark it "in progress." If nothing runs yet, finish one small piece first, or leave it for the interview conversation instead.
Where do side projects go on a resume?
In a Projects section by default, below experience if your jobs already show the skills, above it if you're switching fields or early in your career. List one like a job only if it has real users or revenue and ongoing work, and label it as a side project either way.
Do recruiters actually look at side projects?
It varies by company, role and person, and I won't pretend there's a reliable number. What you control is making it easy: a relevant project, a clear bullet and a link that works in one click. If someone does look, they find proof. If they don't, the entry still shows skills in plain words.
Give your project a page you can link
Pick the one project that fits the role best. Write one line and three honest bullets, click the demo link, write a short README, record a one-minute walkthrough, and practise the two-minute story out loud. That's an evening's work, and it turns a side project on your resume from a line people skim into proof people can click.
If your project doesn't have a public home yet, list it on SideHunt. You get a public page with a launch date that you can link from your resume and LinkedIn, alongside other builders shipping on nights and weekends.