Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersFull stack project ideas: 12 apps with a database, a server and a deploy
A good full stack project has a database, a server that enforces rules, a user interface and a deployed URL, and it teaches one hard backend problem. Examples: a read-later app with full-text search, a group expense ledger, a limited ticket drop that cannot oversell, sign-in built from sessions, or an uptime monitor with a status page. Below are 12 projects in four groups, each with a stack, a first version, a stretch goal and a time estimate.
What makes a project full stack?
A project is full stack when the server owns something the browser cannot be trusted with. That might be a rule (a ticket can only be sold once), a secret (an API key), or a record that outlives a session. A to-do app that saves to a database through two routes is technically full stack and teaches almost nothing. The projects below are chosen because each has one backend problem that a simple solution gets wrong.
Use the stack you already half know. The lessons are the same in Next.js with Postgres, Django, Rails, or Express with SQLite. If you want a framework to start from, the Next.js App Router docs cover routing, server rendering and server-side data access in one place. If you have not built a front end yet, start with React project ideas or web development project ideas.
| Problem you will meet | Project | Group |
|---|---|---|
| Searching text in a database | Read-later app | Data |
| Money as integers, balances | Group expense ledger | Data |
| Two requests at once | Limited ticket drop | Data |
| Passwords and sessions | Sign-in from scratch | People |
| Who may see what | Team workspace with roles | People |
| Who changed what | Admin dashboard with audit log | People |
| Untrusted files | Image upload pipeline | Files and jobs |
| Expiry and secret links | Expiring file share | Files and jobs |
| Scheduled work | Uptime monitor with status page | Files and jobs |
| Doing a job exactly once | Weekly digest email | Files and jobs |
| Pushing updates to clients | Shared list with live sync | Live and operated |
| Recovering from disaster | Deployed app with a tested restore | Live and operated |
Project name: Who uses it (one sentence): The one backend problem it teaches: Tables (names and the key columns): Rules the server enforces (three bullets): What the browser must never decide: What I will not build in version one (three things): Worked example with real numbers that proves the rule:
Which full stack projects teach data modeling?
Start with data. If your tables are right, the rest of the app is plumbing. If they are wrong, no amount of front-end work will save it.
01 Read-later app with full-text search
Save a link, store the readable text of the page, and search across everything you have saved.
- Stack
- Any web framework, Postgres.
- Teaches
- Fetching and parsing pages safely, tags as a many-to-many table, Postgres full-text search, ranking and highlighting, indexes.
- First version
- Paste a URL, the server fetches it and stores title and text. A search box returns ranked matches with a snippet.
- Stretch goal
- Tags, an import from a browser bookmarks export, and a weekly “you saved this and never read it” list.
- Time
- 12 to 20 hours.
The server fetches URLs that strangers type, so limit it: only http and https, a timeout, a size cap, and never addresses inside your own network. That is a real security lesson hidden in a bookmark app. Add a search index and compare query time before and after on 10,000 rows of sample text.
02 Group expense ledger with settle-up
A shared ledger for a trip or a flat where people record who paid, and the app works out the fewest payments that settle everyone.
- Stack
- Any framework, Postgres.
- Teaches
- Money as integer cents, an append-only ledger, balances computed from entries, fair rounding, many-to-many shares.
- First version
- Create a group, add people, add an expense with a payer and who shares it equally. A balances view and a “who pays whom” list.
- Stretch goal
- Uneven shares, multiple currencies stored with the rate used, and edits recorded as new entries, not overwrites.
- Time
- 15 to 25 hours.
Worked example for a test: three people share 120.00. Ana paid 90.00, Ben paid 30.00, Cy paid nothing. Each owes 40.00. Ana is up 50.00, Ben is down 10.00, Cy is down 40.00. Two payments settle it: Cy pays Ana 40.00 and Ben pays Ana 10.00. Check rounding with 100.00 split three ways: 33.33, 33.33 and 33.34, and the cents must add back to 10000. The board’s Kids chore board with pocket money needs the same ledger idea.
03 Limited ticket drop that cannot oversell
Sell 100 tickets to 500 people clicking at the same second, and sell exactly 100.
- Stack
- Any framework, Postgres, a payment provider in test mode.
- Teaches
- Race conditions, transactions, row locking, unique constraints, holds that expire, idempotency.
- First version
- An event with capacity 100. A buy button claims one ticket. A load script fires 500 requests at once and the sold count ends at exactly 100.
- Stretch goal
- A 10-minute hold while the buyer pays, released automatically, and a waiting list that offers freed tickets in order.
- Time
- 15 to 25 hours.
The obvious code reads the sold count, checks it is under 100, then inserts a ticket. Two requests can read 99 at once and both succeed. Fix it in the database: make the claim one atomic statement that only succeeds while the count is under capacity, or lock the event row inside a transaction. Read how Postgres isolation levels behave, then prove your fix with the load script, not by reading your own code. The board’s Neighbourhood tool library has the same shape: one item, many people wanting it.
Build a ticket sale in Next.js with Postgres. Table events(id, name, capacity) and tickets(id, event_id, buyer_email, created_at). Route: POST /api/events/:id/buy takes an email and claims one ticket. Rule: the number of tickets for an event must never exceed capacity, even under 500 simultaneous requests. Enforce this in the database inside one transaction, not in application code that reads then writes. Also write scripts/load-test.ts that fires 500 parallel buy requests at an event with capacity 100 and prints the final ticket count. Do not build: payments, accounts, a seat map. Done when: the load test prints exactly 100 on five consecutive runs.
Which full stack projects teach users and access?
Accounts are where beginner apps become dangerous. In production, most people use a managed sign-in service. Build the version below once anyway, in a throwaway project, so you know what that service is doing for you.
01 Sign-in from scratch with sessions
Email and password sign-up, sign-in, sign-out and a protected page, with passwords stored safely and sessions that can be revoked.
- Stack
- Any framework, Postgres, a password hashing library.
- Teaches
- Password hashing, session cookies, CSRF, rate limiting, account enumeration.
- First version
- Sign up, sign in, a /me page, sign out. Passwords hashed with a slow algorithm. Cookies marked HttpOnly, Secure and SameSite.
- Stretch goal
- A sessions list with “sign out everywhere”, a limit of 5 failed attempts in 15 minutes, and password reset by a one-time link.
- Time
- 12 to 20 hours.
Do not invent the details. The OWASP Password Storage Cheat Sheet covers the accepted algorithms, including Argon2id, scrypt, bcrypt and PBKDF2, and the Session Management Cheat Sheet covers cookies and expiry. Use them as a checklist. Make sign-in answer the same way whether the email exists or not, or you leak who has an account.
02 Team workspace with invites and roles
Users create a workspace, invite teammates by email, and see only the data their role allows.
- Stack
- Any framework, Postgres.
- Teaches
- Multi-tenancy, role-based access, invite tokens, authorization on every query, row level security.
- First version
- Owner, member and viewer roles. Invites by link. A notes table where every row belongs to a workspace and every query filters by it.
- Stretch goal
- Move the tenant filter into the database with row level security, and write a test that a member of workspace A cannot read workspace B by guessing ids.
- Time
- 18 to 30 hours.
Keep a table of who may do what and test it as a grid: each role against each action. The bug you are hunting is the missing check on one route. A guessed id that returns another team’s row is the most common real-world version of it.
03 Admin dashboard with an audit log
A back office where staff change records, every change is logged with who and when, and the log can be filtered and exported.
- Stack
- Any framework, Postgres.
- Teaches
- Append-only tables, database triggers or service-layer hooks, filtering and pagination, CSV export, least privilege.
- First version
- A customers table with edit and deactivate. Each change writes actor, action, record id, before and after to an audit table that has no update or delete route.
- Stretch goal
- A diff view for each change, a filter by actor and date, and a database role that cannot modify audit rows at all.
- Time
- 12 to 20 hours.
The rule to enforce is that the log is trustworthy only if the app cannot rewrite it. Put that rule in database permissions, not in your good intentions. Then try to break it in a test.
Which full stack projects teach files and background work?
Real apps do work when nobody is clicking: resizing a picture, expiring a link, checking a site, sending a summary. These four teach the parts that go wrong quietly.
01 Image upload pipeline
Users upload photos straight to storage, the server verifies and resizes them, and a review queue holds anything suspicious.
- Stack
- Any framework, object storage, a worker process.
- Teaches
- Pre-signed upload URLs, content sniffing, size limits, a job queue, thumbnails, orphan cleanup.
- First version
- Get a time-limited upload URL from the server, upload from the browser, a worker checks the file’s real type, writes three sizes and marks the row ready.
- Stretch goal
- Strip metadata from every image, a quarantine state for files that fail checks, and a nightly job that deletes uploads no row refers to.
- Time
- 15 to 25 hours.
Never trust the file name or the type the browser claims. Read the first bytes and decide yourself. Cap size on the server. A pre-signed URL lets the browser upload without ever holding your storage credentials, which is why this pattern exists.
03 Uptime monitor with a status page
Check a list of URLs every five minutes, record the results, and show a public page with current status and 30-day history.
- Stack
- Any framework, Postgres, a scheduler such as cron.
- Teaches
- Scheduled jobs, time-series tables, timeouts, alert thresholds, aggregation queries, caching a public page.
- First version
- A checks table with URL, status, response time and time. A job that fetches each URL with a 10-second timeout. A page with green or red per site.
- Stretch goal
- Alert after three failures in a row, daily rollups so the page stays fast, and uptime percentages per site.
- Time
- 12 to 20 hours.
Every five minutes is 288 checks a day and 8,640 over 30 days, per URL. Work out how many rows that is for 20 URLs before you choose how to query it. Note that three failures in a row means up to 15 minutes before an alert; decide on purpose whether that is acceptable.
04 Weekly digest email that sends exactly once
Each user gets one summary email each week at 8 in the morning their time, and a crashed or repeated job never sends it twice.
- Stack
- Any framework, Postgres, a mail service in sandbox mode.
- Teaches
- Time zones, idempotent jobs, unique keys per user and week, unsubscribe links, retries.
- First version
- A job that finds users whose local time is 8:00 on Monday, builds a summary, and sends it. A table with a unique key on user and week records each send.
- Stretch goal
- Skip empty digests, a one-click unsubscribe that needs no sign-in, and a log of bounces.
- Time
- 10 to 16 hours.
Insert the send record first. If the insert violates the unique key, someone already sent it and you stop. Run the job twice in a test and check one email was produced. Use a sandbox or a local mail catcher while you build, so a bug cannot message real people.
Which full stack projects teach live updates and operations?
The last two cover what happens after the code works: updates that reach other people's screens, and getting the system back after something breaks.
02 A deployed app with a tested restore
Take any project above, deploy it, back up its database on a schedule, then delete the data and restore it from the backup.
- Stack
- A small server or a managed host, Postgres, a scheduled backup.
- Teaches
- Environment config, migrations, backups, restore drills, health checks, logs.
- First version
- The app runs at a public URL. A nightly pg_dump goes to storage in another place. A script restores it into an empty database.
- Stretch goal
- Point-in-time recovery using continuous archiving, and a written runbook another person could follow.
- Time
- 10 to 18 hours.
A backup you have never restored is a hope, not a backup. Time the restore and write the number down. Keep configuration in environment variables, as the twelve-factor app method describes, so the same code runs on your laptop and in production.
Where do I find a full stack project with real users?
Build for someone you can ask. The board at Post your build ideas lists app ideas that people posted because they will not build them. Browse all ideas, or categories with data-heavy problems such as finance and events. Each idea has a generated build prompt you can paste into Claude Code, Cursor or Lovable, and the projects above give you a checklist to review what the tool builds. Posted is not the same as validated, so talk to one person who has the problem before you design tables.
For a wider mix of languages and levels, see coding project ideas. Going from a finished project to a launched product is covered in how to scope an MVP.
Frequently asked questions
What is a good full stack project for a beginner?
A read-later app with full-text search is a good first one. It needs a form, a server route, a database with two or three tables and a search query, and it deploys easily. Add tags after the basic version works. Avoid starting with sign-in or payments.
Which stack should I use for a full stack project?
Use the one you already know best, then change a single thing per project. Next.js with Postgres, Django, Rails, or Express with SQLite all teach the same backend lessons. Postgres is a good default because it supports full-text search, locking and row level security out of the box.
Do I have to build authentication myself?
Build it once, in a throwaway project, so you understand sessions, hashing and CSRF. For anything real, use a managed sign-in service or your framework's tested library. Writing your own for production is a common source of security holes.
How do I test for race conditions?
Write a script that sends many requests at the same moment and check the end state against the rule. For a ticket sale with 100 tickets, fire 500 buy requests and assert exactly 100 sold. Run it several times. A race that fails one run in ten still counts as a bug.
How many full stack projects do I need for a portfolio?
Two or three well-finished ones are enough. Pick projects that show different skills: one with tricky data, one with users and permissions, one with background work. Deploy them, link the live URL, and add a short write-up of the hardest problem and how you solved it.
Can an AI coding tool build a full stack project for me?
It can write most of the code, but it will not know which rule matters. Tell it the one backend rule in the first prompt, ask for a test that proves it, and read the database queries yourself. Most serious bugs here are in access checks and concurrent writes.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.