Why a notebook is not a system

What a notebook is

A notebook is a script with pretty output. It runs top to bottom in one process, on one machine, at one moment. It works because you are there — you fixed the last error, you have the environment set up, you know which cell to click first, and you close the browser tab when you’re done.

None of that is true for a system. A system runs when you are not watching. It runs from a request it did not choose. It runs when the API is slow, when the disk is full, when the model returned garbage. It runs at 2 AM in Butwal on a phone with weak signal. It runs when a user is unhappy and clicks the button again.

The notebook is a tool for exploring. The system is a tool for serving. The engineering between them is the substance of this course.

The seven things a notebook lacks

Whenever a “notebook goes to production,” seven things are required — usually skipped, and paid for later:

1. An interface. A user needs a way to send a request and get a response. HTTP is the boring, universal answer.
2. A process that stays running. Notebooks close; services keep listening.
3. A hosted environment. The code has to live on a computer that has power, internet, and Python — not your laptop.
4. Handling for concurrent requests. Two users at once cannot break the third.
5. Logging. Every interaction leaves a trace, so you can debug and improve.
6. Cost control. Every LLM call costs money; unbounded traffic can bankrupt a project overnight.
7. A way to change things safely. You will need to update prompts, models, and code — without breaking users.

Each of these is a section, chapter, or theme in this course. None of them is glamorous. All of them are the difference between a demo and a product.

A Nepal story

Two students in Kathmandu build a Nepali-language document Q&A bot in a Streamlit notebook. It works beautifully in the demo. They share the URL on Facebook. Within four hours:

• The Streamlit app crashes because the free hosting tier ran out of memory when 40 users tried it at once.
• The OpenAI bill hits Rs 3,000 for the first day — no one budgeted for load-testers.
• A user reports the bot said something inappropriate in Nepali. They have no logs, so they cannot investigate.
• The next morning, they push a fix. The fix breaks the bot for everyone who was using it. They have no rollback.

None of this is a code bug. All of it is the difference between “notebook that works” and “system that serves.” The team was neither incompetent nor unlucky — they simply hadn’t yet crossed the gap this course is about.

What a system looks like

Contrast the notebook with the shape of a real deployed AI system:

[ user ]
    │  HTTP request (question)
    ▼
[ load balancer ]
    │  routes to healthy instance
    ▼
[ your API server (running always) ]
    │  authenticate user
    │  check rate limit
    │  log request
    ▼
[ retrieval / preprocessing ]
    │  fetch documents, format prompt
    ▼
[ model call ]  ←──── retry on failure, fallback if slow
    │
    ▼
[ post-processing / validation ]
    │  check output is safe
    │  log response
    ▼
[ response ] ──→ [ user ]
    │
    ▼
[ metrics + traces + billing ] ──→ [ your dashboards ]

Every arrow is code you write or infrastructure you configure. Every box has failure modes you handle. Every layer has cost implications you monitor.

The notebook is one box in the middle. The system is everything around it.

Why “just deploy to Vercel” is not the answer

You may have heard that modern platforms make deployment trivial. Push code, and the site is live. This is true — but it only handles two of the seven things (an interface, a running process). The other five — hosted environment guarantees, concurrency, logging, cost control, safe change — are still yours.

Great platforms make the infrastructure easier. They do not make the engineering discipline optional. This course teaches the discipline, and you can apply it on whichever platform you prefer.

What you’ll learn in Course 05

Six chapters, each a piece of the gap:

• Chapter 1 (this one): From notebook to service. Wrapping a model, deploying it, running it somewhere real.
• Chapter 2: Cost, quotas, and rate limits. The economics of running LLMs, and how to not go broke.
• Chapter 3: Reliability and observability. Logs, metrics, and how to know your system is healthy.
• Chapter 4: Evaluation in production. Continuous testing, A/B, and feedback loops.
• Chapter 5: Versioning and rollouts. Changing things without breaking things.
• Chapter 6: Operating an AI product in Nepal. Trust, privacy, law, and the closing playbook.

At the end, you will have taken a notebook and produced a small, real service — running behind an API, deployable, monitored, and safe to change. That is a shipped AI system. That is where the Course 04 chatbots and RAG assistants become products.

The mindset shift

Before we build anything, one internal shift. Notebook thinking asks: does this code work? System thinking asks: what does this code do when I’m not looking?

For every function you write in this course, the honest question is:

• What happens when the input is empty?
• What happens when the API is down?
• What happens when the same request arrives 10,000 times in a minute?
• What happens when I need to change this next month?

These are boring questions. Every one of them is where products die when their builders skipped them.

Check your understanding

Quick check

—

A teammate says their AI project is 'ready to launch' — the notebook works, the model returns the right answer, and they've tested it on 20 example inputs. What is the most honest response?

1. AThat's ready — ship it.
2. BReady to demo, not ready to launch. A launched system needs an interface for users, a hosted process that stays running, handling for concurrent requests, logging of every interaction, cost control on model calls, and a way to change things safely. Each of these is real work between 'notebook works' and 'users can rely on this.' The honest response acknowledges the demo is good and lays out what remains before real users get access.
3. CWrite more tests.
4. DAdd a frontend.

Check answer→

Quick check

—

Which of these belongs in system-thinking, not notebook-thinking?

1. A'Does the model give the right answer for this input?'
2. B'What happens if this function is called 100 times a second, or on empty input, or when the API is slow?' System-thinking is about the code's behaviour when you are not watching — under load, at edge cases, across failure modes. Notebook-thinking assumes the happy path with the operator present. Both matter, but the shift from 'does this work?' to 'what does this do when I'm not looking?' is the fundamental change this course is teaching.
3. C'Is the notebook well-commented?'
4. D'Can I explain this to my teammate?'

Check answer→

What comes next

Section 1.2 is the first practical step: wrapping a model in a small API server so external requests can reach it. We’ll use FastAPI (Python’s standard modern choice) and build a minimal but honest example. It’s the smallest possible bridge from notebook to system — and it’s the foundation of everything to follow.