What projects look good on a developer portfolio?

Projects that solve a real problem, were finished, are deployed somewhere a reviewer can click, and involved at least one technical decision you can defend. Difficulty matters less than those four things — a well-documented, deployed URL shortener that explains why you chose a 302 over a 301 beats an ambitious half-finished machine-learning project every time.

How many portfolio projects do I need?

Two or three that you can explain in depth. Reviewers look at your first two and form a view; the third gets skimmed and the rest are functionally invisible. Eight projects at 60% completion is the most common shape on a junior portfolio and one of the least effective.

Are to-do apps bad portfolio projects?

Not inherently bad, just uninformative — everyone has one and none of them are hard, so a reviewer learns nothing from seeing another. If you have built one, the useful move is to extend it substantially in a direction the tutorial did not go: real-time sync between devices, offline support with conflict resolution, or a shared multi-user model.

Should portfolio projects be original ideas?

No. Originality of concept is worth very little; the engineering is what gets assessed. A well-built booking system is a stronger portfolio piece than a novel idea that was abandoned at 40%. What matters is that you solved a real problem, made decisions you can defend, and finished.

How long should a portfolio project take?

One that you can finish. For a first portfolio piece, a weekend to two weeks of evenings is a realistic target. Longer projects are worth doing once you have something deployed — the failure mode is starting a six-week project when you have nothing shipped, and abandoning it in week three.

30 Developer Portfolio Project Ideas With Full Specs

Short answer

What makes a project worth putting on a portfolio?

Four things, none of which is difficulty: it solves a real problem, it was finished, it is deployed where a reviewer can click it, and it contains at least one technical decision you can defend. A well-documented URL shortener that explains its caching choice beats an abandoned machine-learning project.

What makes a good portfolio project

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 — the code is the means.

This is why the to-do app problem is not really about to-do apps. It is that:

Everyone has one, so it distinguishes nothing
Nothing in it was hard, so there is no decision to discuss
It solves no real problem, so there is no judgement to demonstrate

A project fixes all three by having a real user, a genuine constraint, and something that went wrong. Every brief below is chosen because it contains at least one of those.

How to choose one

Pick one. Not three. The most common failure on a junior portfolio is four projects at 60% completion, and the fix is choosing a scope you can finish and then finishing it.

Criterion	Ask yourself	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
Demonstrability	Can I show it working in thirty seconds?	Medium

If a project scores badly on realistic scope, cut features rather than dropping the project.

Scoping it properly

Each brief below is split into “build this first” and “once the core works” for exactly this reason. The first list is the MVP. Treat the second as optional.

Beginner projects (10)

Buildable in a weekend or two with first-year fundamentals. The goal is a finished, deployed thing — not complexity.

BeginnerFront-endFull-stackIn the free toolkit

Module Deadline Tracker

Coursework deadlines live across four different university systems, an email thread and a lecturer's slide. Students miss submissions they knew about a fortnight earlier.

1–2 weekends

Who it is for

You and the people on your course. This is the rare beginner project with genuine, findable users sitting next to you.

Build this first

Add a deadline with a module, title, due date and weighting
A list sorted by what is due next, with days remaining
Mark something as submitted and hide it
Colour or label the urgency band (this week, this month, later)
Data survives a page refresh

Once the core works

Import an .ics calendar file from the university timetable
Estimated-effort field, and a weekly view of hours committed
Browser notifications 48 hours before a deadline
Share a read-only link with a study group

Data you will need

One entity — a deadline — with about six fields. Local storage is enough for the first version; move to a real database only if you add sharing.

Stack options

Any front-end framework, or plain HTML/CSS/JS. React, Vue, Svelte or a server-rendered app in Django, Rails or Laravel all work.

What a reviewer can infer

CRUD operations and state management; Date handling, which is harder than it looks; Sorting and filtering a list; Persistence and a sensible empty state.

Why this works as portfolio evidence

It solves a problem you actually have, which means you will finish it and be able to talk about the decisions honestly. Date arithmetic also gives you a real bug to describe in an interview — almost everyone gets the timezone or the off-by-one-day wrong first time.

BeginnerBack-end

Developer Utility CLI

You keep opening a browser tab to convert a timestamp, decode a JWT, format JSON or generate a UUID. Each detour costs a minute and breaks concentration.

1 weekend

Who it is for

Developers, including you. Distribute it and other people on your course will use it too.

Build this first

At least five subcommands (epoch to date, JSON pretty-print, UUID, base64, hash)
Reads from arguments and from piped stdin
A --help that is genuinely readable
Correct exit codes, and errors on stderr rather than stdout
Installable with one command

Once the core works

Publish to npm, PyPI or Homebrew
Shell completions for bash and zsh
A config file for user defaults
Unit tests for every subcommand, running in CI

Data you will need

None. Optionally a small config file in the user's home directory.

Stack options

Node with Commander, Python with Typer or Click, Go with Cobra, or Rust with clap. Go and Rust give you a single distributable binary, which demos well.

What a reviewer can infer

Command-line argument parsing and stdin handling; Unix conventions — exit codes, stdout versus stderr, piping; Packaging and distribution; Writing usable developer documentation.

