Full-stack Portfolio Projects

Short answer

What do full-stack reviewers look for?

Full-stack reviewers want one project you took all the way to production, not two halves that never met.

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

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.

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.

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.

Intermediate

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.

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.

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

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.

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.

Other tracks

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.
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

Module Deadline Tracker

Recipe Cost Calculator

Shared House Expense Splitter

Spaced-Repetition Flashcards

URL Shortener with Analytics

Intermediate

Society Events Platform

Job Application Tracker

Real-Time Collaborative Whiteboard

Recipe Scraper and Meal Planner

Cinema Seat Booking System

Real-Time Multiplayer Quiz

Advanced

Production-Shaped E-Commerce Backend

Collaborative Text Editor with CRDTs

Other tracks

Want the complete 14-day system?