Back to path
SmallWeekend build ~7h· 4 milestones

Ship a full-stack app end-to-end

The classic "can you actually build and deploy a whole thing?" test. You take an idea from empty repo to a deployed, authenticated app with a real database, UI, API, persistence, and auth, all wired together and live on a URL a stranger can use.

Frontend + backend integrationREST/RPCDatabaseAuthDeploymentObservability & cost awareness

What you'll build

A deployed full-stack app with a frontend, an API, a persistent database, authentication, and a real URL anyone can use, reproducible from a README in under ten minutes.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

.env.examplebash
# Managed Postgres connection string (Neon / Supabase / RDS)
DATABASE_URL="postgres://user:pass@host/db?sslmode=require"

# Hosted auth provider (Clerk shown; swap for Auth.js if you prefer)
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY="pk_test_..."
CLERK_SECRET_KEY="sk_test_..."

# Error tracking (added in the final milestone)
NEXT_PUBLIC_SENTRY_DSN=""

Reading this file

  • DATABASE_URL=The whole app finds its database through this one connection string, so it must be set before anything works.
  • sslmode=requireForces an encrypted connection to the database, which managed cloud Postgres providers expect by default.
  • CLERK_SECRET_KEYA server-only secret with no NEXT_PUBLIC prefix, so it never gets bundled into the browser where anyone could read it.
  • pk_test_...A test-mode key lets you build and demo safely without touching real users or real money.

Commit this; never commit .env.local. A stranger copies it to know what to set.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Vertical slice first

    5 guided steps

    A thin slice that touches every layer flushes out the integration problems (CORS, env vars, serialization) while the app is still small enough to debug fast.

  2. 2

    Add auth & persistence

    5 guided steps

    Without ownership checks, any signed-in user can read or mutate any other user’s rows, the single most common bug in take-home full-stack apps.

  3. 3

    Deploy it

    5 guided steps

    A project that only runs on your laptop proves nothing. Deploying forces you to handle secrets, build config, and a real database connection, the parts interviews probe.

  4. 4

    Know it broke & know what it costs

    4 guided steps

    A live app you can’t observe is a black box, and a "free tier" project that quietly costs money is a nasty surprise, both are table stakes even for a weekend build.

What's inside when you start

4 starter files, ready to clone
4 guided milestones
4 full reference solutions
8 code blocks explained line-by-line
4 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A deployed app with auth and a live URL
A README a stranger could run it from
A short note on how you enforce data ownership across the API
A 4-line cost note (cost today, first limit hit, cost at 10x traffic) and a working /healthz endpoint

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building