Why this works as portfolio evidence

Small, finishable, and it proves you understand the tools you use every day rather than only the frameworks. A published package with an install command is disproportionately impressive for the effort involved.

BeginnerFront-endFull-stack

Recipe Cost Calculator

Students cooking on a budget have no idea what a meal actually costs per portion, so food shopping is guesswork and money disappears.

1–2 weekends

Who it is for

Students sharing a kitchen, and anyone meal-planning to a budget.

Build this first

Add ingredients with a pack price and a pack size
Build a recipe from those ingredients with per-recipe quantities
Calculate cost per portion, accounting for partial pack usage
Save recipes and edit them later
Compare the cost per portion of two recipes

Once the core works

A shopping list generated from a week of chosen recipes
Scale a recipe up or down by number of portions
Rough per-portion macros from a nutrition dataset
Share a recipe by URL

Data you will need

Two related entities — ingredients and recipes — with a join carrying quantity. This is a clean first exposure to a many-to-many relationship.

Stack options

Anything with a small database. SQLite plus a light back end is ideal; a client-side app with local storage also works for a first version.

What a reviewer can infer

Modelling a many-to-many relationship; Unit conversion and floating-point rounding done carefully; Form design and input validation; Deriving values rather than storing them.

Why this works as portfolio evidence

The unit maths is a genuine trap — grams against millilitres, partial packs, rounding money — so a correct implementation shows care. It is also a relatable product that a non-technical interviewer immediately understands.

BeginnerFront-end

Markdown Notes App

Note apps are either too heavy or lock your notes in a proprietary format you cannot grep.

1–2 weekends

Who it is for

You, and anyone who prefers plain text they can keep.

Build this first

Write Markdown in one pane, see it rendered in the other
Create, rename and delete notes
Full-text search across all notes
Notes persist between sessions
Export a note, or all notes, as .md files

Once the core works

Keyboard shortcuts and a command palette
Tags with filtering
Syntax highlighting inside code blocks
Sync to a GitHub repository via the API

Data you will need

Notes with title, body, timestamps and optional tags. Local storage or IndexedDB.

Stack options

React, Vue or Svelte with a Markdown parser. Or Electron or Tauri if you want it as a desktop app.

What a reviewer can infer

Controlled inputs and debounced updates; Rendering untrusted Markdown safely; Search and filter over a local dataset; Keyboard accessibility.

Why this works as portfolio evidence

The rendering step forces you to think about sanitisation, which is a security conversation you can have in an interview. It is also a project you will keep using, and used projects get maintained.

BeginnerFront-end

Multi-City Weather Dashboard

Checking the weather for several places — home, university, where family lives — means opening the same site three times.

1 weekend

Who it is for

Anyone splitting their life across two or three locations.

Build this first

Add and remove cities from a saved list
Current conditions plus a multi-day forecast for each
Real loading and error states, not a blank screen
Handles the API being unavailable without breaking
Saved cities persist between visits

Once the core works

Cache responses so you do not refetch on every render
Toggle between metric and imperial units
A temperature chart across the forecast period
Detect location with the Geolocation API, with permission handled properly

Data you will need

A free weather API (Open-Meteo needs no key; OpenWeatherMap has a free tier). Store the saved city list locally.

Stack options

Any front-end framework. A chart library only if you attempt the graph stretch goal.

What a reviewer can infer

Consuming a third-party REST API; Asynchronous state — loading, success, error, empty; Rate limiting and caching awareness; Keeping an API key out of client-side code.

Why this works as portfolio evidence

Weather apps are common, so the differentiator is entirely in the error handling and the caching. Doing those properly, and saying so in the README, turns a tutorial project into evidence. If you build this, the README needs to explain what happens when the API fails.

BeginnerFull-stackMobile

Shared House Expense Splitter

Housemates track shared costs in a group chat and a note on the fridge. By the end of term nobody agrees who owes what.

2 weekends

Who it is for

Shared houses, flatmates, trip groups. Real users are two doors down.

Build this first

Add an expense with a payer, an amount and who it is split between
Uneven splits, not only equal ones
A running balance per person
Settle up, which clears balances and records the settlement
A simple shared view without accounts

Once the core works

Minimise the number of transactions needed to settle everyone
Receipt photo upload
Recurring expenses like rent and bills
Export the ledger as CSV

Data you will need

People, expenses and splits. The balance calculation is derived, never stored — a good discipline to establish early.

Stack options

Any full-stack framework with a small database. Postgres or SQLite.

What a reviewer can infer

Money handled correctly — integer minor units, never floats; Derived state calculated from a ledger; Multi-entity data modelling; Designing for a shared, multi-user flow.

Why this works as portfolio evidence

Money arithmetic is where floating point bites, and handling it in integer cents is a detail interviewers notice. The settle-up minimisation stretch goal is a genuine little algorithm you can talk through on a whiteboard.

BeginnerFront-endFull-stackMobile

Spaced-Repetition Flashcards

Revising by re-reading notes is close to useless, and the good spaced-repetition tools have a steep learning curve for one module's worth of revision.

