List personal projects in a dedicated “Projects” section when they show skills the job asks for, especially if your work history doesn't show them yet. For each project, give its name, a link if one is public, the tools you used, your role, and one to three bullets about what you built and what it achieved.
Add a number only when you can explain how it was measured. A shipped feature, a documented method, a resolved problem, or an accepted contribution is often stronger evidence than a figure you can't defend. All the examples below are illustrative.
Where to put projects
- A “Projects” section works for most people. Place it after Experience, or before it when the projects are more relevant than your jobs (common for students, career changers, and self-taught developers).
- Under a job when the project was part of that role. Keep it in that role's bullets rather than listing it twice.
- In Experience only when the work was paid or formally arranged, such as freelance or contract work. The guide to listing freelance work on a resume covers that case.
Choose two to four projects that match the target role. One relevant project with detail beats six one-liners.
What to include for each project
- Name and link: a repository, live site, case study, or publication, tested while signed out.
- Tools or methods: the languages, platforms, or techniques the job also asks for.
- Your role: solo, lead, or contributor. Credit collaborators accurately.
- Dates: a month and year range, or “ongoing.”
- Evidence: what you built, who used it, or what changed.
Example entry:
Room booking tool, personal project · React, PostgreSQL · 2025–present
- Added conflict detection for overlapping bookings, wrote integration tests for boundary cases, and documented the scheduling rules.
- Added an index for the event-date query and reduced a fixed local test script's median response time from 480 to 190 milliseconds across repeated runs.
Give every metric context
Before adding a number, record:
- Definition: What does it measure?
- Baseline: What earlier state does it compare against?
- Period: When, and for how long, was it measured?
- Method: Which tool, test, or process produced it?
- Scope: Which users, files, tasks, or versions does it include?
- Contribution: Which part came from your work?
For accuracy, name the test set and the calculation. For growth, state the starting value and the period. Without this context, a precise figure can imply more than it proves. In the booking example above, the time saving came from a local test, so it shouldn't be presented as production impact.
Useful sources include version history, test output, analytics you're authorized to use, issue trackers, accessibility audits, publication records, and approved project documents.
Examples by project type
Design and creative projects
Use completed deliverables, documented user needs, accessibility checks, tested prototypes, or published work.
Revised a library reservation prototype after five volunteer task sessions revealed confusion between pickup location and collection time; documented the findings and design changes.
Without a metric: “Created accessible form patterns and annotated focus, error, and help-text behavior for developer handoff.”
Community and open-source work
Useful evidence includes accepted contributions, reproduced issues, improved documentation, releases you supported, or community processes you created. Stars and downloads rarely prove your individual impact.
Reproduced an intermittent import error, added a failing test case, and submitted documentation accepted with the subsequent fix.
Link to the public record and describe your part accurately.
Research and data projects
Focus on data provenance, reproducible methods, cleaning rules, uncertainty, evaluation definitions, or the decisions your work supported.
Trained a baseline image classifier and reported 81% accuracy on a held-out test set, with class imbalance and common errors documented.
Be ready to explain the data source, the split, leakage checks, and why accuracy is the right measure. Without a headline result: “Built a reproducible cleaning pipeline and documented exclusions, missing-value rules, and validation checks.”
Content and audience projects
Evidence may include a consistent publishing record, a defined audience, authorized analytics, completed interviews, citations, or content you maintain.
Published three monthly newsletter editions and recorded a 42% unique open rate among recipients of all three, using the platform's definition.
Keep the platform's definition, and don't treat opens as satisfaction. Without a metric: “Planned and edited an interview series, obtained publication permission, and created a fact-checking checklist.”
Avoid weak or misleading evidence
Raw page views without a period, repository stars without attribution, and totals from before your involvement add little. Ask what a number helps the employer understand. If it doesn't clarify relevant skill, scale, quality, or adoption, leave it out.
Credit collaborative work with verbs such as “contributed,” “partnered,” or “maintained.” The guide to writing resume bullet points helps separate context, action, and evidence.
Final check
Before you include a metric, make sure you can explain its source, period, baseline, method, scope, your contribution, and its limits. Then check that each project you list supports the role. In Better Resume, projects live in a custom section of your base resume, so a tailored copy can lead with the ones that fit each job.