In most jobs, what you do in the evenings and at weekends has no place on a resume, or only in one line under interests. In tech, it is different: a personal project can carry as much weight as professional experience, especially at the start of a career or after a career change. But not all projects are equal. A tool that people actually use, a library maintained for two years or a technically ambitious project catches a lead’s attention; a copied tutorial or an unfinished app can, on the contrary, weaken an application. This article helps you sort, describe a project in three lines and place it in the right spot for your level.
Why personal projects matter in tech
Three reasons explain the particular weight of personal projects for a developer.
They are verifiable. A recruiter cannot open the code you wrote for your employer. They can, however, open a public repository, install an app, try an online demo. It is rare proof in a recruitment process.
They show what you choose to do. A personal project reveals your technical interests, your way of approaching a problem without imposed specifications and your ability to see something through on your own.
They make up for a lack of experience. For a student, a recent graduate or a career changer, a well-built personal project partly replaces the professional experience that is still missing. It gives a concrete topic for discussion in the interview.
For an experienced profile, their role changes: they become a signal of curiosity and of keeping up to date, or proof of a skill the current job does not allow you to use.
Sorting: what deserves a place
Before adding a project, ask yourself four questions.
- Is it used? By you every day, by friends and family, by an association, by strangers who downloaded it. A project that serves someone has a story to tell: feedback, fixes, improvements.
- Is it maintained? A recently updated project, with up-to-date dependencies and regular fixes, shows practice over time. A project abandoned long ago says the opposite.
- Is it technically interesting? It does not need to be spectacular, but it should involve at least one real difficulty: a performance problem, offline synchronisation, a complex integration, processing large data, a non-trivial algorithm.
- Is it related to the target role? A mobile project for a mobile role, an API for a backend role, a data pipeline for a data role. An unrelated project can stay, but it comes after.
A project that answers "yes" to at least two of these questions deserves a place. A project that answers yes to none should come off the resume, even if it taught you a lot.
In practice, two or three projects are enough. Beyond that, the section becomes a list nobody reads.
Describing a project in three lines
A project is described like an experience, only shorter. Three elements are enough: what the project does and for whom, the stack and the technical difficulty, a result or a use.
Before: "Task management app in React."
After: "Training tracking app for an athletics club (React Native, Supabase), used every week by the coaches and about fifty athletes; offline synchronisation for stadiums with no network; published on both stores."
Before: "Open source contribution."
After: "Contributions to a Python data validation library: fixed two time zone handling bugs and added a validator, accepted by the maintainers after review."
Before: "Discord bot."
After: "Production release notification bot for a developer community (TypeScript, Discord API, GitHub webhooks): message-queue-based architecture, integration tests, deployed on a managed service for a year."
Each rewritten version gives the reader a reason to stop: real use, a named difficulty, a duration. Add a link to the code or demo, and check that it leads to a clean repository, as explained in our article on the GitHub link on a resume.
Where to put the section depending on your level
The position of the projects section depends on what else you have to show.
- Student or recent graduate: the projects section goes just after education, or even before it if your projects are more convincing than your internships. It can contain the final-year project, a notable group project and a personal project.
- After a career change or a bootcamp: projects go at the top of the page, after the summary and education, because they carry the proof of your skills. Our article on the resume after a bootcamp details the importance of the project continued after the programme.
- Experienced developer: projects move to the end of the resume, in a "Projects and open source" or "Other activities" section, in one or two lines. They complement the profile without competing with the experience section.
- Senior profile: a personal project only appears if it is significant (a library used by others, a notable contribution to a well-known project) or if it proves a skill missing from the professional background.
The mobile developer resume template shows an experienced developer who keeps, in a dedicated section, a personal app that is published and maintained with every system version: one line, but strong proof for a mobile role.
Projects that do more harm than good
Some projects weaken an application instead of strengthening it.
- Tutorials copied exactly: to-do list, social network clone, weather app following an online course. A lead recognises them immediately and concludes that you have not yet built something of your own.
- Unfinished projects with no mention of their status: an app that does not start, a broken demo link, an empty README.
- Projects that contradict the resume: a skills section announcing TypeScript and tests, and a project in JavaScript with no tests at all.
- Risky projects: tools that circumvent a service’s terms of use, careless collection of personal data, reused employer code. They raise a question of judgement.
- Too many projects: a list of ten projects dilutes the two that count.
An unfinished project does not necessarily have to go: it can stay if you state honestly where it stands and what you learned from it. It is the broken promise that bothers readers, not the lack of completion.
For a first job, these projects often make the difference between two applications, as our article on the first developer job points out.
A well-sorted projects section still needs to be readable: links visible in full, technologies as text rather than logos, a layout without columns. The TechCV editor takes care of this and produces a PDF from which recruitment software correctly extracts each project. You can add your projects to your resume in a few minutes.
Frequently asked questions
How many personal projects should I put on a resume?
Two or three, rarely more. Choose those that are used, maintained, technically interesting or directly related to the role. The others can remain visible on your GitHub without appearing on the resume.
Can a course project appear in the projects section?
Yes, if it is significant (final-year project, ambitious group project) and you specify your role. Exercises identical for a whole cohort are of less interest.
Do I need a personal project when I already have experience?
It is not essential. For an experienced developer, professional experience carries most of the proof. A personal project remains useful to show a skill you do not practise at work, or to accompany a change of direction.
How do I present a project that has users but little public code?
Describe the use, the stack and the technical difficulty, then offer a demo or a discussion in the interview. If the code is private, an architecture diagram in a public document can replace the repository.