Skip to content
Developer Portfolio
Free Toolkit

Projects

Front-end Portfolio Projects

10 specified briefs for front-end roles. Interface work where the difficulty is in state, accessibility and performance rather than in the styling.

Short answer

What do front-end reviewers look for?

Front-end reviewers look for real interaction states, keyboard support and a deployed link they can click.

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.

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.

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.

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.

Intermediate

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

Advanced

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

Want the complete 14-day system?

Developer Portfolio Builder takes you from “I need a portfolio” to application-ready in 14 days: seven modules, 30 project briefs, every template, and a 100-point scorecard to check your work.

See what’s included