2 weekends

Who it is for

Students revising anything with facts in it — you, and everyone on your course.

Build this first

Create decks and cards with a front and a back
A review session that shows cards due today
Rate recall, and schedule the next review from that rating
Track how many cards are due and how many were reviewed
Import cards from pasted text or CSV

Once the core works

Implement the SM-2 scheduling algorithm properly
A statistics view of retention over time
Images on cards
Offline support with a service worker

Data you will need

Decks, cards, and a review history per card. The scheduling state is the interesting part of the model.

Stack options

Any front-end framework; add a back end only if you want cross-device sync.

What a reviewer can infer

Implementing a published algorithm from its specification; Date scheduling and interval arithmetic; Session and progress state; Data import and parsing.

Why this works as portfolio evidence

Implementing SM-2 from the original description is exactly the kind of task a junior developer is given: read a spec, translate it into code, verify it behaves. Being able to explain that scheduling algorithm is a strong interview moment.

BeginnerBack-endFull-stackIn the free toolkit

URL Shortener with Analytics

You want short links you control, with click statistics, without handing your traffic data to a third party.

1–2 weekends

Who it is for

Anyone sharing links — for a society, a newsletter, a CV.

Build this first

Submit a long URL and receive a short code
Redirect from the short code to the original, with the correct HTTP status
Count clicks per link
Custom aliases, with collision handling
A stats page per link

Once the core works

Rate limiting on link creation
Link expiry dates
Referrer and rough geographic breakdown of clicks
A QR code for each short link

Data you will need

Links and click events. The click table grows fast, which makes it a natural first conversation about indexing.

Stack options

Any back-end framework with a database. Express, FastAPI, Go net/http, Spring Boot, Rails — all fine.

What a reviewer can infer

HTTP fundamentals — 301 versus 302, and why it matters here; Generating and validating short unique identifiers; Database indexing on a lookup-heavy table; Input validation against malicious URLs.

Why this works as portfolio evidence

It is small but genuinely back-end: routing, persistence, redirects and a real correctness question about caching. Choosing 302 over 301 so your click counts keep working — and being able to say why — is precisely the kind of detail that separates candidates.

BeginnerFront-end

Accessible Component Library

Most tutorial components — modals, dropdowns, tabs — are keyboard traps and invisible to screen readers. Teams pay for that later.

2 weekends

Who it is for

You, on every future project, and anyone who installs it.

Build this first

Six components built properly: modal, dropdown, tabs, accordion, tooltip, toast
Full keyboard operation, including focus trapping in the modal
Correct ARIA roles and relationships, used only where needed
A documentation page demonstrating each component
Visible focus states throughout

Once the core works

Publish it to npm
Automated accessibility tests with axe-core
Dark mode via CSS custom properties
Storybook or a hand-built component playground

Data you will need

None. This is a pure interface project.

Stack options

React, Vue, Svelte or Web Components. TypeScript strongly recommended.

What a reviewer can infer

WAI-ARIA authoring practices applied correctly; Focus management and keyboard interaction; API design for reusable components; Writing documentation for other developers.

Why this works as portfolio evidence

Accessibility is a legal requirement for a lot of employers and most junior candidates cannot discuss it at all. A component library where the modal traps focus correctly and the dropdown handles arrow keys is a small project with a large signal.

BeginnerBack-end

Personal Data API

Your projects, reading list, and now-playing status live across five services. There is no single place to read them from.

1–2 weekends

Who it is for

Your own portfolio site, which consumes the API you built.

Build this first

REST endpoints for at least three resources (projects, books, posts)
JSON responses with a consistent shape
OpenAPI documentation, generated or hand-written
CORS configured correctly for your portfolio origin
Deployed, with a public base URL

Once the core works

Aggregate a live source — GitHub, Spotify or Last.fm — with caching
Simple API-key auth on the write endpoints
Pagination and filtering
Response caching with proper Cache-Control headers

Data you will need

Three or four small entities. SQLite is plenty.

Stack options

FastAPI, Express, Go, Spring Boot or Rails. FastAPI generates OpenAPI docs for free, which is a nice head start.

What a reviewer can infer

REST design — resources, status codes, consistent error shapes; API documentation; CORS, which almost everyone gets wrong the first time; Deployment and environment configuration.

Why this works as portfolio evidence

It gives you a live API to point at, and it makes your portfolio site a real client of your own back end. That connection — front end consuming an API you designed and deployed — is exactly the shape of a junior full-stack role.

Intermediate projects (11)

Two to four weeks of evenings. These involve a real data model, a third party you do not control, and decisions with tradeoffs.

IntermediateFull-stackIn the free toolkit

Society Events Platform

University societies run sign-ups through a mix of Google Forms, Instagram stories and a spreadsheet. Committees lose track of who is coming and members miss events entirely.

3–4 weeks of evenings

Who it is for

A real society at your university. Ask one — most committees will happily be your first users, which gives you the rarest thing on a junior portfolio: actual usage.

Build this first

Committee accounts that can create and edit events
A public event listing with dates, locations and descriptions
Member sign-up with a capacity limit and a waiting list
Email confirmation on sign-up
An attendee list the committee can export

