After this lesson, you will be able to: Plan, build, and deploy a real full-stack web app using Next.js, Supabase, Tailwind, and Vercel — with a custom domain, working authentication, and at least one feature that fetches and mutates real data. End up with a live URL you can put on your resume and walk through in interviews.
This is the capstone. You'll pick one of three project briefs (or pitch your own), build it end to end, and ship it live. The goal isn't to learn new APIs — you have everything from the prior lessons. The goal is to assemble what you know into a polished, deployable thing that proves you can do this. When a hiring manager asks 'what have you built?', they want to click a link, not read a description. This is that link.
Choose ONE. Pick the one whose problem you actually feel — that motivation is what gets you across the finish line. All three are scoped to be buildable in 8-15 hours by someone who finished this subtrack.
**Who it's for:** anyone who needs a professional web presence. **What it does:** a homepage with your bio, a 'Projects' page that lists your work, a contact form that emails you when someone reaches out, and a Markdown-based blog. **Why it's good for a junior portfolio:** every junior dev needs one of these, and yours becomes a self-demo of the skills you're advertising. Recruiters click the link and immediately see you can ship a Next.js app, integrate Supabase, deploy to Vercel, and care about design.
**Who it's for:** a specific small workflow you (or a niche audience) does manually today. Examples: a URL shortener, a personal expense tracker, a meal planner that generates a shopping list, a habit tracker, a study-flashcard app. **Requirements:** auth (sign up / sign in), at least two data tables (one user-owned), one main feature (create / edit / delete items), a dashboard view. **Why it's good:** shows you can build a real product with users, not just static content. The SaaS-shape demonstration is what hiring managers at startups look for.
**Who it's for:** a community you care about that lacks a central index. Examples: a directory of free coding bootcamps, a list of remote-work-friendly companies in your country, a curated list of YouTube channels for a niche skill, a database of accessibility-tested websites. **Requirements:** a public list view (no auth required to browse), search and filter, admin auth so YOU can add / edit / remove entries, a 'submit a suggestion' form. **Why it's good:** demonstrates content modeling, public + admin views, search/filter UI, and gives you something genuinely useful to others.
When you walk through this in an interview or list it on a resume, you should be able to point at every one of these and show where it lives in YOUR code. **Frontend:** Next.js App Router, React Server + Client Components, Tailwind for styling, responsive layout. **Backend:** Supabase Postgres, Row-Level Security policies, API routes, input validation with Zod. **Auth:** Supabase email/password (or OAuth) with protected routes that redirect unauthenticated users. **Deployment:** Vercel with environment variables, preview deployments for every PR, custom domain with HTTPS. **Quality:** TypeScript throughout, no lint errors, accessible markup (semantic HTML, proper labels, keyboard-navigable). If you can hit all five, this project beats most junior portfolios.
Build in this order. The temptation is to start with the prettiest part; resist. Build the data flow first so you have something to style on a real shape.
Milestone 1: Plan on paper. Sketch the screens. List the database tables and columns. List the routes. 30 minutes.
Milestone 2: Scaffold the Next.js + Tailwind project (`npx create-next-app`). Push to a fresh GitHub repo. Deploy a one-page 'Hello world' to Vercel so the deploy pipeline is verified before you've built anything.
Milestone 3: Create the Supabase project. Define the tables. Enable RLS. Write the policies for each table. Test the policies with a sample insert as different users.
Milestone 4: Build the Server Component pages that read the data. No styling yet — just verify data is flowing.
Milestone 5: Build the auth pages (sign up, sign in, sign out). Gate any protected routes.
Milestone 6: Build the Client Components and API routes for mutations (create / update / delete). Validate input with Zod.
Milestone 7: Style everything with Tailwind. Add a header / footer / nav layout. Make it look intentional.
Milestone 8: Run Lighthouse. Fix any accessibility issues (missing alt, missing labels, low contrast). Add a `metadata` export for SEO.
Milestone 9: Add the custom domain in Vercel. Update env vars for production. Final deploy.
Milestone 10: Write a real README with a screenshot, a one-line description, the tech stack, and instructions to run locally. Take a screenshot for your portfolio.
Push the final version to your `main` branch. Vercel auto-deploys. Visit your live URL. Click every link. Sign up as a new user from scratch and make sure the full flow works end to end. Test on your phone. Send the link to a friend and ask them to try it cold. The thing isn't done until someone else can use it without you nearby.
**Interview pitch (60 seconds):** "I built [name], a [one-line description] using Next.js with the App Router, Supabase for the database and auth, and Tailwind for styling, deployed on Vercel with a custom domain. The interesting decision was [pick one: 'using Server Components to avoid shipping JS for the list pages,' 'wiring up Row-Level Security so a user can only see their own data,' or 'the preview-deployment flow that let me share work-in-progress without merging']. It's at [URL]." **Resume bullet:** Built and deployed [name] ([URL]), a [type] web app using Next.js (App Router), Supabase (Postgres + Auth with RLS), and Tailwind, hosted on Vercel with a custom domain. **Questions an interviewer might ask:** (1) How do you handle the case where two users try to update the same record at the same time? (2) What would you change if traffic 10x'd tomorrow? (3) Walk me through what happens when a user clicks 'Sign in,' from button click to authenticated state. (4) Why Server Components for [some page]? Could you have used a Client Component instead — what would have changed? (5) How do you keep your Supabase service-role key out of the browser? Be ready for any of those. The answer to all five is in code you wrote.
Sign in and purchase access to unlock this lesson.