What You Built in This Module

A page that shows a prediction and a page that refuses to lie about one are different products, and the gap is entirely in the cases the demo never hits: the model down, the call still pending, the number a non-ML reader will misinterpret. What you can build now does not merely render a result — it shows one only when it has one, says so plainly when it does not, and frames it so the person on the other side draws the conclusion the number actually supports.

What you completed

A working dashboard came first; both lessons after it were about the page telling the truth when the easy path is gone:

• The result does not exist until the network call resolves. A render placed before the await shows undefined, not a number — the async timing bug that looks like a display problem and is actually an ordering one. Building the smallest real page that collects an input, calls the endpoint, and renders the response is what makes that timing visible instead of mysterious.
• The stale number is more dangerous than the blank one. A page that reads the body without checking response.ok parses a 503 error page into nothing, and worse, leaves the last good prediction sitting on screen looking fresh after the model has gone down. Routing failure to an explicit unavailable state that disables the action is what stops the page from presenting an answer the model never produced for this input.
• The threshold is a business decision the frontend owns, not a model property. A raw predict_proba score shown to someone who does not think in probabilities misleads more than it informs, and the yes-or-no cutoff that turns it into a decision belongs on the product side of the boundary, not buried in the model. Seeing why an API key in client JavaScript is already public is the same lesson about boundaries from the other direction — what the frontend owns, and what it must never hold.

Check your understanding

Work these without scrolling back up. Each one is a new product, not the loan example the lessons used — the point is to apply the judgment, not recall the case. Try to answer before opening the hint.

1. You are building a dashboard that shows a delivery-time estimate after a user enters an address. The page renders the estimate field but it always reads undefined instead of a number. Explain why this looks like a display bug but is actually an ordering one, and what the render is racing against.

   Hint

   The result does not exist until the network call resolves. Think about where the render sits relative to the `await`, and why placing it before the response arrives gives you nothing rather than a value.

2. The delivery-estimate service goes down and returns a 503, and the dashboard keeps showing the last estimate it received, looking current, while the page reads the error body as if it were data. Explain why a stale number on screen is more dangerous than a blank one, and the state you would route a failed call into instead.

   Hint

   A page that does not check whether the response succeeded parses an error page into nothing and leaves the old answer sitting there. Think about an explicit unavailable state that also disables the action, so the page never presents an answer the model did not produce for this input.

3. The delivery model outputs a probability that an order arrives late, and a designer wants to show that raw 0.34 directly to customers. Explain why the raw score misleads a non-technical reader, where the late-or-not-late cutoff belongs, and why an API key placed in the page’s JavaScript is already public.

   Hint

   A raw probability shown to someone who does not think in probabilities informs less than it misleads. Think about the threshold being a business decision the product owns rather than a model property, and the boundary lesson in reverse — what the frontend must never hold.

What it adds up to

Showing a number was the start, and making it a number someone can act on was the job. The page you can now build does not just display a prediction; it shows one only when it has one, says so plainly when it does not, and frames it so the person on the other side draws the right conclusion. That is the difference between a model behind an API and a product a non-ML colleague can actually use.

What comes next

The dashboard and the endpoint both run on your machine. Nothing outside your laptop can reach them yet. The next step is to make the system publicly usable: a stranger reaches it at a real URL, over TLS, with a deploy you can roll back and a cost you have bounded. The frontend and service you built here are exactly what gets deployed.