Once the core works

QR check-in on the door
Recurring events
A calendar feed members can subscribe to (.ics)
Attendance statistics across a term

Data you will need

Users with roles, events, and registrations with a status. The waiting-list promotion when someone cancels is the interesting piece of logic.

Stack options

Next.js, Django, Rails, Laravel or Spring Boot with Postgres. Any transactional email service for confirmations.

What a reviewer can infer

Authentication and role-based authorisation; Race conditions on a limited resource — two people taking the last place; Transactional email integration; Designing for two distinct user types.

Why this works as portfolio evidence

It has real users, real permissions and a real concurrency problem. The capacity race condition is the single best interview story on this list: describe how two simultaneous sign-ups can both see one place remaining, and how you fixed it with a transaction or a database constraint.

IntermediateFull-stack

Job Application Tracker

Applying for placements means 40 applications across 12 portals, each with its own status, deadline and follow-up. A spreadsheet stops coping around application 20.

2–3 weeks of evenings

Who it is for

You, immediately, and every other student on your course applying this year.

Build this first

Add applications with company, role, link, date applied and status
A pipeline view grouped by stage
Reminders for follow-ups and upcoming interviews
Notes and contacts per application
Search and filter across everything

Once the core works

Parse a job posting URL to prefill company and role
Statistics — response rate, time to first reply, stage conversion
Browser extension to save a posting in one click
Store the CV version sent with each application

Data you will need

Applications, stages, contacts and notes. A status history table is worth adding so you can chart progression over time.

Stack options

Any full-stack framework with Postgres. Background jobs for the reminders.

What a reviewer can infer

State machines — an application moves through defined stages; Scheduled and background work; Filtering and search across related tables; Building something you use daily, which shows in the polish.

Why this works as portfolio evidence

You will use it while job hunting, which means it gets finished and refined. It also gives an interviewer an easy, genuine question — and "I built this because I was losing track of my own applications" is a good answer.

IntermediateFull-stackFront-end

Real-Time Collaborative Whiteboard

Group project planning over a video call means one person shares a screen and everyone else describes where to draw the box.

3–4 weeks of evenings

Who it is for

Student project groups and study sessions.

Build this first

Draw shapes, lines and text on a shared canvas
Multiple people editing the same board simultaneously
Live cursors showing where others are
Boards persist and can be reopened by URL
Undo and redo

Once the core works

Conflict resolution when two people edit the same object
Export the board as PNG or SVG
Presence list showing who is currently connected
Offline edits that reconcile on reconnect

Data you will need

Boards and drawing operations. Storing an operation log rather than canvas snapshots is what makes undo and reconciliation tractable.

Stack options

WebSockets via Socket.IO, native ws, Phoenix Channels or SignalR. Canvas or SVG on the front end. Redis if you need to share state across server instances.

What a reviewer can infer

WebSocket connection lifecycle, including reconnection; Real-time state synchronisation between clients; Canvas rendering and hit detection; Event-sourced data modelling.

Why this works as portfolio evidence

Real-time is where a lot of candidates stop, so getting it working is a genuine differentiator. Even a partial answer to "what happens when two people drag the same shape?" shows you have thought about distributed state.

IntermediateBack-endFull-stackData

Recipe Scraper and Meal Planner

Recipes are scattered across sites wrapped in adverts and life stories. Planning a week of meals means twelve tabs and manual copying.

3 weeks of evenings

Who it is for

Anyone who meal plans, which turns out to be most people once they have a kitchen.

Build this first

Paste a recipe URL and extract title, ingredients and method
Save recipes to a personal collection
Assign recipes to days on a weekly plan
Generate a consolidated shopping list, combining duplicate ingredients
Handle sites that cannot be parsed, gracefully

Once the core works

Parse structured recipe metadata where sites publish it
Normalise ingredient quantities across different units
Scale recipes by servings
Suggest recipes that reuse ingredients already on the list

Data you will need

Recipes, ingredients, plans and plan entries. Ingredient normalisation — matching "2 medium onions" to "onion" — is the genuinely hard part.

Stack options

Python with BeautifulSoup or Go with goquery for the parsing; any framework for the app. A queue for scraping jobs.

What a reviewer can infer

HTML parsing and dealing with inconsistent third-party data; Text normalisation and fuzzy matching; Background job processing; Failing gracefully on input you do not control.

Why this works as portfolio evidence

Working with data you do not control is most of real engineering, and this project is full of it. Be careful to respect robots.txt and rate limits — and say in your README that you did, because that judgement is itself a signal.

IntermediateMobile

Workout Tracker (Mobile)

Tracking gym sessions in a notes app means no history, no progression and no way to see whether anything is improving.

3–4 weeks of evenings

Who it is for

Anyone lifting regularly and trying to progress.

Build this first

Define workout templates with exercises, sets and reps
Log a session against a template, entering weights as you go
History per exercise, with a progression chart
Works fully offline
Rest timer between sets

Once the core works

Sync across devices when a connection is available
Personal-record detection and notifications
Import and export data as CSV or JSON
Apple Health or Google Fit integration

