‹ Ship Your Tool Lesson 16 of 16
Contents Lesson 16 of 16

4 min read · professional

What you can now do, and what the exam checks

Five courses. This is the last lesson in the track, so it names what actually transferred.

The five disciplines

Planning and secret safety (course 1). A page of writing before the prompt, a key that lives on one side of a line, and the habit of reading what your assistant handed you.

Rebuilding and code review (course 2). Four questions before changing working software, four lenses in worst-consequence-first order.

Testing and correctness (course 3). Properties where there is no oracle, and the instinct that a flattering result is a bug prior.

Architecture and state (course 4). Where each piece lives, who may change it, and pricing a feature before building it.

Production discipline (course 5). CI that outlives your attention, an audit of what you installed, documentation for a stranger, and monitoring that turns silent failure into known failure.

None of those is about markets. The market data made them concrete and gave every claim something to be checked against — which is why the walls were measured rather than described.

What you actually learned about AI-assisted building

Generate freely, accept carefully. The bottleneck was never producing code.

Give it a contract, not a wish. The single biggest quality difference across all five courses.

It is strongest on the happy path and weakest at the edges. Spend review attention where the failures are: empty results, error envelopes, wrong units, the first and last element.

A flattering result is a bug prior. Course 3's rule, general beyond backtesting.

What the exam asks

Ten questions, seventy percent to pass, twenty-four hour cooldown, drawn from a pool so a retake is a different paper. Every fixture is fixed. Expect:

  • Read a workflow. A CI file with a hole in it; you name what it fails to catch.
  • Price the year. A deployment's daily call requirement against an allowance.
  • Order the deploy. A migration and a code change; you say what ships first and why rollback depends on it.
  • Spot the public-only risk. Something safe on a laptop and not safe on a URL.
  • Judge the README. What is missing before a stranger could run it.
  • Name the silent failure. A symptom, and which of the six unattended failure modes produced it.

After the exam

The certificate is the academy's part. Yours is the repository — and the honest measure of this track is not the exam but whether the tool is still running in three months, and whether you decided that rather than discovering it.

Then build the next one. The five disciplines do not care what the domain is, and the second tool takes a fraction of the time.

Definition of shipped

"Still running in three months" is a claim about the future, and the only way to hold it is a list you can run today. Eight checks, each with an answer you can see, each belonging to a lesson in this track — so a failure has an address rather than a feeling.

  1. It answers from a machine that is not yours. curl -sI https://your-tool.example — first line HTTP/1.1 200 OK. Run it from a phone on mobile data. A tool that works only from your desk was demonstrated, not deployed. — What "shipped" actually means
  2. The key is not in the repository, history included. export YOUR_KEY=$(grep -E '^EODHD_API_KEY=' .env.local | cut -d= -f2-) first, or the variable is empty and matches every commit; then git grep -lF "$YOUR_KEY" $(git rev-list --all) prints one commit:path line per hit and nothing when clean. A key deleted in a later commit still sits in an earlier one, and only this form finds it. — The security pass before anything is public
  3. The key is not in what the browser downloads. Fetch the deployed page, list the scripts it pulls, fetch each of those and search them for the key. Zero hits, or your secret is public and reachable without any hacking at all. — Configuration for someone else's machine
  4. The tests run, and one of them recomputes. npx vitest run, then open the tests: at least one must work out what it expects instead of asserting a number you pasted from the output. A test that expects what the code printed only proves the code still prints it. — The review that runs itself
  5. A stranger got it running from the README alone. Clone into an empty directory, follow the quick start with no improvisation, and time it. Five minutes and no questions asked, or the README is the next thing you fix. — The README nobody has to ask you about
  6. You have rolled back once, deliberately, and know how long it took. Deploy, roll back, roll forward, and write the three times down. That is what an incident will cost you, measured before the incident rather than during it. — Deploy so that rolling back is boring
  7. It stayed inside its quota for a day unattended. Leave it deployed and untouched for twenty-four hours, then read the meter. Whatever it spent, it spent on nobody. — Quota in production
  8. It answered a real question this week, and the date is written down. One line in REVIEW.md: the question, the answer, the day. — The final review

Try it now

Run the eight checks above and write the results in REVIEW.md under today's date — pass or fail, one line each, no softening. Then count them. Eight is the artefact this track was for; six is two addressed jobs with a page to open for each, which beats most working software. The count must not be unknown, because every check here is minutes of work and the only reason to skip one is that a suspicion is more comfortable than a result.

Then open the tool and ask it a real question you actually have about a market. If it answers, you built something. If it does not, you know which wall is in the way — worth more than a passing score.