Ship a real full-stack project

Every CS student’s portfolio has the same problem: 17 half-finished projects, none with a live URL, all stuck at the 30-percent mark where the architecture is laid out and the real work hasn’t begun. The capstone of this track is the inverse: one project. Finished. Deployed. With telemetry. On your own domain. The kind of thing a recruiter clicks through, a friend uses for a real task, and you can talk about for 10 minutes without getting bored.

The single biggest opinion in this module: your portfolio needs one of these, not five. A single shipped, polished, observable project beats a dozen impressive READMEs every time. The recruiter who skims your GitHub gives each repo about 12 seconds. They want to see one URL that works.

The second-biggest opinion: ship a v0 in two weeks. The v0 you can demo in a single screenshot is the v0 that ever ships. Anything bigger and you’ll spend the next six weekends on infrastructure, design systems, and the perfect form library, and the project will quietly die in a private repo. The way out is to scope so small you’d be embarrassed, ship that on day 14, and let the project earn its expansions afterward.

Set up

This module assumes you’ve shipped the work in 03.1 through 03.5. If https://yourname.com and https://api.yourname.com aren’t both live with HTTPS already, finish 03.5 first.

You’ll add two things during this module:

• A monitoring tool. Use Sentry for errors, PostHog for product analytics. Both have generous free tiers.
• A real custom domain for this project specifically (not just a subdomain of your portfolio). Domains under $20 a year on a .app, .dev, or .io go a long way for credibility.

# Sentry, in either Next.js or FastAPI
pnpm dlx @sentry/wizard@latest -i nextjs
# or for Python:
uv pip install sentry-sdk

Read these first

Five resources, in order, then stop:

1. Paul Graham — Do things that don’t scale. essay · 15 min · the right framing for shipping a portfolio project that nobody asked for.
2. Basecamp / 37signals — Shape Up. book · 90 min for chapters 1–4 · how to scope to a fixed time window. The single best writing on shipping.
3. Julia Evans — How to write a release announcement. post · 10 min · so the launch isn’t an afterthought.
4. PostHog docs — Tracking custom events. docs · 20 min · the minimum viable analytics setup.
5. Sentry docs — Releases. docs · 15 min · so you can blame a specific deploy when errors spike.

You’ll be tempted to read 50 articles about the perfect product idea. Don’t. Pick from the list at the end of this module and start.

Step 1 — Scope the v0

The v0 has one rule: you can demo it in a single 1080p screenshot, with no animation needed. If a friend asks “what does it do,” the answer is one sentence and the screenshot. Anything more elaborate is v1, and v1 is what kills student projects.

Examples of correctly scoped v0s:

Project idea	v0 in one screenshot
”Better Hacker News”	A list of stories, sorted by your custom score formula. That’s it.
”Personal CRM”	A single page with people you’ve met, last contact date, sortable.
”Recipe organizer”	A list of recipes with photos. Search by ingredient. No editing yet.
”Workout tracker”	One page: today’s workout, three buttons to log sets, a chart of weekly volume.

Things that are not v0:

• A landing page. (You will write one. After v0 is real.)
• A user system with email verification, password reset, OAuth. (Magic links via Auth.js or single-tenant for v0. You.)
• An admin dashboard. (You’re the admin. Use psql.)
• Mobile app. (v1, see 03.6 for the test of whether you actually need one.)
• A blog. (You don’t need a blog before you have a project.)

If your v0 still doesn’t fit in one screenshot after a first cut, cut again. The cut is the work.

Step 2 — Write a one-page spec

A spec stops you from wasting weekend three on a feature you decided in week one and forgot the reasoning for. Keep it to one page. The shape that survives:

# Project name

One sentence: what it is, who it's for.

## Problem
Two paragraphs. The actual user, the actual need, the alternatives they have today, why those don't work.

## v0 scope
Bullet list of features in v0. Things explicitly NOT in v0 below.

## Not in v0
Bullet list. This is the most important section — it's the boundary you defend.

## Schema (rough)
- Table users(id, email, ...)
- Table <main_thing>(id, user_id, ...)

## Routes (rough)
- GET /<thing> — list
- POST /<thing> — create
- ...

## Success metric
One number that tells you v0 worked. "I use it every day for a week" is enough.

## Decisions log
- 2026-05-01: Chose Postgres over SQLite because <reason>.

That’s it. Save it as SPEC.md in the repo root. Update the decisions log when you change your mind. Future you will thank present you.

Step 3 — Build in the right order

The order you build determines what gets cut when you run out of time. Build in this order, and what survives a time-cut is the part that matters:

1. Schema first. Open psql. Sketch the tables. Add foreign keys. The schema will outlive every UI decision you’ll make.
2. API second. Stand up the endpoints from the schema. Test with curl and a bash file you save as smoke.sh. No frontend yet.
3. UI third. A spartan UI bound to the API. Tailwind defaults. No animations. No design system tokens beyond what comes for free.
4. Polish fourth. Now type, color, hierarchy, hover states, loading skeletons, error states, empty states.
5. Observability fifth. Sentry, PostHog, an uptime monitor. (Even on an unlaunched project. Errors in development are easier to find when you can grep them.)
6. Launch. Write the announcement. Post it. Send it to five specific people who would care.

Most students reverse this. They start with a Figma file, three weeks on a design system, then realize the schema doesn’t support what they designed. Schema-first is non-negotiable.