Data you will need

Exercises, templates, sessions and set entries. Local-first storage with an optional sync layer.

Stack options

React Native or Expo, Flutter, Swift or Kotlin. SQLite locally, whatever you prefer for the optional sync back end.

What a reviewer can infer

Offline-first data with a local database; Mobile navigation and platform interface conventions; Charting time-series data; Designing for one-handed use in a noisy environment.

Why this works as portfolio evidence

Offline-first is a real architectural constraint and it forces genuine decisions about conflict resolution. Mobile portfolios are also less crowded than web ones, so a finished, installable app stands out.

IntermediateBack-end

API Gateway with Rate Limiting

A small API needs authentication, rate limiting and request logging, and bolting those into every endpoint by hand does not scale.

3 weeks of evenings

Who it is for

Your own services — and it is a component every back-end team maintains a version of.

Build this first

Proxy requests to one or more upstream services
API-key authentication
Per-key rate limiting with a documented algorithm
Request and response logging with latency
Correct 429 responses with Retry-After headers

Once the core works

Token-bucket and sliding-window algorithms, switchable
Distributed rate limiting backed by Redis
Circuit breaking when an upstream is failing
A metrics endpoint in Prometheus format

Data you will need

API keys and their limits; counters in Redis or in memory. The counter expiry strategy is the design decision worth writing up.

Stack options

Go, Node or Rust for throughput. Redis for shared state. Docker Compose to run the whole thing locally.

What a reviewer can infer

HTTP proxying and middleware architecture; Rate-limiting algorithms and their tradeoffs; Distributed state and atomic counter operations; Observability — structured logging and metrics.

Why this works as portfolio evidence

This is infrastructure, and it reads as such. Being able to explain the difference between a fixed window and a sliding window, and why the fixed window lets through a burst at the boundary, puts you ahead of most junior candidates in a back-end interview.

IntermediateFull-stack

Cinema Seat Booking System

Booking a seat is a deceptively hard problem: two people must never end up with the same seat, and a seat held in someone's basket must not be locked forever.

3 weeks of evenings

Who it is for

A classic domain, chosen because the constraints are real rather than because cinemas need another system.

Build this first

Browse films and showings
An interactive seat map with availability
Hold seats for a limited window while checking out
Confirm a booking and produce a reference
Release held seats automatically when the hold expires

Once the core works

Seat pricing tiers
Admin interface for scheduling showings
Booking confirmation email with a QR code
Load test it and write up what broke

Data you will need

Films, showings, seats, holds and bookings. The hold expiry and the uniqueness constraint on a booked seat are the core of the project.

Stack options

Any framework with a transactional database. Postgres is a good fit because you can lean on real constraints.

What a reviewer can infer

Database transactions and isolation levels; Optimistic versus pessimistic locking; Time-limited state and expiry jobs; Enforcing invariants in the database rather than only in code.

Why this works as portfolio evidence

It is the cleanest way to demonstrate that you understand concurrency in a database. Write up the double-booking scenario and how you prevented it, and you have an answer to one of the most common back-end interview questions.

IntermediateBack-endFront-end

Static Site Generator

You want to understand what tools like Hugo, Eleventy and Astro actually do, rather than treating them as magic.

2–3 weeks of evenings

Who it is for

You — and then use it to build your own blog, which closes the loop nicely.

Build this first

Read Markdown files with frontmatter from a content directory
Render them through templates into static HTML
Generate an index page and per-tag pages
Copy static assets and produce a sitemap
A watch mode with a local dev server

Once the core works

Incremental builds that only regenerate changed pages
RSS feed generation
Syntax highlighting at build time
Image optimisation during the build

Data you will need

The filesystem is the database. Content in, HTML out.

Stack options

Go, Rust, Python or Node. A compiled language makes the performance story more interesting.

What a reviewer can infer

File I/O and directory traversal; Templating and content pipelines; Build-tool architecture and caching; Filesystem watching and dev-server tooling.

Why this works as portfolio evidence

Building the tool rather than using it demonstrates depth. If you then host your own blog on it, you have a live artefact and a self-referential demo that is genuinely fun to present.

IntermediateFront-end

Study Focus Browser Extension

Site blockers are all-or-nothing and easy to disable in the moment you most need them not to be.

2–3 weeks of evenings

Who it is for

Students revising, which is a large and honest user base.

Build this first

Block a configurable list of sites during a focus session
Pomodoro-style timer with breaks
Statistics on focus time per day
Settings that sync across the user's browser profile
A friendly block page rather than a connection error

Once the core works

Allow a site for five minutes with a deliberate friction step
Weekly report of time saved
Publish to the Chrome Web Store or Firefox Add-ons
Schedule focus sessions in advance

Data you will need

Settings and session history in the browser's extension storage.

Stack options

Manifest V3, vanilla JS or a small framework. WebExtensions APIs work in both Chrome and Firefox.

What a reviewer can infer

Browser extension architecture — background workers, content scripts, permissions; Working within a restrictive security model; Store review and publication process; Persisting and syncing user settings.

Why this works as portfolio evidence

