Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersPortfolio project ideas: 12 builds that show real engineering
A good portfolio project is small enough to finish, public enough to open in a minute and specific enough to talk about for ten. Pick something with a real user, a live link, tests and a README that names one hard decision you made. Below are 12 ideas grouped by what they prove: that you ship to real users, that you can go deep on one problem, or that you work well inside other people's code. Each lists the stack, what it teaches, a first version, a stretch goal and a time estimate.
What makes a portfolio project worth showing?
Assume a reviewer gives your project one minute. They open the README, look for a live link, scan the commit history and maybe open one file. A portfolio project earns attention when each of those steps rewards them. A to-do app built from a tutorial rewards none of them, because many other applicants have the same one.
| Signal | Weak version | Strong version |
|---|---|---|
| README | Install steps only | What it does, who it is for, one screenshot, one hard decision and why you made it |
| Live link | None, or a dead host | A deployed URL that works without signing up |
| Tests | No tests | A test suite that runs in CI, with a badge that is green |
| Commits | One commit called "final" | Small commits with messages that explain why |
| Scope | Ten half-working features | One feature that works, with a list of what you left out |
| Users | Only you | At least one other person who used it and told you what broke |
The 12 projects below are grouped by the claim they let you make. Pick one from each group over a year and you have an honest story: you ship, you go deep and you collaborate. Every entry gives a stack, what you learn, a first version you can finish, a stretch goal for later and a rough time estimate for evenings and weekends. The estimates assume you have built at least one small app before.
# Project name One sentence: what it does and for whom. Live demo: (your URL). Screenshot: docs/screenshot.png ## Why it exists The real problem, in two sentences. Who used it besides me. ## The hard decision One choice I had to make (for example: store times in UTC, or check permissions in the database instead of the app), the options I weighed, and why I picked this one. ## What I left out on purpose - Feature A, because ... - Feature B, because ... ## Run it Exact commands, copy-pasteable, tested on a clean machine. ## Tests How to run them, and what they cover and do not cover.
If you are not sure what to build, use real problems rather than invented ones. The board of ideas is a public list of problems people posted and will not build themselves, and each has a ready build prompt. For a wider menu of beginner to advanced builds, see coding project ideas.
Which portfolio projects show you can ship to real users?
Shipping means someone other than you depends on the thing. These four prove that, and each produces evidence you can link: a number, a store listing, a status page, a write-up.
01 A tool for one real local client
A small web app that replaces one repeated chore at a club, shop, studio or clinic you can actually talk to.
- Stack
- Your usual web stack, a managed Postgres or SQLite database, email sending.
- Teaches
- Requirements from a non-technical person, deployment, support, saying no.
- Time estimate
- 25 to 40 hours over about a month, much of it waiting for feedback.
First version: sit with the person and write down one chore they repeat each week: a booking sheet, a rota, a member list. Build only that, in a single role, and have them use it for two weeks. Measure the before and after in minutes, and keep their words about what annoyed them.
Stretch: add a second role, a CSV export and a backup they can trigger, then write a one-page case study with the numbers. A named user and a measured saving is the strongest line a portfolio can carry.
02 A browser extension in the Chrome Web Store
An extension that fixes one annoyance on one site, published through the store's review process.
- Stack
- TypeScript, Manifest V3, a content script, a bundler.
- Teaches
- Least-privilege permissions, store review, shipping updates to installed users.
- Time estimate
- 15 to 25 hours, plus review time.
First version: one content script that changes one thing on one site, with the narrowest host permission that works. Follow Chrome's extension development docs and publishing steps, then submit it from the Developer Dashboard.
Stretch: an options page, a changelog shown after updates and an automated test that loads the built extension. For ideas worth building, see Chrome extension ideas and how to build a Chrome extension.
03 A public status page for services you depend on
A poller that checks five URLs every minute, stores the results and shows the last 24 hours and 90 days.
- Stack
- Node or Python, Postgres or SQLite, a scheduler, a static front end.
- Teaches
- Scheduled jobs, time-series tables, idempotent writes, uptime arithmetic.
- Time estimate
- 15 to 25 hours.
First version: every minute, request each URL, record the status code and response time, and draw a bar per hour that is green, amber or red. Point it at your own projects so it has a real job.
Stretch: declare an incident after three failures in a row, publish an RSS feed, and make the uptime percentage honest about the minutes your own poller was down. That last detail is the kind of thing an interviewer asks about.
04 A board idea, built and written up
Take one small problem from the public board, build only what its build prompt asks for, and keep a decision log.
- Stack
- Your choice. Small, single-purpose ideas work best.
- Teaches
- Scoping a vague problem, cutting features, explaining trade-offs.
- Time estimate
- 12 to 20 hours.
First version: pick a small idea from the board, such as the meeting cost ticker posted there. Copy its build prompt, add a "Do not build" list, build the narrow version and keep a DECISIONS.md with one line per choice and the reason.
Stretch: publish a short write-up of what you cut and why, and tell the person who posted it. A build with a decision log shows judgment, which a feature list does not.
Read “A board idea, built and written up” on the board and copy its build prompt →
Which portfolio projects show depth in one area?
Depth projects answer the question "what do you know better than most people in your cohort?" They are narrow on purpose. Each one ends in a measurement or a test result, not a screenshot.
01 A grep clone with honest benchmarks
A command-line search tool compared against GNU grep on the same files, with timings in the README.
- Stack
- Rust, Go or C, plus hyperfine for timing.
- Teaches
- Buffered file input, directory walking, regular expressions, profiling, benchmark method.
- Time estimate
- 20 to 30 hours.
First version: search files recursively for a literal string and print file, line number and line. Write tests that compare your output with the real grep on a fixed directory, including binary files and very long lines.
Stretch: add regex support through a library, walk directories in parallel, and publish a timing table made with hyperfine, listing the machine, the corpus and the exact commands so anyone can reproduce it.
02 A support inbox with roles and an audit trail
A ticket system where customers, agents and admins see different things and every status change is logged.
- Stack
- Postgres, any backend, optionally Postgres row security policies.
- Teaches
- Authorization versus authentication, audit logs, migrations, permission tests.
- Time estimate
- 30 to 45 hours.
First version: three roles, tickets, replies, and an audit table that records who changed what and when. Write tests that prove an agent from one team cannot read another team's ticket, and that no code path updates a ticket without writing an audit row.
Stretch: move the access rules into the database with row security policies, then show in the README which rules live where and why.
03 A load-tested service with a written postmortem
A small API pushed until it breaks, fixed at the real bottleneck and documented like an incident.
- Stack
- Go, Node or Python service, Postgres, k6 for load, OpenTelemetry or plain metrics.
- Teaches
- Measuring before optimizing, connection pooling, indexes, caching, percentile latency.
- Time estimate
- 25 to 35 hours.
First version: a URL-lookup API and a k6 script that ramps up request rate until the 95th-percentile latency passes 500 milliseconds. Record the rate at which that happens.
Stretch: find the bottleneck with traces or query plans, fix only that, rerun the same script and write a blameless postmortem in the style described in the Google SRE book: timeline, cause, fix, what you would monitor next.
04 An accessible combobox and date picker as web components
Two form controls that work by keyboard and screen reader, with tests that prove it.
- Stack
- TypeScript, Web Components, Playwright, axe-core.
- Teaches
- Keyboard behavior, ARIA roles, focus management, WCAG 2.2.
- Time estimate
- 25 to 40 hours.
First version: build the combobox following the ARIA Authoring Practices pattern: arrow keys, Escape, Home and End. Add a Playwright accessibility test that drives it with the keyboard only and runs axe.
Stretch: add the date picker and a short note on what you heard when you tested with a real screen reader. Automated checks catch only part of the problem, so say in the README which parts you checked by hand.
Which portfolio projects show you work well with other people's code?
Most jobs are spent inside code someone else wrote. These four make that skill visible, and two of them cost nothing but patience.
01 Three merged pull requests to one open-source project
Not a build: a documented record of contributions to a project you actually use.
- Stack
- Whatever the project uses.
- Teaches
- Reading unfamiliar code, following a contributing guide, taking review comments well.
- Time estimate
- 15 to 30 hours spread over weeks, because maintainers take time to reply.
First version: read GitHub's guide to finding ways to contribute, pick a project you use, and fix a documentation error. Then fix a small bug with a test, then a third change.
Stretch: help triage issues or review someone else's pull request. Link all three merged changes from your README, with one sentence on what each taught you.
02 A release pipeline for a small library
A tiny package where pushing a tag runs the tests and publishes the release automatically.
- Stack
- npm or PyPI, GitHub Actions, Semantic Versioning, Conventional Commits.
- Teaches
- Release hygiene, version rules, changelogs, supply-chain provenance.
- Time estimate
- 12 to 20 hours.
First version: a small library, such as a date-range parser, with tests. A tag that follows SemVer triggers a workflow that tests and publishes. Write commit messages in the Conventional Commits format.
Stretch: generate the changelog from commits, following Keep a Changelog, and publish with npm's provenance statements so consumers can see which workflow built the package.
03 One module of an old app, ported behind characterization tests
Pick an aging open-source app, pin down what one module does today, then rewrite it without changing behavior.
- Stack
- The old app's language plus a modern test runner for the rewrite.
- Teaches
- Legacy code, characterization tests, incremental replacement.
- Time estimate
- 25 to 40 hours.
First version: write characterization tests that record what the module returns for many inputs, odd results included. Then write the replacement until the same tests pass.
Stretch: apply the strangler fig pattern: route a share of real calls to the new module, compare outputs and keep a log of every difference you found.
04 A tiny app on TestFlight or Google Play testing
A single-purpose mobile app distributed to invited testers through the stores' own test channels.
- Stack
- Swift, Kotlin, Flutter or React Native; a crash reporter.
- Teaches
- Code signing, build pipelines, tester feedback, release notes.
- Time estimate
- 30 to 50 hours.
First version: one screen, one job, distributed to five people through Apple's TestFlight or a closed test on Google Play. Ask each tester to do one task and watch where they hesitate.
Stretch: crash reporting, per-build release notes and a short list of what you changed after tester feedback. Store steps are covered in publishing on the App Store and on Google Play.
How do you pick one and keep it from stalling?
Most portfolio projects die at 70 percent: the idea is clear, the first screens work, and the remaining work is dull. Choose by what you want to say in an interview, then shrink the scope until you can finish in a month of evenings.
- Write the sentence you want to say: "I shipped X to Y people" or "I made Z ten times faster." Pick the project that makes it true.
- List what you will not build. Put it in the README on day one.
- Set a deploy date, not a finish date. Deploy a broken version on day three so the pipeline is never the last problem.
- Add one test per bug you fix. The suite then grows from real failures.
- Show it to one person before you add the next feature.
- Stop when the README is honest. Write the hard decision, the cut features and the next step, then move on.
If you use an AI coding tool, you can still explain every file you ship. Write the first prompt with a scope and a done-when line, as described in how to write an app build prompt, and read the diff before you accept it. If you do not have an idea, post what you would like built or browse developer tool ideas and side project ideas.
Frequently asked questions
How many projects should a portfolio have?
Three to five finished projects are enough. A reviewer remembers one or two, so make each one complete, deployed and explained. Twelve half-built repositories read as a habit of stopping. If you have more, pin the best three on your profile and archive the rest.
Should portfolio projects be original?
They do not need to be new, but they need to be yours. A familiar idea built carefully, with a real user and a written decision log, beats a novel idea that barely runs. Avoid unmodified tutorial projects, because reviewers have seen them many times.
What should a portfolio project README include?
A one-sentence description, a live link, a screenshot, the reason it exists, one hard decision you made and why, what you left out on purpose, and exact run and test commands. The decision and the cut list show judgment, which is what a README can prove that code alone cannot.
How long should a portfolio project take?
Between 12 and 50 hours for most of the ideas above, spread over two to six weeks. The longer ones involve waiting for users, reviewers or store approval. If a project passes two months, cut scope instead of extending the deadline.
Can I use AI coding tools for portfolio projects?
Yes, as long as you can explain every part of what you ship. Interviewers ask why you chose a design, not who typed it. Write a scoped first prompt, read each diff, and keep your own tests and decision log. Do not submit code you could not debug live.
What are good portfolio project ideas for beginners?
Start with the client tool, the status page or the release pipeline. They need modest code, have a clear finish, and produce evidence such as a measured saving or a green build. Leave the load-tested service and the accessible components for your second or third project.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.