Step 4 — Observability lite

You can run a real product with surprisingly little observability. Three sources of signal, all on free tiers:

Tool	What it tells you	Setup time
Sentry	Every uncaught exception with a stack trace, browser, user, breadcrumbs	15 min
PostHog	Which pages people visit, where they drop off, custom events	30 min
BetterStack / UptimeRobot	”Is the site responding from outside my house” — pings every minute	10 min

Wire Sentry on both client and server. The client tells you which feature breaks for which user. The server tells you which endpoint is throwing 500s on which input. Tag every release:

SENTRY_RELEASE=$(git rev-parse --short HEAD)
sentry-cli releases new "$SENTRY_RELEASE"
sentry-cli releases set-commits "$SENTRY_RELEASE" --auto
sentry-cli releases finalize "$SENTRY_RELEASE"

Now when an error spikes after a deploy, the dashboard shows you exactly which commit introduced it.

For PostHog, capture three event types:

• Page views (free, automatic).
• The thing the product is for. (“recipe_added”, “workout_logged”, “story_clicked”.)
• Conversion events. (“signup_completed”, “first_value_reached”.)

If a feature does not show up in those events, it is not a feature; it is decoration.

Step 5 — Launch checklist

Before the launch post is ready, all of these are green:

• HTTPS live on the custom domain, no mixed-content warnings.
• https://yourdomain.com/healthz (or equivalent) returns 200.
• An anonymous incognito user can sign up, do the main thing, and log out without errors.
• Error monitoring catches a deliberately-thrown exception in a test page and shows it in Sentry.
• Page views show up in PostHog.
• An uptime monitor is configured and emails you when the site is down.
• A README with: one-paragraph description, screenshot, “live at” link, “tech stack” section, demo video or GIF, install instructions for local dev.
• Open Graph tags so the link previews on Twitter, LinkedIn, Discord look intentional.
• The HN, Reddit, or X post is drafted in a separate file and slept on for a day.

If any of those are missing, the launch waits.

Step 6 — Six project ideas worth considering

These are scoped so the v0 fits in one screenshot. Pick the one that scratches a real itch in your life — that is the project you will not abandon.

Idea	Why it works	Risk
Personal CRM	Real, recurring use. Schema is small. Mobile-friendly use case.	Easy to over-design.
Reading list with annotations	Re-reads the spec for “save and reflect.” Markdown is enough.	Crowded space; needs a strong opinion.
Workout / habit tracker	Lots of write events, charts make it visual, daily use.	Charting can rabbit-hole you.
Recipe organizer for one cook	Photo-heavy, search-driven, real-life utility.	Image storage costs if you scale.
AI-written release notes for a public GitHub repo	Real audience, taste-driven, plays well with module 04.x later.	API cost management.
Local-first markdown notes that sync via your own backend	Touches every layer; offline-first; CRDT optional.	Conflict resolution is a real engineering project.

Score them on these axes before picking, on a scale of 1 to 5 each:

• Will I personally use it? (Below 4 — skip.)
• Can I demo v0 in a screenshot? (Below 5 — re-scope.)
• Is the schema obvious to me? (Below 3 — keep thinking.)
• Will this teach me something? (Below 3 — boring.)
• Can a recruiter understand the value in 10 seconds? (Below 4 — clarify the pitch.)

Total under 18 across the five axes? Pick a different idea.

Step 7 — The launch

The launch post is short and specific. Roughly:

I built [name]. It does [one sentence].

I built it because [the problem you had]. The way I solved it is [the
specific approach]. The bits I'm proud of: [two or three concrete details].
The bits I'd change: [one honest thing].

Live: https://yourdomain.com
Source: https://github.com/you/repo

Three places to post:

• Hacker News “Show HN” (Tuesday-Thursday morning, US time).
• A subreddit specific to the audience (r/selfhosted, r/foodscience, r/CRM).
• LinkedIn, with the live URL above the fold.

Watch the Sentry dashboard for the first 30 minutes after posting. You will find a 500 you didn’t expect. Ship the fix while the post is still live.

Going deeper

1. Tyler Tringas — Indie hackers, scope down · for the tools-vs-product framing.
2. Patrick McKenzie — Standing invitation · how to introduce yourself when you have a project to point at.
3. Julia Evans — Examples are awesome · how to write a README that recruiters actually read.
4. Stripe Press — High Growth Handbook · once you’ve shipped one and want to understand what comes after.
5. Levels.fyi — engineering portfolios that landed offers · pattern-match on what actually got hired.

Skip “10 portfolio projects to land a FAANG job.” They’re written by content marketers, not engineers, and the projects all look identical.

Checkpoints

1. Take an idea you have right now. Score it against the five axes in step 6. Defend each number in one sentence.
2. Sketch the v0 of that idea so it fits in one screenshot. List explicitly what is not in v0.
3. Write the four section headers your SPEC.md will have. For each, name the single most important sentence.
4. Walk through the build order in step 3. Why is “design system” not in the list before step 4?
5. Name the three observability tools in step 4 and what each one tells you that the others don’t.

When the project is live on a real domain, when one stranger has used it and survived, when the launch post is up — the T3 track is finished. Your portfolio now has the project you point recruiters at. Move on to 04.1 The math you actually need for ML, where you’ll start the next track on top of a foundation you already have.