Extensions are an unusual portfolio piece, and a published one with install instructions is immediately credible. The permissions model also forces you to think about least privilege, which is a good conversation to be able to have.

IntermediateBack-endData

Log Analyser and Dashboard

Server logs contain the answer to why something broke, but grep across a gigabyte of unstructured text is a slow way to find it.

3 weeks of evenings

Who it is for

Anyone running a service — including you, on your own deployed projects.

Build this first

Ingest log files in at least two formats
Parse into structured records with timestamp, level and message
Query by time range, level and text
A dashboard with request volume and error rate over time
Handle files larger than available memory

Once the core works

Live tailing of a growing file
Anomaly detection on error rate
Alerting when a threshold is crossed
Compressed storage of older records

Data you will need

Parsed log entries. Time-series indexing matters as soon as you have real volume, which makes the index design a real decision.

Stack options

Go or Python for ingestion; Postgres, ClickHouse or SQLite for storage; any charting library for the dashboard.

What a reviewer can infer

Streaming large files without loading them into memory; Regular expressions and parser design; Time-series querying and aggregation; Data visualisation with a purpose.

Why this works as portfolio evidence

The memory constraint forces streaming, which is a real skill and a good story. Point it at logs from another of your own deployed projects and the demo becomes concrete rather than synthetic.

IntermediateFull-stackGame development

Real-Time Multiplayer Quiz

Running a quiz for a society or a class means one person reading questions aloud and manually keeping score.

3 weeks of evenings

Who it is for

Societies, classes, pub teams. Easy to get in front of real people, which is the point.

Build this first

Host creates a room and gets a join code
Players join on their phones without installing anything
Questions appear simultaneously with a countdown
Scoring that rewards speed as well as correctness
Live leaderboard between rounds

Once the core works

Reconnect handling when a player drops off wifi
Question packs that hosts can import
Team mode
Spectator view for a projector

Data you will need

Rooms, players, questions and answers. Most state is in memory during a game; only results need persisting.

Stack options

WebSockets on any stack. Redis if you want rooms to survive a server restart.

What a reviewer can infer

Real-time synchronisation and server-authoritative timing; Managing ephemeral game state; Reconnection and failure handling; Mobile-first interface under time pressure.

Why this works as portfolio evidence

Timing is the interesting problem: you cannot trust the client's clock, so the server has to be authoritative. That is a real distributed-systems idea in a project you can demo live in an interview.

Advanced projects (9)

A month or more. Concurrency, scale, infrastructure or genuine algorithmic work — the projects that carry a whole portfolio.

AdvancedBack-endIn the free toolkit

Distributed Task Queue

Slow work — sending email, processing images, generating reports — blocks web requests. Every serious back end eventually needs somewhere to put that work.

4–6 weeks of evenings

Who it is for

Your own services. Build it, then use it in another of your projects so the demo is a system rather than a library.

Build this first

Enqueue jobs with a payload and a priority
Worker processes that claim and execute jobs
Retries with exponential backoff
A dead-letter queue for jobs that exhaust their retries
At-least-once delivery, with the guarantee documented

Once the core works

Scheduled and recurring jobs
A web dashboard showing queue depth and failures
Graceful worker shutdown that finishes in-flight jobs
Horizontal scaling across multiple worker machines

Data you will need

Jobs with state, attempt count and timestamps. Redis or Postgres both work — Postgres with SELECT ... FOR UPDATE SKIP LOCKED is an elegant approach worth writing up.

Stack options

Go, Rust, Python or Node. Redis or Postgres for storage. Docker Compose for the local cluster.

What a reviewer can infer

Concurrency and worker coordination; Delivery guarantees and idempotency; Failure handling, retries and backoff; Distributed-systems vocabulary used accurately.

Why this works as portfolio evidence

It is the single most interview-relevant project on this list for a back-end role. "What happens if a worker dies halfway through a job?" is a question you will be asked, and having built the answer is far better than having read it.

AdvancedBack-endData

Code Search Engine

Searching a large codebase with grep is slow and imprecise. Understanding how real code search works means building an index.

6 weeks of evenings

Who it is for

Developers searching their own repositories.

Build this first

Index a repository's files into a searchable structure
Substring and regular-expression search across the index
Results ranked with file and line context
Incremental reindexing when files change
Search across multiple repositories

Once the core works

Trigram indexing for fast regex prefiltering
Language-aware search — definitions versus references
A web interface with syntax highlighting
Benchmarks against grep, written up honestly

Data you will need

An inverted or trigram index. Memory and disk layout are the whole engineering problem here.

Stack options

Go or Rust for performance. A tree-sitter binding if you attempt language awareness.

What a reviewer can infer

Index data structures and their tradeoffs; Algorithmic thinking applied to a real problem; Performance measurement and optimisation; Memory-conscious programming.

Why this works as portfolio evidence

It is genuine computer science applied to a tool developers use daily. A benchmark table showing your index beating grep on a large repository is a portfolio artefact very few juniors have.

AdvancedBack-end

Minimal Container Runtime

