Write the plan before you write the prompt
There is a way of building with an AI assistant that feels fast and produces nothing you can maintain. You describe a vague thing, you get 300 lines, you ask for a change, you get 300 different lines, and four hours later you have an app you cannot explain. The fix is not a better prompt. It is a page of writing you do before the first prompt.
This lesson is that page. It takes fifteen minutes and it is the difference between vibe-coding and gambling.
The tool you are going to build
A watchlist. Not a demo watchlist — yours, with the instruments you actually check, deployed at a URL you own, by the end of this course.
Small on purpose. A watchlist is the smallest thing that still contains every hard part of a real market tool: fetching data you do not control, keeping a secret out of the browser, rendering numbers that must line up, handling the moment the data is stale or missing, and living inside a quota. Get those right once and the screener, the backtester and the dashboard in the later courses are variations, not new problems.
What a one-page plan contains
Five sections. Resist making it six.
1. One sentence of purpose. Not features. The job.
A page I open at 7am that tells me, for the twelve instruments I care about, what moved overnight and by how much.
If you cannot write that sentence, you do not yet know what you are building, and no assistant can know it for you.
2. The data you need, named precisely. For each thing on screen, which endpoint answers it. You do not need to know the API yet — you need to know the question.
| On screen | The question | Endpoint |
|---|---|---|
| Last price | What is it trading at now? | /real-time/{ticker} |
| Change since yesterday | How far did it move? | same call, change and change_p |
| History for a sparkline | Where has it been? | /eod/{ticker} |
| Calls used today | How close am I to the limit? | /user |
The academy's reference is built exactly for this column: every endpoint, the market question it answers, and the lesson underneath it. Use it now and you will not guess later.
3. What you are deliberately NOT building. This is the section people skip and the one that saves the project. Write it down and your assistant stops inventing.
Not building: user accounts, a database, charts beyond a sparkline, mobile-native anything, alerts that push to my phone. Not yet: notes on symbols (course 1, unit 3).
4. Done, defined as something you can check. Not "it works". A sentence you can be wrong about.
Done = deployed at a URL, showing my twelve tickers with live-ish prices and change, on my phone, without my API key appearing anywhere in the browser.
5. The riskiest unknown. One thing. For this project it is always the same one, and it is the subject of lesson 3: the API key must never reach the browser, and everything about how you fetch data follows from that.
Why writing it down changes the output
Two reasons, and only one of them is about the assistant.
The assistant reason: a plan is context. Pasted at the top of a conversation, it stops the model inventing a database you did not ask for, and it gives you something to point at when the code drifts. "This is out of scope, see the plan" is a sentence that works.
The human reason, which matters more: a plan is what makes a diff reviewable. Without it, every generated change looks equally plausible, because you have no standard to hold it against. With it, you can look at 200 new lines and say that is not in the plan — which is how you catch the thing that would have cost you a weekend.
Put it in the repository
Your plan lives in the project as PLAN.md, not in a chat window. Chat scrolls away. A file gets read by your assistant every session, gets edited when you change your mind, and shows in git history when you changed it.
academy-dashboard-starter/
PLAN.md ← you write this, first
src/
...
Change of mind is expected. Change of mind that never gets written down is how a project quietly becomes something nobody chose.
Try it now
Write your own PLAN.md for a watchlist, using the five sections above. Two constraints: the purpose sentence must name a real time of day and a real reason, and the "not building" list must have at least four items on it. Keep it — you will paste it into your assistant in unit 2, and you will edit it in unit 3 when the tool turns out to need something you did not predict.