Projects
15 Developer Portfolio Projects That Demonstrate Real Skills
Fifteen project ideas grouped by the specific capability each one proves to a reviewer, with honest scope and time estimates.
Every list of portfolio project ideas has a to-do app on it. The problem is not that a to-do app is bad — it is that it does not prove anything, because everyone has one and none of them are hard.
A project demonstrates a skill when a reviewer can look at it and infer something they could not have assumed. That inference is what you are actually building. So the useful way to group projects is not by difficulty or by stack, but by what each one lets someone conclude about you.
If you want to prove you can finish something
The most common gap on a junior portfolio is not sophistication. It is completion.
1. A developer utility CLI. Five or six subcommands — timestamp conversion, JSON formatting, UUID generation, base64, hashing. Reads from arguments and from piped stdin, has a real --help, uses correct exit codes. Publish it to npm, PyPI or Homebrew so it installs in one command. One weekend. Proves: you understand the tools you use daily, and you can ship something to a package registry.
2. A URL shortener with click analytics. Submit a long URL, get a short code, count clicks, show stats per link. One to two weekends. Proves: HTTP fundamentals. The interesting question is why you chose 302 over 301 — a permanent redirect gets cached by the browser and your click counter stops working. Being able to say that is worth more than the project.
3. A module deadline tracker for your course. Deadlines, weightings, days remaining, mark as submitted. One to two weekends. Proves: you can ship something people actually use. Twenty classmates using it is more convincing than a hypothetical market of millions.
If you want to prove you can model data
4. A shared-house expense splitter. Add expenses with a payer and an uneven split, calculate running balances, settle up. Two weekends. Proves: you handle money in integer minor units rather than floats, and you calculate balances from a ledger instead of storing a mutable total. Both are things a reviewer will check.
5. A recipe cost calculator. Ingredients with pack prices, recipes built from them, cost per portion accounting for partial packs. One to two weekends. Proves: a clean many-to-many relationship, and careful unit conversion — grams against millilitres, rounding money correctly.
6. A spaced-repetition flashcard app. Decks, cards, a review session, and scheduling based on recall rating. Two weekends. Proves: you can read a published specification (SM-2 is well documented) and translate it into working code. That is most of what junior engineering actually is.
If you want to prove you understand concurrency
This is the area where junior candidates most often have nothing to say, which makes it the highest-value place to build.
7. A cinema seat booking system. Seat map, temporary holds during checkout, automatic release when a hold expires. Three weeks of evenings. Proves: you know what happens when two people try to book the same seat, and you fixed it with a transaction or a database constraint rather than hoping.
8. A society events platform with capacity limits. Sign-ups with a maximum and a waiting list, with promotion when someone cancels. Three to four weeks. Proves: the same concurrency understanding, plus authentication, roles and transactional email. If you build it for a real society you also get real usage.
9. A distributed task queue. Enqueue jobs, workers claim them, retries with exponential backoff, a dead-letter queue for jobs that give up. Four to six weeks. Proves: you can reason about delivery guarantees and worker failure. Postgres with SELECT … FOR UPDATE SKIP LOCKED is an elegant approach that removes the need for Redis entirely — explaining that tradeoff is a strong interview moment.
If you want to prove you can handle data you don't control
10. A recipe scraper and meal planner. Parse recipes from arbitrary URLs, save them, plan a week, generate a consolidated shopping list. Three weeks. Proves: you can work with inconsistent third-party HTML and fail gracefully when a site cannot be parsed. Respect robots.txt and rate limits, and say so in the README — that judgement is itself the signal.
11. A log analyser. Ingest log files larger than available memory, parse into structured records, query by time and level, chart error rate. Three weeks. Proves: you stream files rather than reading them into memory. "Peak usage went from 1.2 GB to 40 MB on a 2 GB file" is a sentence that stops a reviewer.
If you want to prove front-end depth
12. An accessible component library. Modal, dropdown, tabs, accordion, tooltip, toast — all fully keyboard operable, with focus trapping in the modal and correct ARIA. Two weekends. Proves: you understand accessibility, which is a legal requirement for many employers and something most junior candidates cannot discuss at all.
13. A real-time collaborative whiteboard. Multiple people drawing on a shared canvas with live cursors and undo. Three to four weeks. Proves: WebSocket lifecycle handling, reconnection, and that you have thought about what happens when two people edit the same object.
If you want to prove systems depth
14. A static site generator. Read Markdown with frontmatter, render through templates, generate an index, tag pages and a sitemap, with a watch mode. Two to three weeks. Proves: you understand what your build tools actually do. Host your own blog on it and the demo becomes self-referential in a satisfying way.
15. An interpreter for a small language. Lexer, parser, tree-walking evaluator with variables, functions and control flow, plus a REPL and error messages with line numbers. Five to six weeks. Proves: fundamentals that transfer everywhere. The quality of your error messages is a good secondary conversation about developer experience.
How to choose one
Not three. One.
Score your options on four things:
| Criterion | Question | Weight |
|---|---|---|
| Role relevance | Does this use the technologies in the job ads I am answering? | Highest |
| Genuine interest | Will I still open this on a wet Tuesday in week three? | High |
| Realistic scope | Can I finish the core in the time I actually have? | High |
| One new thing | Does it stretch me in exactly one direction? | Medium |
If a project scores badly on realistic scope, cut features rather than dropping the project. Scope it in four layers — MVP, core, advanced, stretch — ship the MVP, deploy it, write the README, and only then decide whether to continue. Most people invert this and end up with four things at 60%.
The thing nobody tells you
You may not need a new project at all.
An assignment becomes portfolio evidence when you add what marking schemes ignore: deploy it publicly, write a real README, add one feature nobody asked for, add a handful of tests, and handle the error cases the sample data never triggered. That is typically two evenings, against three weeks for something new — and a reviewer cannot tell the difference, because a deployed, documented, tested project is a deployed, documented, tested project.
Full specifications for thirty of these — with problem, users, features, data model, stack options and stretch goals — are in the portfolio project ideas guide.
Want the complete 14-day system?
Developer Portfolio Builder takes you from “I need a portfolio” to application-ready in 14 days: seven modules, 30 project briefs, every template, and a scorecard to check your work.
See what’s included