Containers are treated as magic by most developers. They are namespaces, cgroups and a filesystem, and building a minimal one removes the mystery.

5–6 weeks of evenings

Who it is for

You, for understanding. This is a learning project presented honestly as one.

Build this first

Run a process in isolated PID, mount, network and UTS namespaces
Apply cgroup limits for memory and CPU
Use a root filesystem from an extracted image
Basic run command with argument passing
Documentation explaining each isolation mechanism

Once the core works

Pull images from a registry
Container networking with a bridge
Layered filesystem with overlayfs
A comparison write-up against runc

Data you will need

None. This is systems programming against the kernel API.

Stack options

Go or Rust on Linux. A virtual machine if you are developing on macOS or Windows.

What a reviewer can infer

Linux kernel primitives — namespaces, cgroups, chroot; Systems programming and syscall usage; Deep understanding of infrastructure most developers only consume; Technical writing about complex material.

Why this works as portfolio evidence

Nothing signals systems depth faster. Be explicit in the README that it is a teaching implementation and not production software — that framing is honest and it is exactly how a strong engineer would present it.

AdvancedBack-end

Interpreter for a Small Language

Every developer uses languages daily and most have never seen how one is executed. Building an interpreter closes that gap permanently.

5–6 weeks of evenings

Who it is for

You, plus anyone who wants to read a small, comprehensible interpreter.

Build this first

Lexer producing a token stream
Parser producing an abstract syntax tree
Tree-walking evaluator with variables, functions and control flow
A REPL
Useful error messages with line and column numbers

Once the core works

Closures and first-class functions
A bytecode compiler and virtual machine
Garbage collection
A test suite of language programs

Data you will need

None. The AST is the data structure.

Stack options

Any language you are comfortable in. Go, Rust, Python and TypeScript all work; the exercise is the same.

What a reviewer can infer

Parsing, grammars and recursive descent; Tree data structures and traversal; Language semantics — scope, environments, evaluation order; Working from a specification to a working system.

Why this works as portfolio evidence

It is a classic for good reason: it demonstrates fundamentals that transfer everywhere, and the error-message quality gives you something concrete to talk about in terms of user experience for developers.

AdvancedFull-stackBack-end

Production-Shaped E-Commerce Backend

Most tutorial shops skip everything that makes commerce hard: inventory that must not oversell, payments that must not double-charge, and orders that must survive a crash.

6 weeks of evenings

Who it is for

A small real seller if you can find one — a society selling merchandise is a good candidate.

Build this first

Product catalogue with variants and stock levels
Cart and checkout with stock reservation
Payment integration in test mode with webhook handling
Idempotent order creation that survives a duplicate webhook
Order history and status transitions

Once the core works

Refunds and partial refunds
An admin dashboard for fulfilment
Email notifications at each order stage
Full audit log of state changes

Data you will need

Products, variants, inventory, carts, orders, payments and events. The idempotency key on payment webhooks is the detail that makes this credible.

Stack options

Any serious back-end framework with Postgres. Stripe test mode for payments — never handle raw card details yourself.

What a reviewer can infer

Transactional integrity across multiple entities; Idempotency and webhook handling; Third-party payment integration done safely; Modelling state machines for orders.

Why this works as portfolio evidence

The webhook idempotency problem — the payment provider retries and you must not create two orders — is a genuinely professional concern. Solving it and writing it up puts you ahead of candidates who have only built a cart.

AdvancedDataBack-end

Recommendation Service

Recommendation is treated as a black box. Building one end to end — data, model, serving, evaluation — shows where the real engineering is.

5 weeks of evenings

Who it is for

Attach it to one of your own projects that has items and users, so it recommends something real.

Build this first

Ingest and clean a public dataset
A baseline recommender — popularity or item-to-item similarity
An API endpoint serving recommendations under a latency budget
Offline evaluation with a stated metric and a holdout split
Honest documentation of what the model cannot do

Once the core works

Collaborative filtering with matrix factorisation
Cold-start handling for new users and new items
A/B test harness comparing two strategies
Feature store and scheduled retraining

Data you will need

A public dataset — MovieLens is the standard. Serving requires precomputed similarities or embeddings.

Stack options

Python with pandas and scikit-learn or implicit; FastAPI for serving; Postgres or a vector store.

What a reviewer can infer

The full machine-learning lifecycle, not just model fitting; Evaluation methodology and avoiding leakage; Serving models under latency constraints; Being honest about model limitations.

Why this works as portfolio evidence

Most student ML projects stop at a notebook with an accuracy number. Deploying a model behind an API with a latency budget and a stated evaluation method is the part employers actually need and rarely see.

AdvancedGame developmentBack-end

Authoritative Multiplayer Game Server

Naive multiplayer games trust the client, so they desynchronise and can be cheated. Doing it properly means the server owns the truth.

6+ weeks of evenings

Who it is for

Players of a small real-time game — top-down shooter, racing, or similar.

Build this first

Server-authoritative game state on a fixed tick
Client prediction with server reconciliation
Interpolation of other players' positions
Lag compensation for hit detection
Room-based matchmaking

Once the core works

