Built a full-stack web app using React, Node.js and PostgreSQL.
It's true, but it tells the reader almost nothing. Thousands of people have built a React app. A recruiter wants to know what problem you solved, which parts you did yourself, and how they can tell it worked.
I write project bullets by answering three questions, using evidence that's already in the repo.
**
The three questions
**
- What problem does the project solve? Answer in one sentence that someone who has never seen the code would understand.
- What did you personally do? This matters most when other people touched the project.
- What evidence is there? Tests, a live deploy, a README, a measured result: anything a reviewer could check.
A bullet that answers fewer than two of these is really just a list of technologies.
A worked example
The candidate and project below are made up for this post.
Sara built ShiftSwap, a small app that lets staff at a café trade shifts. Her README says:
- The café's 12 staff used a WhatsApp group for swaps, and requests got lost
- App built with Next.js and PostgreSQL, deployed on Vercel
- Manager approves swaps with one click; both people get an email
- 41 tests covering swap rules (no double-booking, no overtime past 40 hrs)
- Used by the café for 3 months
That's enough material for three good bullets:
| Before | After | Why it's better |
|---|---|---|
| Built a full-stack web app using React, Node.js and PostgreSQL | Built a shift-swap app (Next.js, PostgreSQL) that replaced a WhatsApp group for a 12-person café team | It names the problem and who used it. The stack moves into brackets |
| Implemented an approval system | Added one-click manager approval with email confirmation to both staff, so swaps stopped getting lost | It says what the feature changed for the people using it |
| Wrote tests | Wrote 41 tests covering scheduling rules, including double-booking and the 40-hour overtime limit | Naming the rules shows she understood how the café actually works |
Every claim in the new bullets comes from the README or the repo.
When you have no users and no numbers
Most side projects never get users, and you shouldn't pretend yours did. You can still describe the engineering.
Say nobody ever used Sara's app. Her README still shows a deployed demo, a test suite, and a section explaining why she chose optimistic UI updates over waiting for the server. Those become:
- Built and deployed a shift-swap prototype (Next.js, PostgreSQL) with a public demo and setup docs
- Designed scheduling rules to prevent double-booking and overtime, covered by 41 automated tests
- Chose optimistic UI updates for swap requests and documented the tradeoff around conflicting edits in the README
There's no "increased efficiency by 40%" in there. A reviewer can open the repo and check every line, and I'd trust that over a number I can't verify.
If you want a second opinion after rewriting, I'm building Resumize AI. Its free checker flags weak bullets and shows which line each piece of feedback refers to. (Disclosure: I'm the founder.)
What's the hardest project on your resume to describe? Put it in the comments and I'll try rewriting one or two:))
Top comments (0)