What you are building, and why not from zero
A watchlist answers "how are my twelve doing?". A screener answers a harder question: "out of everything, which ones are worth my attention at all?"
Same data, opposite direction. The watchlist starts from a list you already have. The screener starts from a market and has to produce the list.
The instinct to start again, and why it is wrong
The obvious move is a new project. Resist it, because the interesting work of this course is not the screener — it is the rebuild.
Look at what your watchlist already contains: a server-side proxy that keeps the key safe, error handling that fails one row instead of the page, a table that renders figures so they line up, a usage meter, a deployment. Every one of those is needed here too, and every one of them took you a course to get right.
Starting again throws all of it away and, worse, teaches you nothing transferable. The skill that pays for itself across every product you will ever build is seeing what generalises in code you already have — and that is a skill you cannot practise on a blank file.
The three questions of a rebuild
Before touching anything, write the answers down in your PLAN.md. Every rebuild you ever do is these three questions.
1. What survives untouched? The proxy. The key handling. The usage meter. The deploy pipeline. These are not "watchlist code", they are "market tool code", and you were right to build them once.
2. What generalises? The table. Today it renders a fixed set of columns for a fixed set of rows. A screener needs the same behaviour with different columns and rows it did not choose. That is one component with a wider contract, not two components.
3. What is genuinely new? Filters. A universe you did not pick. Ranking. Saved criteria. This is the only part that deserves new files — and noticing that it is a small part is the point of the exercise.
There is a fourth question people forget: what dies? Notes and thresholds belong to instruments you chose deliberately; they make no sense against a result set that changes every time you run it. Say so in the plan, or your assistant will helpfully carry them over.
What a screen actually is
Three things, and it is worth naming them separately because they fail separately:
- A universe — the set you are choosing from. Not "the market": a specific, listable set of instruments.
- Filters — the conditions that cut it down.
- An ordering — what comes first, which decides what you actually look at.
The endpoint that does this in one call is /screener. A single request with filters and a sort returns matching instruments with the fields you need to judge them. Unit 1 lesson 3 runs your first one.
The honest framing, stated once and meant
A screener finds instruments matching conditions you chose. That is all it does.
It does not know whether your conditions are sensible, whether the result is a good idea, or what happens next. A list of companies with low P/E is a list of companies with low P/E — some are bargains, some are cheap for excellent reasons, and the screen cannot tell you which. Nothing this course produces is investment advice, and a tool that implies otherwise is worse than no tool.
That is not a legal footnote bolted to the end. It changes what you build: it is why unit 4 makes you write down the reasoning behind a shortlist rather than just the shortlist.
Try it now
Open your watchlist repository and write the rebuild section of PLAN.md before reading on. Four headings — survives, generalises, new, dies — and put every file you already have under one of them. If a file is hard to place, that is the file worth discussing with your assistant first.