The wall — where your tool stops being enough
You have a working watchlist with honest labels. This lesson finds the exact point where it cannot do what you want, on your own data, with your own numbers. Not a marketing panel: an experiment with a result you write down.
Measure your own cost per view
You have the meter. Use it as an instrument.
Note apiRequests from /user, reload your watchlist once, note it again. The difference is your cost per page view — one per instrument on the list, since /real-time is billed per symbol whether you batch the request or not. Measured on the account this course was written against, ten consecutive /user reads left the counter unmoved, so the meter itself is free and does not distort the reading; check that on yours rather than taking it from here, because it is exactly the kind of thing that differs by plan.
Then work out what your allowance actually buys:
views per day = daily limit ÷ cost per view
Do that arithmetic with your real numbers, right now, before reading on. It is the single most useful figure in this course, and it is different for everyone.
Then work out what you actually want
Ask honestly, not aspirationally. A realistic morning routine might be: open it at 7am, again at the open, then every half hour while the market is active. That is roughly fifteen views. Fifteen views is nothing.
Now ask for what you wanted when you started building: a page that refreshes itself every minute while it is open, so glancing at the tab is enough. Six and a half hours of trading, once a minute, is around 390 refreshes, times your cost per view.
Compare the two against your allowance. For most free plans the first fits comfortably and the second does not fit at all.
That gap is the wall. It is not "you have run out of calls". It is a specific thing you wanted your tool to do, that it cannot: keep itself current while you are not looking.
The other wall, and the more interesting one
Freshness. Go back to the age you measured in the last lesson.
If your data is delayed by fifteen minutes, then the threshold rules from unit 3 fire fifteen minutes late, always. For a rule that says "tell me if this drops 3%", fifteen minutes is the difference between information and history. You cannot fix this with more calls, and no amount of clever caching helps: the number does not exist yet at your tier.
This is the cleanest possible statement of what a subscription buys, and it is not quota. It is the difference between a tool that reports and a tool that alerts.
Write down your own numbers
Three lines in your PLAN.md, filled in with what you measured:
Cost per view: ___ calls
Views my allowance buys: ___ per day
My data age: ___ minutes
What I cannot build: _________________
That last line is the honest output of this course. For most people it reads something like "an alert I can act on" or "a page I can leave open".
What upgrading changes, stated precisely
Nothing about your code. Your proxy, your list, your notes, your rules, your deployment: all unchanged. The same tool starts receiving fresher data and more of it, and the features you deferred become buildable.
That is the whole proposition and it deserves to be stated without decoration. You built the tool. The subscription is what keeps it current. Live pricing is on the EODHD pricing page — this lesson deliberately quotes no figures, because a number written into a lesson is a number that goes stale and lies to the next reader.
And if your measured routine fits inside the free allowance, then it fits, and you should not pay for anything. A course that told you otherwise would be an advertisement, and you would be right to stop trusting the rest of it.
Try it now
Fill in the four lines above with your own measured numbers, and put them in your PLAN.md next to the definition of done you wrote in unit 1. Then answer one question in a sentence: which specific thing you wanted, on the day you wrote that plan, does your tool still not do? That sentence is the most valuable thing you will produce in this course.