React, Node.js, and PostgreSQL tell a reader which tools you named, not what you built. A useful software project entry explains the problem, your implementation, and a check or trade-off you can discuss. Use the worked revision below to move beyond a stack list.
The short answer
Describe a project's purpose, your own contribution, the relevant tools, and a testing or design decision. Label it as personal, academic, volunteer, or professional work. Link to inspectable material when appropriate, and distinguish a demonstration app from a production service or commercial result.
See the worked exampleWorked example: turn a stack list into a project entry
Suppose your notes say only React, Node.js, PostgreSQL. Ask what the app did, which part you owned, and what you checked. In this fictional project, the applicant built a booking interface, wrote date-validation tests, and documented setup. Those details create a technical conversation without needing a made-up user count.
Choose one detail that matters to the role. For a frontend vacancy, explain the interaction or accessibility work you performed. For a backend vacancy, a data model or API-validation decision may be more relevant. Keep the fuller explanation in the repository so the CV remains readable.
Choose evidence for the development work in the vacancy
The National Careers Service describes development work as more than coding: it includes discussing requirements, testing, recording changes, and maintaining systems. Compare those activities with the particular vacancy. Our suggestion is to choose projects that show relevant parts of that work, rather than treating a long technology list as the whole application.
Avoid including several projects that demonstrate exactly the same thing unless their differences matter. One well-explained form, a tested API, and a deployment exercise can show different kinds of work. Use the project selection to complement, rather than repeat, your employment history.
Explain the purpose and your own contribution
Give the project a short descriptive name and identify it as personal, academic, volunteer, or professional work. Explain who it was for and what you implemented. If a team built it, distinguish your contribution from the overall application.
MIT recommends explaining how work was performed, including a programming language where relevant, and supports including class or personal projects. Put the technology in the task: built a booking form in React and validated submitted dates. Keep the project setting and official job titles accurate; the examples here are Folio's fictional illustrations.
Sources: MIT CAPD: Resumes
Include a decision, check, or constraint
Choose a detail that shows how you approached the work: handling invalid input, testing an edge case, documenting an API, reviewing accessibility, or adapting a layout to small screens. Do not imply that one check proves the entire application is secure, accessible, or production-ready.
State measured results only when you know how they were measured. If performance improved in a local test, explain the conditions rather than presenting the figure as a real-user outcome. An honest limit can make a project easier to discuss, because it shows you understand what it does and does not demonstrate.
Link to work a reviewer can actually inspect
Open the repository and demo links in a signed-out browser. Check the README, setup instructions, and whether screenshots or a short description would help. Use a stable link to the work you discuss, not a page that requires the reviewer to request access.
Respect confidentiality and ownership. Do not publish private code, employer information, credentials, or user records to provide evidence. You can describe a contribution without linking to proprietary work. For tutorial-based projects, explain what you implemented or extended rather than claiming the entire design as original.
Fit the projects into a readable CV
For an early-career application, place strong projects near education or before unrelated jobs. For an experienced engineer, relevant employment may carry more weight. Keep a concise skills section, then use project and work entries to show those skills in use.
Start from the software developer CV example or frontend developer example. Use the bullet builder to structure a contribution, then check the layout in a plain ATS-friendly template.
Review a software project before listing it
- The problem and intended user are understandable.
- Your contribution is distinct from teammates' or tutorial code.
- At least one technical choice or check is explained.
- Repository and demo links work without private access.
- No private code, credentials, or user records are exposed.
Frequently asked questions
Can I include personal projects without professional experience?
Yes. Label them clearly, explain what you built, and state any important limits. Do not present a demonstration project as paid client work.
Should every project include a performance number?
No. Use a number only when you can explain its measurement. A specific implementation or testing contribution can be useful on its own.
Sources and further reading
Sources checked on . Examples are fictional; practical suggestions are Folio's own application of the guidance.