Delta compression of state updates
Anti-cheat validation of client inputs
Spectator mode
Replay recording and playback

Data you will need

In-memory game state per room. Persist only match results and player statistics.

Stack options

Go, Rust or C# for the server; any engine or a browser client. UDP or WebRTC data channels where latency matters.

What a reviewer can infer

Network programming and protocol design; Client prediction and reconciliation; Real-time performance under a tick budget; Security thinking — never trust the client.

Why this works as portfolio evidence

Client prediction and lag compensation are genuinely difficult and well documented, so you can work from published techniques and still produce something hard. A playable demo in an interview is memorable in a way a screenshot is not.

AdvancedBack-endData

Self-Hosted Observability Stack

When a deployed project breaks, most students find out because someone tells them. Without metrics, logs and traces you are guessing.

4–5 weeks of evenings

Who it is for

Your own deployed projects, instrumented for real.

Build this first

Instrument at least two of your services with metrics and traces
Collect them with an OpenTelemetry collector
Store and query metrics, and visualise them on a dashboard
Distributed tracing across a service boundary
Alert on an error-rate threshold

Once the core works

Service-level objectives with an error budget
Log correlation by trace ID
Runbook documentation for each alert
Deliberately break something and write up the incident

Data you will need

Time-series metrics, traces and logs from your own running services.

Stack options

OpenTelemetry, Prometheus, Grafana, Tempo or Jaeger. Docker Compose or a small Kubernetes cluster.

What a reviewer can infer

Instrumentation and observability practice; Distributed tracing across services; Infrastructure operation and configuration; Incident analysis and write-up.

Why this works as portfolio evidence

It is operations rather than feature work, which almost no junior portfolio shows. A written incident post-mortem from your own deliberately-broken service is a genuinely unusual and impressive artefact.

AdvancedFull-stackFront-end

Collaborative Text Editor with CRDTs

Two people editing the same document at the same time will produce conflicting states unless the data structure itself is designed to converge.

6+ weeks of evenings

Who it is for

Anyone co-writing — group reports, shared notes, documentation.

Build this first

Rich text editing in the browser
Concurrent editing by multiple users that converges to the same result
Offline editing that reconciles on reconnect
Cursor and selection presence for other users
Document persistence and reload

Once the core works

Implement a CRDT yourself rather than using a library
Version history with the ability to restore
Comments anchored to text ranges
Performance testing with a large document

Data you will need

The document as a CRDT structure plus an operation log. Compaction matters once documents get long.

Stack options

Yjs or Automerge to start, then consider a hand-rolled implementation. WebSockets for transport, any editor surface.

What a reviewer can infer

Conflict-free replicated data types and eventual consistency; Complex client-side state management; Offline-first architecture; Reading and applying academic literature.

Why this works as portfolio evidence

CRDTs are current, genuinely hard, and well documented. Even using a library and explaining precisely why the convergence property holds demonstrates a level of reading and reasoning that stands out immediately.

Browse by track

If you have already chosen a direction, the briefs are also grouped by the kind of role they support.

Front-end portfolio projects — Interface work where the difficulty is in state, accessibility and performance rather than in the styling.
Back-end portfolio projects — APIs, data modelling, concurrency and the infrastructure that keeps a service standing up.
Full-stack portfolio projects — End-to-end products with authentication, a database and a deployed front end talking to your own API.
Mobile portfolio projects — Native and cross-platform apps, where offline behaviour and platform conventions do most of the judging.
Game development portfolio projects — Real-time systems where the tick budget, the network model and the feel of the thing are the engineering.

Or upgrade something you have already built

You may not need a new project at all. An assignment becomes portfolio evidence when you add the things 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. The full upgrade is here.

Of the 30 briefs above, 4 are included in the free toolkit as standalone Markdown files you can keep alongside your project.

30 Developer Portfolio Project Ideas

What makes a good portfolio project

How to choose one

Scoping it properly

Beginner projects (10)

Module Deadline Tracker

Developer Utility CLI

Recipe Cost Calculator

Markdown Notes App

Multi-City Weather Dashboard

Shared House Expense Splitter

Spaced-Repetition Flashcards

URL Shortener with Analytics

Accessible Component Library

Personal Data API

Intermediate projects (11)

Society Events Platform

Job Application Tracker

Real-Time Collaborative Whiteboard

Recipe Scraper and Meal Planner

Workout Tracker (Mobile)

API Gateway with Rate Limiting

Cinema Seat Booking System

Static Site Generator

Study Focus Browser Extension

Log Analyser and Dashboard

Real-Time Multiplayer Quiz

Advanced projects (9)

Distributed Task Queue

Code Search Engine

Minimal Container Runtime

Interpreter for a Small Language

Production-Shaped E-Commerce Backend

Recommendation Service

Authoritative Multiplayer Game Server

Self-Hosted Observability Stack

Collaborative Text Editor with CRDTs

Browse by track

Or upgrade something you have already built

Common questions

What projects look good on a developer portfolio?

How many portfolio projects do I need?

Are to-do apps bad portfolio projects?

Should portfolio projects be original ideas?

How long should a portfolio project take?

Want the complete 14-day system?