Building one real thing

The brief

Find one person with one real, small need. A tutor who takes bookings on WhatsApp and loses track. A shop that writes orders in a notebook. A club that keeps its roster in a spreadsheet three people edit. Somebody you can talk to, whose problem fits in a paragraph, and who will use what you build for a week and tell you what is wrong with it.

That last clause is the whole assignment. Everything in this course was about what happens when somebody other than you uses the thing. A demo you use yourself exercises none of it.

The specification, first

Before a prompt, the specification block’s output, on one page:

• The entities: three or four tables, with the columns every table needs.
• The actions: who can do what to which row.
• The rules: the things that must be true, and what happens when a rule is broken.
• The failure paths: the empty state, the wrong password, the double submission, the person on a phone in a train.
• The acceptance checks: the two-minute experiments, written before any code, that would show each feature working or not.

Show it to the person it is for. They will correct it. That correction is cheaper now than after the first build.

What built means

The checklist, which is the course in one page. Each line is a lesson, and each has a test you can run.

The machine and the model. A rules file the tool reads, with the forbidden lists for git and the database. The stack named in the specification and not chosen by the model.

Reading and checking. Every change read as a diff before being committed. The smallest experiment, run, for every claim the agent made.

Save points. A git history of at least twenty commits, each a working state, with messages that say what became true. A branch per feature. A remote. No secret in the history: the scan run and clean.

Shipping. Deployed on a free host, with a domain, HTTPS, environment variables scoped per environment, a version stamp in the footer that matches the latest commit, and a health route being pinged.

The parts that persist. A real database with migrations in a folder and run as a deploy step. Sign-in through a library. Sessions as the only source of identity. Uploads in object storage, if there are any. A backup restored into a fresh database, with the date recorded.

A model inside. One AI feature, called from a server route, with a timeout and streaming, the prompt in a file, output validated, three caps in place, a fallback message for the provider’s bad hour, and an eval set of twenty inputs that runs in one command.

The holes. The three-account script passing. The bundle and history scan clean. Every route with a schema at the top. The admin route gated by an allowlist and returning 404 to everyone else. A bot check on sign-up.

Running it. Error tracking with source maps and scrubbing. A report button. A privacy notice that names the model provider. A deletion path that includes the backups. A README that a developer could run from.

The stranger’s rubric

Give the app to the person it is for, and to one more person who has never seen it, and watch. Not over their shoulder; ask them to use it for a week and to press the report button whenever something is confusing or wrong. The measure of the capstone is what comes back: the reports, what each turned out to be, and what changed. Three reports found and fixed is a pass. Zero reports means either a very small app or a report button nobody found.

The write-up

One page, honest, kept in the repository:

• What the app does and who it is for.
• What broke during the build, how you found it, and which lesson’s technique found it.
• What the strangers reported and what each turned out to be.
• What you would not build this way: the line from the closing lesson, applied to this project.
• What you cannot yet explain about your own app.

That last item is the important one. It is the list the learning path is for, and it is the honest answer to the question every module of this course has asked: do you know what you have made, or does it merely work?

After

The exam at the end of this course tests the mechanisms. The capstone tests whether they hold under a stranger’s hands, which is the only test that has ever mattered for software. Keep the app running. In three months, the complaint list, the eval set and the git log will be a better record of what you learned than any certificate, and they will be yours.