Back-end Portfolio Projects

Short answer

What do back-end reviewers look for?

Back-end reviewers look for a data model that makes sense, correct HTTP semantics, and evidence you have thought about failure.

Every brief below includes the problem it solves, who would use it, the features to build first, the stretch goals to leave until the core works, the data model, stack options and an honest time estimate — plus what a reviewer can infer from a finished build.

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

Beginner

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.

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.

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

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.

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.

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.

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.

Advanced

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.

Other tracks

Front-end portfolio projects — Interface work where the difficulty is in state, accessibility and performance rather than in the styling.
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.
All 30 briefs — the complete library, grouped by difficulty.

Beginner

Developer Utility CLI

URL Shortener with Analytics

Personal Data API

Intermediate

Recipe Scraper and Meal Planner

API Gateway with Rate Limiting

Static Site Generator

Log Analyser and Dashboard

Advanced

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

Other tracks

Want the complete 14-day system?