Track · Apps

Build a real app — spec first, then ship it.

An app is a site that remembers things. You'll build a small task tracker that saves your data, runs on a real database, and deploys to the cloud — and you'll do it the way professionals build with AI now: write a short spec first, let the agent implement, review every change, and prove it works with a test. This is where vibe coding grows into engineering.

How this track reads

This is the path made concrete for software people depend on. It leans harder on the chops from Vibe → agentic than the other tracks, because apps are where "it works on my screen" stops being good enough. Each step has a prompt, the concept, and a your turn.

#What you'll install

Node.js 24 + VS Code — same base as the web track; mise from the groundwork environment already gives you Node.
An AI assistant that edits files — Claude Code, Cursor, or similar, working in your project folder.
A free database — a hosted Postgres (Neon or Supabase free tier) for the real version, or SQLite to start fully local.
Git + a free host — a Git repo and a Vercel account for serverless deploys.

1Write the spec first

ask your AIHelp me write a one-page spec for a personal task tracker: what it does, the data it stores (a task has text, a done flag, a created date), the actions (add, toggle done, delete), and 3–4 acceptance criteria like "a refreshed page still shows my tasks." Don't write code yet.

Concept · Spec-driven developmentThe spec is the real instruction — the code is downstream of it. Writing it first turns a vague idea into clear, checkable requirements, and gives the agent a target instead of a vibe. This single habit is the biggest difference between a toy and software you can trust. Keep the spec in the repo; you'll edit it as the app grows.

Your turn: add one acceptance criterion the agent didn't think of (an empty task shouldn't be addable?). You're now designing, not just asking.

2Scaffold the app

ask your AIScaffold a Next.js app for this spec and build the front end first with in-memory data: a form to add a task and a list that shows them with a done toggle and delete. Explain the folder structure as you go.

Concept · App structure & client vs serverA framework gives you a real project layout — pages/routes, components, and a split between code that runs in the browser (the UI) and code that runs on the server. Right now data lives only in memory and vanishes on refresh — that's the gap the next step fills, and feeling that gap is the point.

Your turn: add a task, refresh the page, watch it disappear. Now you want a database — that's the pain that earns the next step.

3Give it a memory

ask your AIAdd a database so tasks persist. Define a tasks table matching the spec, and wire add/toggle/delete to read and write it. Use SQLite locally, or a free hosted Postgres via an environment variable for the connection string.

Concept · Data models, CRUD, and secretsAn app's data lives in a database as tables (your task model becomes columns). The four basic operations — Create, Read, Update, Delete (CRUD) — are most of what apps do. And the database password goes in an environment variable, never in the code — your first real security habit.

Your turn: confirm a secret isn't hard-coded anywhere. Ask the agent "where does the connection string come from?" and verify the answer in the files.

4Prove it works

ask your AITurn my acceptance criteria into automated tests — at least one that adds a task and confirms it's saved, and one for delete. Show me how to run them.

Concept · Tests as the safety netA test encodes "this should be true" so a machine checks it for you — forever. When an agent changes code later, the tests catch what it broke. Tests are how you let the AI move fast without holding your breath: green means the behavior you specified still holds.

Your turn: deliberately break the add feature, run the tests, and watch one go red. That red line is the test doing its job.

5Review like an engineer

ask your AIAdd a feature: let me edit a task's text. Make the change, then show me the diff and explain what you touched and why.

Concept · Diff reviewThis is the central chop. Don't just check that it runs — read what changed, decide if it's the right design, and make sure it didn't quietly alter something else. The agent is fast and fallible; you are the reviewer who keeps the quality bar. Run the tests after, too.

Your turn: find one thing in the diff you'd have done differently and ask the agent to change it. You're directing now, not following.

6Deploy serverless

ask your AIDeploy this to Vercel from my Git repo, set the database connection string as an environment variable in the host, and give me the live URL.

Concept · Serverless hostingYour app runs on infrastructure that scales automatically and costs nothing when idle — you push to Git, it builds and goes live. This "serverless" shape (functions + a managed database) is how modern apps are hosted from a hobby project all the way up to a company's product.

Your turn: open the live URL on your phone, add a task, and see it persist. You shipped a real, multi-device app.

#Where to go next

Fundamentals, free: the Next.js Learn course, and The Odin Project for a full free full-stack curriculum.
The chops: keep running the loop from Vibe → agentic — update the spec, let tests go red, make them green, review the diff, note what changed.
Add the next layer: accounts and login, then multiple users. The moment an app has real users, you're doing professional software.

This is the on-ramp to a real platform

The shape you just built — spec, a data model, tests, a reviewed diff, a serverless deploy — is exactly how production apps are made, only smaller. Scale it up with accounts, multiple users, and several apps sharing one login, and you've described a full application platform. That's a long road, and you just walked the first mile of it.

Built to be rebuilt. Open source, no tracking, works offline.