How Modern Software Is Built (in 2026)

1.1 What a programming language is, and why there are so many 8 min Slides

A computer's processor understands only machine code: numbers that mean "add these two values," "copy this to memory," "jump to that instruction." Nobody writes that by hand. A programming language is a human-readable notation for those instructions, with a precise grammar (its syntax) so that a program can translate it into machine code without ambiguity. What a programmer writes is called source code.

Two translation strategies exist, and the difference will matter later in this session:

• A compiler translates the whole program ahead of time into an executable file. The result runs very fast, but the file is tied to one kind of processor and operating system. C, C++, Rust, Go, and Swift work this way.
• An interpreter reads the source code and carries it out on the spot, line by line. Nothing is built in advance; the same file runs wherever the interpreter is installed. Python, JavaScript, and Ruby work this way. (Java and C# sit in between and get their own explanation in Section 1.6.)

Why are there hundreds of languages instead of one? Because each was created to make a particular kind of work easier, at the cost of making other kinds harder. Some trade speed for ease of writing (Python). Some trade ease for total control of the hardware (C). Some exist because a company controls a platform and wants a language optimised for it (Swift for Apple, Kotlin for Android). Some are not meant for writing whole programs at all but for one specialised job (SQL for asking questions of a database). Choosing a language is choosing which trade-offs suit your product.

Three words that get mixed up, and a hierarchy to keep them straight:

• A language is the notation itself: Python.
• A library (also called a package or module) is a bundle of ready-made code in that language that does one job, which you call instead of writing yourself: a library for sending email, one for drawing charts.
• A framework is a large, opinionated set of libraries that provides the skeleton of a whole kind of application; you fill in the parts unique to your product. Flask and Django are web frameworks for Python; React is a front-end framework for JavaScript. Session 3 uses one.

1.2 Fit for purpose: what each language was designed to do 12 min Slides

The first question is the simplest: was this language built for the job? Languages divide into general-purpose languages, which can write almost any kind of program, and domain-specific languages, which are excellent at one narrow thing and useless outside it.

SQL is the clearest example of the second kind. It is superb at describing questions about tables ("all Boston customers who ordered rye twice last quarter") and it is the right tool for that everywhere it comes up. But it has no way to draw a button, listen for a click, send an email, or lay out a page. Nobody writes a website in SQL for the same reason nobody writes a novel in the notation of chess: the language simply cannot express the ideas. HTML and CSS are also domain-specific: they describe structure and appearance and are not, strictly, programming languages at all, since they cannot express logic such as "if the order is over 50 dollars, show the discount."

Among general-purpose languages the fit is softer but real. Each has a home turf where its design, its tooling, and its community are strongest, and using it elsewhere is possible but uphill. The table maps the languages you will hear about to what they are typically used for. A few terms in it (front end, back end, operating system, native, embedded) are explained properly in later sessions; each is highlighted and defined there, and the glossary in Appendix A links to every one.

Notice a pattern in the diagram: a modern product is never written in one language. A typical web product uses HTML, CSS, and JavaScript in the browser, Python or JavaScript on the server, and SQL in the database, with Swift and Kotlin if it has native apps. "Choosing a language" really means choosing the back-end language and, if relevant, the mobile strategy; the rest is dictated by where the code has to run.

1.3 Popularity, maturity, and community 10 min Slides

Two languages can be equally capable on paper and yet one is a far better business choice, because a language is not just a notation. It is a community of people using it, a body of documentation and answered questions, a supply of developers who can be hired, and a track record of being maintained. Together these are the language's maturity and popularity, and they matter for concrete reasons:

• Hiring. A product written in a popular language can be worked on by millions of developers; one written in an obscure language depends on a few thousand, who cost more and take longer to find. When the original developer leaves, this becomes urgent.
• Answers. Every problem a developer hits in a popular language has been hit before, written up, and solved somewhere public. In a niche language, they are on their own.
• Longevity. Software lasts longer than anyone plans. Systems written in COBOL in the 1970s still run banks and governments, and the language's small pool of programmers is now a well-known crisis. A language with a large base is far more likely to still be supported, patched, and running on new hardware in twenty years.
• Security. Popular languages and their libraries are inspected by many eyes, and flaws are found and fixed quickly. Obscure ones can carry unfixed problems for years.
• Tooling. Editors, debuggers, testing tools, hosting platforms, and cloud services all support the popular languages first and best.

Popularity is measured in several imperfect ways: surveys of developers, counts of questions asked online, job postings, and activity on GitHub. They disagree on details but agree on the picture: Python, JavaScript/TypeScript, Java, C#, C/C++, Go, and SQL are the mainstream, with Rust, Swift, and Kotlin strong in their niches. A business choosing from that set is choosing safely.

The other side of maturity is age. A very new language may be genuinely better designed than its predecessors and still be the wrong choice, because it has few libraries, changes in ways that break existing code, and has not yet shown it will survive. Most successful languages needed ten years to become safe bets. The cautious rule: let others be early adopters unless the new language solves a problem you actually have.

1.4 The ecosystem: packages and libraries 10 min Slides

No serious program is written from scratch. Sending an email, reading a spreadsheet, charging a credit card, resizing an image, talking to a database, drawing a chart: for any language worth using, someone has already written each of these and published it for free. A language's ecosystem is that collection of ready-made parts plus the tools for finding and installing them, and it is frequently the deciding factor between two otherwise similar languages.

The mechanics are worth knowing because they come up daily. Libraries are distributed through a package manager, which fetches them from a central registry and keeps track of which versions your project uses. Python has pip (and a newer, faster tool called uv) drawing from a registry called PyPI with over half a million packages. JavaScript has npm, with more than two million. When a developer says "we added a dependency," they mean the project now relies on someone else's package.

Almost all of these packages are open source: published freely for anyone to use, inspect, and improve. Open source is why a two-person startup can build on the same foundations as a bank. It is also a software supply chain. A package you depend on may itself depend on fifty others, each maintained by volunteers who may stop, and occasionally one is abandoned or, rarely, deliberately sabotaged. Mature ecosystems have tooling that flags known-vulnerable packages, which is one more reason maturity matters.

Ecosystem strength is uneven across domains, and this is where it steers language choice:

1.5 Speed and memory: when performance matters 10 min Slides

Languages differ enormously in how fast the programs written in them run and how much memory they use. Compiled languages such as C, C++, and Rust are typically ten to a hundred times faster than interpreted ones such as Python at raw computation, and use a fraction of the memory, because there is no interpreter in the way and the programmer controls exactly how data is laid out. Java, C#, and Go sit between the two.

The instinct is to want the fastest, and it is usually wrong. What matters is where the time actually goes:

• Most business applications wait, they do not compute. A web request spends its time waiting for the database, the network, and the disk. Whether the surrounding logic runs in one millisecond or ten is invisible next to a fifty-millisecond database query. Instagram, Dropbox, Spotify, and Reddit serve enormous audiences from Python and the like, because the architecture in Sessions 4 and 5 (caching, more servers) buys far more speed than a faster language would.
• Developer time costs more than machine time. A language that lets a team ship in a week instead of a month is worth more than one that saves a few servers, at almost any scale short of the very largest. Servers cost dollars; developers cost thousands.
• The slow language often calls the fast one. Python's data and AI libraries are Python on the outside and C or C++ on the inside. The heavy arithmetic runs at compiled speed; the developer writes the convenient language. This is why "Python is slow" and "Python runs the world's AI" are both true.

Performance genuinely decides the language in a minority of cases, and they are recognisable:

Memory footprint follows the same logic: it decides everything on a device with 256 kilobytes and almost nothing on a server with 64 gigabytes. The sensible sequence for most products is to build in the productive language, measure, and rewrite only the specific slow part in a faster one if measurement proves it necessary. Teams that guess in advance which part will be slow are usually wrong.

1.6 Platforms and portability 12 min Slides

A platform is the combination of processor and operating system a program runs on: Windows on an Intel laptop, macOS on an Apple chip, Linux on a cloud server, iOS on an iPhone, Android on a Samsung phone. Machine code for one is gibberish to another, for two independent reasons. The processor architecture differs (Intel and AMD chips speak x86; phones, Apple silicon Macs, and a growing share of servers speak ARM), and the operating system differs in how programs ask for files, windows, and the network. Getting the same software onto several platforms is a real cost, and languages handle it in three different ways.

1. Recompile for each platform. C and C++ programs are compiled straight to machine code, so a Windows build, a Mac build, and a Linux build are three separate products, each needing its own compilation and its own testing. When Apple moved Macs from Intel to its own ARM chips in 2020, every compiled Mac program had to be rebuilt, which is why some software ran slowly in an emulator for a year or two. Rust, Go, and Swift work the same way, though their tooling makes the rebuilds easier.
2. Compile once, run on a virtual machine. Java was designed in the 1990s around the slogan "write once, run anywhere." Java source is compiled to bytecode, a machine code for an imaginary computer, and a virtual machine (the JVM) installed on each real platform runs that imaginary computer. The same .class file runs unchanged on Windows, Mac, Linux, and, historically, on phones and smart cards. Kotlin, Scala, and Clojure share the JVM; C# and the other .NET languages use the equivalent .NET runtime. The price is the virtual machine itself: it must be installed, it uses memory, and it takes a moment to start.
3. Ship the source and interpret it. Python, JavaScript, and Ruby are never compiled by the developer at all. The same source file runs anywhere the interpreter is installed. JavaScript is the extreme case: the interpreter is built into every browser on earth, which makes the web the most portable platform that has ever existed. A web app needs no per-platform version, no app store, and no installer.

Mobile phones are the important special case. Apple and Google each built their platform around a preferred language and toolset: Swift (and its predecessor Objective-C) for iOS, Kotlin (and older Java) for Android. Both are compiled for the phone's processor, and the platform's own libraries, design conventions, and store tooling are built for them first. A company that wants the best possible app on both platforms therefore writes it twice. Cross-platform frameworks such as React Native (JavaScript) and Flutter (Dart) exist to avoid that: one codebase produces both apps, at some cost in performance and in fidelity to each platform's conventions. Session 5 returns to this trade-off in detail. For desktop software, Electron plays the same role, wrapping a web app so that Slack, VS Code, and Discord ship one codebase to Windows, Mac, and Linux.

The business reading of all this: every additional platform is an additional product to build, test, and support, and the language strategy determines how much of that work is duplicated. The web minimises it, virtual-machine languages nearly eliminate it for desktop and server software, compiled languages maximise it but run fastest, and native mobile doubles it on purpose in exchange for the best user experience.

1.7 Making the decision in the age of AI 8 min Slides

AI-assisted development changes who types the code but not which language the code should be in. Pulling the session together, here is how each factor shifts:

Three conclusions follow, and they are the ones to carry into the rest of the module:

1. Choose mainstream. For anything built with an AI assistant, prefer the languages with the largest bodies of public code: Python, JavaScript/TypeScript, SQL, and Java or C# where the enterprise requires them, with Swift and Kotlin for native mobile. This is where the assistant is most reliable and where a human reviewer can most easily find help.
2. Optimise for readability, not typing speed. When an AI writes most of the code, the human's job becomes reading it: reviewing, testing, and deciding. A language that is easy to read (Python was designed for exactly this) makes that job possible for a non-specialist. This is a real argument for Python as a first back-end language for people in this course.
3. The language is rarely the risk. Products fail far more often from unclear requirements, wrong data models, and missing security than from choosing Python over Go. Spend the decision-making effort on the architecture in Sessions 2 to 5, pick a sensible mainstream language, and move on.

2.1 Why architecture is a business topic 5 min Slides

When an architect designs a building, they decide where the load-bearing walls go, how people move between floors, and where the plumbing runs. Change those decisions after the concrete is poured and the cost is enormous. Software has the same property. Architecture is the set of big structural decisions about a piece of software: what its major parts are, what each part is responsible for, and how the parts talk to each other.

Three reasons a business student should care:

• Cost. Architecture decides whether you pay a few dollars a month or tens of thousands. It decides whether adding customers adds cost linearly or barely at all.
• Risk. Architecture decides what happens when a component fails, how a data breach could occur, and whether the product survives a viral moment or collapses under it.
• Speed. Architecture decides how fast a team (or you with an AI coding assistant) can add features without breaking what already works.

You will not be writing the load-bearing walls yourself in this course. But you will be talking to people and tools that do, and the person who cannot follow the conversation does not get a vote.

2.2 Clients, servers, and programs 10 min Slides

Almost every piece of modern software follows one pattern: one computer asks, another computer answers. The computer that asks is the client. The computer that answers is the server. Together this is the client–server model.

Two things students often get wrong about servers:

• A server is an ordinary computer. It has a processor, memory, and a disk exactly like a laptop. It usually has no screen or keyboard because nobody sits at it. It lives in a building full of other servers (a data center) with reliable power, cooling, and a fast internet connection. It runs 24 hours a day, waiting.
• "Server" also names a program. A web server is a program whose only job is to listen for requests and hand back web pages. The same physical computer can run several server programs at once. In conversation, "the server" means whichever of the two is obvious from context.

Everyday examples students already use, with the client and server identified:

The client for a website is nearly always a web browser: Chrome, Safari, Firefox, Edge. The browser is itself just a program installed on your computer. Its job is to request pages and turn what comes back into pictures and text on the screen.

2.3 A web page is three languages 15 min Slides

Here is a surprising fact: a web page is a plain text file. You can open it in Notepad. If you save a text file with the name index.html, type a few lines into it, and double-click it, your browser will display it as a web page. No internet connection, no server, no company involved.

The text inside that file is written in up to three languages, each with a separate job.

HTML: the content and its structure

HTML (HyperText Markup Language) says what is on the page: this is a heading, this is a paragraph, this is an image, this is a link to another page. It does this with tags, labels in angle brackets that wrap the content.

<!DOCTYPE html>
<html>
  <head>
    <title>Rosenthal's Bakery</title>
  </head>
  <body>
    <h1>Rosenthal's Bakery</h1>
    <p>Fresh bread every morning since 1998.</p>
    <img src="storefront.jpg" alt="Our shop">
    <a href="menu.html">See the menu</a>
  </body>
</html>

Read it aloud and it almost explains itself: <h1> is a top-level heading, <p> is a paragraph, <img> places an image stored in a file called storefront.jpg, and <a href=...> is a link (an "anchor") to another page called menu.html. HTML alone gives you a working but ugly page: black text on white, default fonts, no layout.

CSS: how it looks

CSS (Cascading Style Sheets) says what the page looks like: colors, fonts, spacing, how things are arranged, what happens on a phone screen versus a desktop monitor. A CSS rule names the thing it applies to and lists the properties to change.

h1 {
  color: #7a3e12;
  font-family: Georgia, serif;
}
p {
  font-size: 18px;
  line-height: 1.6;
}

This says: every top-level heading is a warm brown in the Georgia font; every paragraph uses 18-pixel text with comfortable line spacing. The same HTML file with a different CSS file can look like a completely different website. That separation is deliberate: content people write the HTML, design people write the CSS, and neither steps on the other.

JavaScript: what it does

JavaScript is a real programming language, the only one that browsers can run, and it makes the page do things: react when a button is clicked, check that an email address looks valid before a form is sent, show a dropdown menu, load more posts as you scroll. Without JavaScript a page is a document. With it, a page becomes an application.

const button = document.querySelector("#order-button");
button.addEventListener("click", function () {
  alert("Thanks! Your order is on its way.");
});

In words: find the element on the page whose id is order-button; when it is clicked, show a message. Students in a Python course will notice that this looks like a programming language because it is one. The syntax differs from Python (curly braces, semicolons) but the ideas are the same: variables, functions, conditions, loops.

The browser's act of turning those text files into pixels is called rendering. Every browser does it slightly differently, which is why the same site can look marginally different in Safari and Chrome.

2.4 The static website on your own computer 5 min Slides

A website made only of files like the ones above, files that are written once and sent to every visitor exactly as they are, is a static website. The word "static" means the content does not change depending on who is looking or when. A brochure site for a bakery, a personal portfolio, a documentation site, and a landing page are all naturally static.

The essential point for this session: a static website needs no server at all to work on your own computer. The browser reads the files straight off your disk. This is the zero-cost, zero-infrastructure starting point from which everything else in this module is built up.

Notice the limitation, though. Only you can see this page. Your friend across town cannot type anything into their browser that reaches a file on your desktop. To share it with the world, the files have to be placed on a server that is always on and reachable by address. That is the subject of the next section.

2.5 How the internet delivers a page 20 min Slides

Suppose the bakery's files are now sitting on a server somewhere. A customer types https://www.rosenthalsbakery.com/menu.html into their browser. In the roughly half a second before the page appears, a lot happens. We take it piece by piece.

The address: anatomy of a URL

The thing you type is a URL (Uniform Resource Locator). It has parts, and each part answers a different question.

• The domain name is the human-friendly name a business rents (typically 10 to 20 dollars a year from a registrar such as GoDaddy, Namecheap, or Cloudflare). Owning the domain is owning the brand's address on the internet. A subdomain such as www or shop is a named subdivision of the domain that its owner can create freely and point wherever they like.
• The path identifies a specific page or file on that server. For a static site the path is literally a file name. For dynamic sites (Session 3) the path is more like an instruction: /orders/1234 means "show me order number 1234".
• The query string passes extra details, like a language or a search term. When you search Google, the words you typed appear in the query string of the results URL.

Finding the server: IP addresses and DNS

Computers on the internet do not find each other by name. Every connected machine has an IP address, a number such as 142.250.72.14, and traffic is routed by number. Nobody wants to memorize numbers, so the internet has a distributed phone book called DNS (Domain Name System). When you type a domain, your browser first asks DNS "what is the IP address of www.rosenthalsbakery.com?" and gets back a number. Only then does it know where to send the request.

When a business buys a domain and then signs up with a hosting company, "pointing the domain at the host" means editing a DNS record so that the name resolves to the host's IP address. It is one of the few technical tasks a founder often does personally, and it is where the phrase "DNS changes can take up to 48 hours to propagate" comes from: the phone book is copied to thousands of servers worldwide and they refresh on a schedule.

The conversation: HTTP requests and responses

Now the browser knows the number. It opens a connection to that server and speaks a language called HTTP (HyperText Transfer Protocol). A protocol is simply an agreed set of rules for how two computers exchange messages, the way a business letter has a conventional layout. HTTP is refreshingly readable. The browser's request looks like this:

GET /menu.html HTTP/1.1
Host: www.rosenthalsbakery.com
User-Agent: Mozilla/5.0 (Macintosh) Chrome/128.0
Accept-Language: en-US

Read it as: "GET me the thing at /menu.html. I'm looking for the site called www.rosenthalsbakery.com. I'm Chrome on a Mac, and I prefer English." Each line after the first is a header: a labelled detail about the request. A request that sends data, such as a submitted form, also carries a body after the headers, which is where a submitted form or order travels. The server's response is equally readable:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 5120

<!DOCTYPE html>
<html> ... the actual page ...

The first line carries a status code, a three-digit summary of how things went. A handful are worth knowing because they show up in everyday life:

One page usually triggers many requests. The HTML arrives first; as the browser reads it, it discovers it also needs style.css, app.js, and storefront.jpg, and sends a separate request for each. A typical commercial home page today makes 50 to 150 requests. This is why "the number of requests" is a real performance metric and why the CDN in Session 4 matters.

HTTPS: the padlock

Plain HTTP sends everything as readable text, so anyone on the same coffee-shop Wi-Fi could read the pages you request and anything you type into them. HTTPS wraps the same conversation in encryption, so that only the browser and the server can read it. The padlock in the address bar means HTTPS is on. The server proves its identity with a certificate issued by a trusted authority; since 2015 these are free (from a non-profit called Let's Encrypt) and every serious hosting service turns them on automatically. There is no longer a business reason to run a site without HTTPS, and browsers actively warn visitors away from sites that do.

Getting the files onto a server: hosting

Hosting means renting space on someone else's always-on server and putting your files there. For a static website this is astonishingly cheap or free. Services such as GitHub Pages, Netlify, Vercel, and Cloudflare Pages will take a folder of HTML, CSS, and JavaScript and serve it to the whole world, including HTTPS and a domain of your choosing, for nothing or a few dollars a month. The workflow is: put the files in the service, point your domain's DNS at it, done.

Why is it so cheap? Because serving static files is the easiest job a computer can do. The server reads a file from disk and sends it. No thinking, no computation per visitor, nothing to remember. That simplicity is the reason static sites are fast, hard to hack, and almost impossible to overload. It is also the reason they are limited, which brings us to the next section.

2.6 Front end, back end, and the limits of static sites 10 min Slides

Two words you will hear in every conversation about software: front end and back end. The front end is everything that runs on the user's device and that they can see and touch: the HTML, CSS, and JavaScript we have been discussing. The back end is everything that runs on the server, out of sight: the code that decides what to send, checks who you are, records your order, charges your card.

A static website is front end only. That is precisely why it is cheap, and precisely why it cannot do certain things:

• It cannot remember anything. If a visitor fills in a form, there is nowhere for the data to go. The server just hands out files; it does not accept and store information.
• It cannot personalise. Every visitor gets the same menu.html. There is no "Welcome back, Dana" and no shopping cart that survives a page reload, because nothing on the server knows who Dana is.
• It cannot keep secrets. Everything in a static site is sent to the visitor's browser, so anything in it can be read by anyone. A password, a payment key, or a private price list cannot live in front-end code. This is one of the most important security rules in this module and it will return in Session 5.
• It cannot do work on your behalf. Sending a confirmation email, charging a credit card, or generating a PDF invoice all require a program running somewhere that is not the visitor's browser.

Every one of those needs is met by adding a back end: a program on the server that receives requests, runs logic, reads and writes stored data, and produces a response tailored to the visitor. A website with a back end is a dynamic website: its pages are generated at the moment they are requested, so they can be different for every person and every moment.

Most real products mix the two. The marketing pages of a company are static; the product behind the login button is dynamic. Knowing which parts of your product genuinely need a back end, and which can be static, is one of the first cost-saving architecture decisions a founder can make.

2.7 Where Python fits 5 min Slides

You are learning Python in parallel with this course, so it is worth saying exactly where it fits into the picture. The browser can run only JavaScript. Python does not run in the browser. Python runs on your computer when you run a script, and it runs on servers as back-end code. When a Python program on a server answers web requests, it is the "Program" box in the diagram above.

Python is one of the most popular back-end languages in the world, used at Instagram, Spotify, Netflix, Dropbox, and nearly every AI company. In Session 3 you will see a complete, working Python web server in about ten lines. The Python skills from your other course are directly the skills of writing back ends.

Session 1 covered how a back-end language is chosen; the table above shows the result of that choice for this module. A final piece of vocabulary. A developer who works on the front end is a front-end developer; one who works on the back end is a back-end developer; one who does both is a full-stack developer. "The stack" is the list of technologies a product uses, top to bottom: the front-end framework, the back-end language, the database, the hosting. When someone asks "what's your stack?", they are asking about your architecture.

3.1 Inside the back end: a Python web server 12 min Slides

Here is a complete dynamic web server written in Python, using a popular framework called Flask. It is short enough to read in full.

from flask import Flask
from datetime import datetime

app = Flask(__name__)

@app.route("/")
def home():
    return "<h1>Rosenthal's Bakery</h1><p>Fresh bread every morning.</p>"

@app.route("/hours")
def hours():
    now = datetime.now()
    if 7 <= now.hour < 18:
        return "<p>We are <b>open</b> right now!</p>"
    return "<p>We are closed. Back at 7 a.m.</p>"

app.run(port=5000)

Walk through it slowly with the class:

• app = Flask(__name__) creates the web server program. Flask is a framework (Session 1): a bundle of pre-written code that handles the routine parts of being a web server, so the developer only writes the parts unique to the bakery. Flask, Django, and FastAPI are Python frameworks; Express and Next.js are JavaScript ones; Rails is Ruby; Spring is Java. When Claude Code builds you a web app, it will pick one of these.
• Each @app.route("...") line is a route: it connects a path (the part of the URL after the domain) to a Python function. When a request for /hours arrives, the hours() function runs and whatever it returns is sent back as the response.
• The hours() function is where "dynamic" happens. It checks the current time and returns different HTML depending on the answer. Two visitors a minute apart at 5:59 p.m. and 6:00 p.m. see different pages. No static file could do that.
• app.run(port=5000) starts listening. A port is a numbered door on a computer. One machine can run many server programs, each behind a different door. Websites use port 443 (HTTPS) and 80 (HTTP) by convention, so you never type them; developers testing on their own machine use doors like 5000 or 3000, which is why you will see addresses like http://localhost:5000.

localhost means "this computer." When you run the program above and open http://localhost:5000/hours, your browser is the client, your own laptop is the server, and the request never leaves the machine. Every developer works this way before putting anything on the internet. Session 4 covers the jump from localhost to the world.

In practice, back ends do not build HTML by gluing strings together. They use templates: HTML files with blanks in them, such as Welcome back, {{ customer_name }}, which the program fills in for each request. Designers can edit the template without touching the Python, and the Python can change without touching the design. The idea to carry away is the same either way: the server runs code, and the code produces the page.

3.2 APIs and JSON: how programs talk to programs 15 min Slides

The Flask example returned HTML for a human to read. But increasingly the thing making the request is not a human's browser rendering a page. It is another program: JavaScript in the page asking for "just the data," a mobile app, a partner's system, or an AI assistant. For those callers, the server returns raw data instead of a designed page. The set of requests a server understands, and the shape of the answers it gives, is its API (Application Programming Interface).

A web API is reached over HTTP just like a page, but its endpoints (individual addresses) return data rather than HTML. Here is the bakery adding one:

@app.route("/api/products")
def list_products():
    return {
        "products": [
            {"id": 1, "name": "Sourdough loaf", "price": 7.50, "in_stock": True},
            {"id": 2, "name": "Rye bread",      "price": 6.00, "in_stock": False},
            {"id": 3, "name": "Challah",        "price": 8.00, "in_stock": True}
        ]
    }

A request to /api/products gets back this:

{
  "products": [
    {"id": 1, "name": "Sourdough loaf", "price": 7.5, "in_stock": true},
    {"id": 2, "name": "Rye bread", "price": 6.0, "in_stock": false},
    {"id": 3, "name": "Challah", "price": 8.0, "in_stock": true}
  ]
}

This format is JSON (JavaScript Object Notation, pronounced "Jason"). Curly braces hold a set of named values; square brackets hold a list; text is in quotes; numbers and true/false stand alone. Python students will recognise it: a JSON object is almost exactly a Python dictionary, and a JSON array is a Python list. Every programming language can read and write JSON, which is why it became the common tongue of the web.

Verbs: GET, POST, and friends

HTTP requests carry a method, a verb stating the kind of action. Static sites only ever needed GET ("give me this"). APIs use the full set:

An API organised this way, where every URL names a thing (a product, an order) and the method says what to do to it, is called REST (or "RESTful"). Almost every API you will encounter, from Stripe to Shopify to the Claude API, is roughly REST. The letters stand for something (Representational State Transfer) that nobody needs to remember; the idea is nouns in the URL, verbs in the method.

The four verbs map to the four things any system does with data, remembered by the acronym CRUD: Create, Read, Update, Delete. A surprising fraction of all business software is CRUD screens over a database: customers, invoices, tickets, inventory. Recognising a product as "mostly CRUD" is a useful signal that it is well understood and inexpensive to build.

Who calls APIs?

The right-hand side of this picture is where much of modern product-building happens. A third-party API lets you rent a capability instead of building it: charge a card with Stripe, send a text message with Twilio, look up an address with Google Maps, or generate text with the Claude API. Each is usually billed per use, which turns what used to be an engineering project into a line item. Much of "using AI to build products" is, architecturally, calling the right third-party APIs from your back end.

3.3 Why every product needs a database 10 min Slides

The /api/products example had its data typed directly into the program. That breaks the moment a real business touches it: the baker cannot edit Python to change a price, and an order placed by a customer has nowhere to be saved. The server needs somewhere to store data that survives restarts, can be changed by the program, and can be searched. That somewhere is a database.

Why not just save to a file, the way you might save a spreadsheet? Because a database solves problems a file cannot:

• Many writers at once. Two customers buying the last challah at the same instant must not both succeed. A database handles this; a file being edited by two programs simultaneously gets corrupted.
• Speed at scale. Finding one order among ten million by scanning a file takes minutes. A database with an index (like the index in a textbook) does it in milliseconds.
• Reliability. If the power fails halfway through saving an order, a database guarantees the order is either fully saved or not saved at all, never half. This property is called a transaction. Moving money between two bank accounts is the classic case: the debit and the credit must both happen or neither.
• Questions. "Which customers ordered rye more than three times last quarter?" is one line in a database language and a small programming project against a pile of files.

The database is a separate program, a database management system (DBMS). Your Python back end does not store data itself; it sends instructions to the DBMS and gets results back, much as the browser sends requests to the web server. In Session 4 we will see that the DBMS often runs on its own machine.

The relational model: tables

The dominant way to organise business data for the last fifty years is the relational model. Data lives in tables: each table holds one kind of thing, each row is one instance of that thing, and each column is one fact about it. The bakery needs at least these:

Two ideas make this work:

• Every row has a primary key, a column whose value is unique for that row and never changes: customer_id, product_id, order_id. Names are not good keys because two customers can share one and people change theirs.
• Instead of copying Dana's name and email into every order she places, the order stores only her customer_id. A column that holds the primary key of a row in another table is a foreign key. The orders table has two: customer_id and product_id. This is what "relational" refers to: tables related through keys.

The overall design of the tables, their columns, and the keys that link them is the schema. Designing a schema is really designing the business: what things exist, what we record about them, and how they relate. Business students are often better at this than engineers, because it is a question about the domain rather than about code.

3.4 SQL by example 15 min Slides

Relational databases are all controlled with one language, SQL (Structured Query Language, said "sequel" or "S-Q-L"). It was designed in the 1970s to be readable by business analysts, and it largely is. You are not expected to write SQL in this course; you are expected to recognise it, read simple statements, and know what it can do. Claude Code will write the SQL, but you will be reviewing what it writes and asking for the right things.

A request to a database is a query. Six examples cover most of what a business ever needs.

Reading: SELECT

SELECT name, email FROM customers WHERE city = 'Boston';

"Give me the name and email of every customer whose city is Boston." SELECT picks the columns, FROM picks the table, WHERE filters the rows. Result: Dana Levi and Priya Nair. Replace the column list with * to get every column.

Counting and summing: aggregate functions

SELECT status, COUNT(*) AS how_many
FROM orders
GROUP BY status;

"For each order status, how many orders are there?" Result: one row per status (placed 1, baking 1, ready 1). SUM, AVG, MIN, and MAX work the same way; together with COUNT they are called aggregate functions, because each combines many rows into a single number. Every management dashboard in the world is a stack of queries like this.

Combining tables: JOIN

SELECT customers.name, products.name, orders.quantity
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
JOIN products  ON orders.product_id  = products.product_id
WHERE orders.status = 'placed';

This is the query that makes the relational model pay off. The orders table has only ID numbers; a JOIN stitches each order to the matching customer row and product row using the keys, so the result reads like a human wants it to: "Dana Levi, Rye bread, 1." Whenever you see a report that combines information from several places, there is a JOIN behind it.

Writing: INSERT, UPDATE, DELETE

INSERT INTO orders (customer_id, product_id, quantity, status)
VALUES (3, 1, 2, 'placed');

UPDATE orders SET status = 'ready' WHERE order_id = 88;

DELETE FROM orders WHERE order_id = 89;

"Add an order: customer 3, product 1, quantity 2, status placed." "Change order 88's status to ready." "Remove order 89." The database assigns the new order its order_id automatically. Notice how much rides on the WHERE clause: DELETE FROM orders; with no WHERE deletes every order in the company. This is not a hypothetical. It is a well-known category of career-defining mistakes, and the reason production databases have backups and restricted permissions (Session 4).

Creating the structure: CREATE TABLE

CREATE TABLE orders (
    order_id     INTEGER PRIMARY KEY,
    customer_id  INTEGER REFERENCES customers(customer_id),
    product_id   INTEGER REFERENCES products(product_id),
    quantity     INTEGER NOT NULL,
    ordered_at   TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status       TEXT DEFAULT 'placed'
);

This defines the table itself: each column, its data type (whole number, timestamp, text), which column is the primary key, which columns are foreign keys (REFERENCES), and which are required (NOT NULL). The database will now refuse to save an order with no quantity, or one pointing at a customer who does not exist. Those constraints are business rules enforced by the storage layer, which is far more reliable than hoping every program remembers to check.

Which database? The names you will hear

All the relational ones speak SQL with minor dialect differences, so the concepts transfer. For a new product in 2026, "Postgres" is the safe default and the one you will hear most.

3.5 Beyond tables: NoSQL and ORMs 8 min Slides

NoSQL databases

Not all data fits neatly into fixed columns. A product catalogue where every product has different attributes (shoes have sizes, laptops have memory) fights the relational model. NoSQL databases relax the rules. The most common kind, a document database such as MongoDB, stores each record as a JSON-like document with whatever fields it needs:

{
  "product_id": 3,
  "name": "Challah",
  "price": 8.00,
  "tags": ["bread", "shabbat", "egg"],
  "sizes": {"small": 6.00, "large": 8.00}
}

Flexibility has a price: the database no longer enforces that every product has a price, and combining data across collections is clumsier than a JOIN. The choice between relational and NoSQL is a genuine architecture decision, but a simple rule of thumb serves most businesses: start relational. Business data (customers, orders, invoices, inventory) is naturally tabular and you will want the guarantees. Reach for NoSQL when you have a specific reason: extremely high write volume, genuinely irregular data, or a cache.

ORMs: letting Python speak to the database

Developers rarely type SQL into their programs directly. Most use an ORM (Object-Relational Mapper), a library that lets the program treat rows as ordinary Python objects and generates the SQL behind the scenes:

# Python with an ORM (SQLAlchemy):
boston = Customer.query.filter_by(city="Boston").all()

# ...which the ORM turns into SQL for you:
# SELECT * FROM customers WHERE city = 'Boston';

When Claude Code builds a back end for you, it will almost certainly use an ORM, and files called "models" describe the tables. The point for a business reader: the concepts (tables, keys, queries) are unchanged; the ORM is a convenience layer on top of them.

3.6 Putting it together: the three-tier architecture 10 min Slides

We now have three distinct kinds of component, and the standard name for arranging them is the three-tier architecture:

1. Presentation tier: the front end. HTML, CSS, and JavaScript in the browser (or the screens of a phone app). Shows things to people and collects their input.
2. Application tier (also called the logic tier or the back end): the server program. Receives requests, enforces business rules, decides what to do, talks to the database, and returns responses. This is where business logic lives: prices, discounts, permissions, validation, workflows.
3. Data tier: the database. Stores and retrieves the facts.

Follow one order through all three tiers. Dana clicks "Order 2 challahs":

Three observations that will matter for the rest of the module:

• The browser never talks to the database directly. All access goes through the back end, which checks identity and applies rules. If a browser could send SQL, anyone could run DELETE FROM orders. This is why the front end can never be trusted with secrets or with enforcing rules; anything in the browser can be changed by the person using it.
• Each tier can be changed independently. Redesign the front end without touching the database. Swap SQLite for PostgreSQL without changing the HTML. Rewrite the back end from Python to something else while the other two tiers carry on. This independence is the whole point of tiers.
• Each tier can be placed on different hardware. Today all three might run on one laptop. Tomorrow the database can move to its own machine and the back end can be copied onto ten. That is Session 4.

4.1 From localhost to production 10 min Slides

The bakery's back end works beautifully at http://localhost:5000. Moving it to a place where customers can reach it is called deployment. "Deploy" is one of the most frequently used verbs in a software team, and it means exactly this: take the code that works here and make it run there.

Serious teams do not deploy straight from a laptop to customers. Code passes through environments, each a full copy of the application with its own database:

"It works on my machine" is the oldest joke in software precisely because development and production differ: different operating system, different database size, different traffic, different secrets. Staging exists to catch those differences before a customer does. When a founder asks "can we just push it live?" the honest engineering answer is "only if you would be comfortable finding the bugs at the same moment your customers do."

Two measures describe how well a production system is doing. Uptime is the percentage of time it is reachable; each extra "nine" is dramatically more expensive to achieve. Latency is how long each request takes to answer. Much of the architecture in this session exists to push uptime up and latency down.

4.2 Step 1: everything on one server 10 min Slides

The simplest deployment is to rent one computer in a data center and install everything on it. Cloud companies rent these by the hour or month as virtual private servers (VPS) from providers such as DigitalOcean, Linode, Hetzner, or Amazon's EC2, for as little as 5 dollars a month. "Virtual" because one powerful physical machine is carved into several independent virtual ones, each of which feels to its renter like a whole computer.

On that one machine you install:

• An operating system, almost always Linux on servers. Linux is free, stable, and what nearly all server software is built for. Windows and macOS run desktops; iOS and Android run phones; Linux runs the internet.
• The web server program (Nginx is the usual choice), which accepts connections on ports 80 and 443, handles HTTPS, serves the static files itself, and forwards dynamic requests to the back end.
• Your back-end program (the Python/Flask app), listening on an internal port such as 5000.
• The database (PostgreSQL), listening on its own internal port, 5432 by convention.

Do not underestimate this setup. A modest 20-dollar server can comfortably handle tens of thousands of visits a day, which covers most small businesses and every early-stage prototype. Its weaknesses only appear with growth:

• Single point of failure. If the machine's disk dies, or the data center loses power, or you make a mistake while updating it, the website and the database disappear together. A single point of failure is the enemy of uptime.
• Resource contention. The database and the back end compete for the same memory and processor. A heavy report query can make the website slow for every visitor.
• Hard ceiling. When traffic outgrows the machine, the only option is a bigger machine, and machines do not get infinitely big.
• Security blast radius. If an attacker breaks into the web server, they are already sitting on the same machine as all the customer data.

Each of the following steps removes one of these weaknesses, and each adds cost and complexity. Good architecture means taking the next step when the problem is real, not before.

4.3 Step 2: give the database its own machine 10 min Slides

The first thing to move off the shared server is the database. It goes onto a second machine, a dedicated database server, and the back end connects to it over the network instead of talking to it on the same box.

Why this is worth the second bill:

• Right-sized hardware. Databases want lots of memory and fast disks; web servers want processor cores and network bandwidth. Separated, each can be bought for what it actually needs.
• Security. The database server gets a private network address only. There is no route from the internet to it. A firewall allows connections on port 5432 only from the web server. An attacker who compromises the web server still has another wall to get through, and no one can stumble across the customer records from outside.
• Independent failure and maintenance. The web server can be rebuilt, upgraded, or replaced without touching a byte of data. Backups of the database run without slowing the website.
• It unlocks the next step. With the data in one shared place, you can now run more than one copy of the web server, which is what Step 3 does.

In practice, almost nobody installs PostgreSQL on a rented machine themselves any more. Cloud providers offer a managed database, such as Amazon RDS, Google Cloud SQL, Supabase, or Neon: you click "create PostgreSQL," and they run the machine, take nightly backups, install security patches, and can switch to a standby copy automatically if the primary fails (called failover). You get a connection address and a bill, starting around 15 to 50 dollars a month. For nearly every business this is the correct choice; running your own database is expertise you do not want to have to hire.

4.4 Step 3: many web servers behind a load balancer 15 min Slides

The bakery is featured on a national morning show. Ten thousand people open the site in the same minute. The single web server, already the busiest machine, runs out of capacity and starts answering with 503 errors. There are two ways to add capacity, and their names are worth knowing because they come up in every scaling conversation.

• Vertical scaling ("scaling up"): replace the machine with a bigger one. Simple, no code changes. But the biggest machine money can buy is still finite, price grows faster than capacity, and there is still exactly one of it.
• Horizontal scaling ("scaling out"): keep the machines modest but run several identical copies of the web server. Twice the traffic, twice the servers. In principle there is no ceiling; this is how every large internet company works.

The load balancer

Several web servers create an immediate question: the domain name resolves to one IP address, so which server does a customer's request go to? The answer is a new component that sits in front of all of them, the load balancer. The public address belongs to the load balancer. It accepts every request and forwards each to one of the servers behind it, spreading the work evenly (round-robin, or to whichever is least busy). It also performs health checks: every few seconds it pings each server, and if one stops answering it simply stops sending it traffic. Customers never notice.

The catch: servers must be stateless

Horizontal scaling has one requirement that shapes how back ends are written. Consider a customer who logs in. Their first request goes to web server 1, which notes "this person is Dana, logged in." Their next click is routed by the load balancer to web server 2, which has never heard of them and asks them to log in again. The site appears broken.

The solution is that web servers must be stateless: they remember nothing between requests. Everything that needs remembering (who is logged in, what is in the shopping cart) is stored somewhere all the servers can reach: the database, or a fast shared store such as Redis. Any server can then handle any request, because the information travels with the request (in a cookie, as Session 5 explains) and the facts live in the shared store. Statelessness is what makes servers interchangeable, and interchangeable servers are what make it possible to add ten more during the morning show and remove them after lunch.

This step is also the one that turns "the server is down" from a disaster into a non-event. With two or more servers behind a load balancer, one can fail, be updated, or be replaced while the others carry on. Redundancy at every layer, including the database, is what the industry calls high availability, and it is how three and four nines of uptime are bought.

4.5 Step 4: caches, CDNs, and storage 10 min Slides

With the servers scaled, the next bottlenecks are usually the database and the distance between servers and customers. Three components address them.

Cache

A cache is a fast, temporary copy of something that was expensive to produce. The bakery's product list is requested thousands of times a minute and changes twice a day. Running the same SQL query thousands of times is wasteful; the back end runs it once, keeps the result in memory (typically in Redis, the same in-memory store used for sessions), and hands out the copy for the next 60 seconds. Database load drops by a thousand-fold. Caches appear everywhere: your browser caches images so it does not re-download them, servers cache query results, and the CDN below is a cache too. Their one hard problem is staleness: the copy can be out of date, so someone must decide how long a copy may live and when to throw it away.

Content delivery network

A customer in Singapore requesting an image from a server in Virginia waits for the bytes to cross the Pacific twice, about 200 milliseconds, before anything appears. A CDN (Content Delivery Network) is a company with servers in hundreds of cities that keeps copies of your static files (images, CSS, JavaScript, video) near your users. The Singaporean customer gets the image from Singapore in 10 milliseconds, and your own servers never see the request at all. Cloudflare, Akamai, Fastly, and Amazon CloudFront are the household names. Most of the bytes of most websites are served by a CDN, not by the site's own servers, and CDNs also absorb the flood of junk traffic in a denial-of-service attack.

Object storage

Customers upload photos; the bakery publishes menus as PDFs; the app records videos. Files like these should not live on a web server's disk, because with three web servers a file uploaded to server 1 is invisible to servers 2 and 3. They go into object storage, a cloud service designed to hold unlimited files at fractions of a cent per gigabyte and hand them out by URL. Amazon S3 is the original and the name people use generically; Google Cloud Storage, Azure Blob Storage, and Cloudflare R2 are equivalents. The database stores the address of the photo; the photo itself is in object storage, usually behind the CDN.

Read replicas

Finally, the database itself can be partially scaled. Most applications read far more than they write. A read replica is a continuously updated copy of the primary database that answers read-only queries (product lists, order history, reports) while all writes still go to the one primary. A replica also serves as a hot spare: if the primary fails, the replica is promoted and the site carries on. Splitting writes across several databases (called sharding) is the hard, expensive step that only very large companies take; it is beyond this course, but you should know the word.

This picture, or something very like it, is what runs behind most products you use. Naming its parts and explaining why each exists is the core competence this module aims for. Notice that nothing conceptually new was added after Session 3: it is still presentation, application, and data. Everything in this session was about copies, placement, and failure.

4.6 The cloud menu: IaaS, PaaS, SaaS, serverless 10 min Slides

Everything above can be rented rather than owned, and cloud computing is simply the name for that arrangement: someone else owns the data centers and you pay for what you use. Amazon Web Services (AWS), Microsoft Azure, and Google Cloud are the giants; there are many smaller, simpler providers. The real decision is not which brand but how much of the work you want to do yourself, and the industry describes that choice in layers.

Two more terms fill out the vocabulary. A container (made with a tool called Docker) packages a program with everything it needs so it runs identically on a developer's laptop and on any cloud, which largely cures "it works on my machine." Kubernetes is the system that runs and scales thousands of containers across many machines; it is powerful, complex, and almost never the right first choice for a small team. When people say "we containerised the app," they mean it is now portable across all the layers above.

For students in this course, the practical guidance is direct. A prototype built with Claude Code is best deployed on a PaaS (Render, Railway, Vercel, Fly.io) with a managed database (Supabase, Neon, or the PaaS's own). That gives you Steps 1 through 3 of this session, including HTTPS, load balancing, and horizontal scaling, for somewhere between 0 and 50 dollars a month, without ever logging into a server. Move down to IaaS only when you have a specific reason and someone to operate it.

4.7 Shipping code safely 5 min Slides

Three practices make it possible to change a live product without breaking it, and you will see all three in any team you work with.

• Version control. Every change to the code is recorded, with author and reason, and can be undone. The tool is Git; GitHub and GitLab host the shared copies. A repository ("repo") is one project's history. Claude Code works inside Git repositories and can commit changes for you; knowing that the history exists, and that anything can be rolled back, is what makes experimenting safe.
• CI/CD (Continuous Integration / Continuous Deployment). Automation that runs the automated tests every time code changes and, if they pass, deploys it. Instead of a risky quarterly release, teams ship small changes many times a day. On a PaaS this is often built in: connect your GitHub repo, and every change to the main branch goes live within minutes.
• Monitoring and logging. Servers write a line to a log for every request and every error; monitoring tools (Datadog, Sentry, Grafana) collect them, chart them, and page someone at 2 a.m. if the error rate jumps. A product without monitoring finds out about outages from angry customers.

5.1 Authentication versus authorization 8 min Slides

Two words that sound alike and are constantly confused, even by professionals. Keep them apart with two questions.

• Authentication answers "Who are you?" It is the act of proving identity: a password, a code from your phone, a fingerprint, or a login through Google. Shortened to "authn" or just "auth".
• Authorization answers "What are you allowed to do?" Once the system knows you are Dana, may Dana see order 90? May Dana see Sam's order 88? May Dana issue a refund? Shortened to "authz".

Authorization is usually organised through roles: customer, staff, manager, administrator. Rules are written per role ("staff may mark orders ready; only managers may refund") and users are assigned roles. Deciding the roles and rules of a product is a business question, not a technical one, and it is one you should expect to answer when you build something.

A rule of thumb that catches most authorization bugs in the wild: every request that touches a specific record must check that this user may touch this record. Systems that check "is the user logged in?" but forget "is this their order?" allow anyone to read anyone's data by changing the number in the URL. This exact flaw has produced many of the largest data leaks of the last decade.

5.2 Passwords done right 8 min Slides

The oldest authentication method is a shared secret: the user and the server both know the password. The obvious design, storing each user's password in the database next to their email, is also the most dangerous thing a product can do. If the database is ever stolen (and databases are stolen constantly), every password is exposed, and since people reuse passwords, so are their bank and email accounts.

The correct design stores a hash of the password instead. A hash function turns any input into a fixed-length scramble in a way that cannot be reversed. correct-horse-battery might hash to $2b$12$K9xT…. To check a login, the server hashes what the user typed and compares the two scrambles. The server never needs the original password, and a thief who steals the database gets scrambles they cannot turn back into passwords. (Details you may hear: passwords are "salted," meaning a random value is mixed in so identical passwords do not produce identical hashes, and slow algorithms such as bcrypt or argon2 are used so that guessing billions of passwords takes years.)

The lesson for a product owner is simple and non-negotiable: if a system can email you your old password, it is storing passwords wrongly. A correctly built system can only reset a password, never reveal it.

Passwords alone are weak because people choose bad ones and reuse them. Multi-factor authentication (MFA, or two-factor, 2FA) adds a second, independent proof: something you have (a code from an authenticator app or a hardware key) or something you are (a fingerprint or face) on top of something you know (the password). A stolen password alone then no longer opens the account. Every serious product should offer it, and every business should require it for staff accounts. Newer passkeys go further and replace passwords with a cryptographic key stored on your device, unlocked by fingerprint or face; they are becoming the default on major platforms.

5.3 Staying logged in: cookies, sessions, and tokens 10 min Slides

Session 4 established that HTTP is stateless: each request arrives with no memory of the last. Yet you log in once and stay logged in for weeks. How does the server recognise you on the second request?

The mechanism is the cookie. When you log in successfully, the server's response includes an instruction: "browser, please store this piece of text and send it back to me with every future request." The browser obeys automatically. The text is usually a session ID: a long random string that means nothing by itself but which the server has recorded in its session store (the Redis box in Session 4) alongside "this is Dana, logged in at 8:14, expires in 14 days." Each request carries the cookie; the server looks up the ID; now it knows who is asking. Log out, and the server deletes the record so the ID becomes worthless.

Three consequences worth drawing out:

• The cookie is as good as the password while it lasts. Anyone who copies the session cookie can act as Dana until it expires. This is why cookies are marked to be sent only over HTTPS and never be readable by JavaScript, and why sensitive actions (changing the password, paying) often ask for the password again.
• This is how any web server in a load-balanced pool can serve Dana. The identity travels with the request; the facts live in the shared store. Stateless servers, from Session 4, depend on exactly this.
• Cookies are also how advertising tracks people. The same mechanism that remembers your login lets a third-party advertising server recognise your browser across every site that shows its ads. Cookie-consent banners and privacy laws exist because of that second use, not the first.

Mobile apps and APIs often use a variant: instead of a random ID that the server looks up, the server issues a token: a signed piece of text that itself says "Dana, valid until Friday" and cannot be forged because it carries a digital signature only the server could produce. The most common format is the JSON Web Token (JWT, said "jot"). The client sends the token in an Authorization header rather than a cookie. The concept is identical: prove who you are once, receive a credential, present the credential thereafter.

5.4 HTTP Basic Authentication and API keys 7 min Slides

Before cookies and tokens there was the simplest possible scheme, built into HTTP itself and still in use: HTTP Basic Authentication. When a server requires it, the browser pops up its own plain grey username/password box (you have probably seen one on a router or a staging site). The browser then attaches the credentials to every request:

GET /admin/reports HTTP/1.1
Host: www.rosenthalsbakery.com
Authorization: Basic ZGFuYTpjb3JyZWN0LWhvcnNl

That jumble after Basic is not encryption. It is Base64 encoding of the text dana:correct-horse, and anyone can decode it in a second. Basic Auth therefore has two rules and two uses:

A close cousin is the API key, which we met in Session 3. It is a long random secret issued by a service provider that your back end presents with each call so the provider knows whose account to bill and what it may do. Keys are passwords for programs, and they must be treated as such: stored in server configuration (as environment variables, conventionally kept in a file called .env), never typed into front-end code, and never committed into a Git repository. Automated bots scan GitHub around the clock for accidentally published keys and can spend thousands of dollars of someone's cloud budget within minutes. When you use Claude Code with the Claude API or any other service, this is the single most important habit to build.

5.5 OAuth: how "Sign in with Google" works 15 min Slides

Two problems appear the moment products start working together. First, a new app wants to let users sign up without inventing yet another password, so it offers "Sign in with Google" or "Continue with Apple." Second, an app wants to use another service on the user's behalf: a scheduling tool that reads your Google Calendar, an accounting app that pulls transactions from your bank, a Claude integration that reads your Notion pages. The naive solution to both, asking the user to type their Google password into the new app, is catastrophic: the app would then hold a password that opens everything, forever, and the user could revoke it only by changing the password everywhere.

OAuth 2.0 solves both problems with one idea: the user never gives the app their password. Instead, the user is sent to the service they already trust (Google), approves a specific, limited request there, and the trusted service hands the app a special-purpose key.

The four parties

OAuth conversations always involve four roles. Learning their names makes every OAuth diagram readable.

The authorization-code flow, step by step

Walk the class through it slowly; it is the most intricate diagram in the module and worth the time.

1. Steps 1–3. The bakery's app does not show a password box. It sends Dana's browser to Google, telling Google which app is asking (a public client ID the bakery registered with Google beforehand) and what it wants (the scopes: here just email and name).
2. Step 4. Dana logs in at Google, with Google's password box and Google's MFA. The bakery sees none of it. Google shows a consent screen listing exactly the scopes requested. Dana can refuse.
3. Steps 5–6. Google sends the browser back to a pre-registered address at the bakery with a one-time authorization code. The code is deliberately useless on its own: it expires in a minute and can be redeemed only by the party holding the matching secret.
4. Steps 7–8. The bakery's back end, in a direct server-to-server call the browser never sees, presents the code together with its client secret (a password that only the bakery's server and Google know). Google returns the access token, valid for about an hour, plus a longer-lived refresh token for obtaining new ones, plus an ID token describing who Dana is.
5. Steps 9–10. The bakery uses the access token to ask Google for Dana's email and name, matches or creates her account, and issues its own ordinary session cookie. From here on, Session 5.3 applies.

Why the roundabout design? Because of what it protects against. Dana's password is never disclosed to the bakery. The token can do only what the scopes allow, so even a badly behaved app cannot read her email if it asked only for her name. Dana can see every app she has authorised in her Google account settings and revoke any of them with one click, instantly, without changing her password. And the access token expires quickly, so a stolen one has a short life. Compare each of those properties with the "type your Google password into our app" alternative and the value of the standard becomes obvious.

Login versus access: OpenID Connect

Strictly, OAuth is about authorization: granting an app access to resources. Using it for login (proving who the user is) was such a common desire that a thin standard was added on top: OpenID Connect (OIDC). It defines the ID token in step 8 and what it must contain. Every "Sign in with Google / Apple / Microsoft / GitHub" button is OIDC over OAuth. When a vendor says they support single sign-on (SSO), they mean a company's employees can log into the vendor's product with the company's central identity provider (Google Workspace, Microsoft Entra, Okta) using OIDC or its older enterprise cousin, SAML. For a business selling software to other businesses, supporting SSO is often a condition of the sale.

5.6 Security basics every product owner should know 7 min Slides

You do not need to be a security engineer, but a handful of ideas will let you ask the right questions and recognise the most common mistakes, several of which have already appeared in this module.

• Encrypt in transit and at rest. HTTPS everywhere (in transit); encrypted disks and database volumes (at rest). Every cloud provider offers the latter as a checkbox. Turn it on.
• Never trust the front end. Anything in the browser or the app can be read and altered by the user. Prices, discounts, permissions, and secrets belong on the server. This was the lesson of the three-tier diagram in Session 3.
• Watch for injection. The most famous web vulnerability, SQL injection, happens when text a user types is pasted straight into a SQL query. If a login form builds SELECT * FROM users WHERE name = ' + whatever was typed + ', then typing ' OR 1=1 -- makes the query true for every user. The fix (parameterised queries, where user input is passed to the database separately from the SQL) is automatic in every modern framework and ORM, which is one reason to use them. A cousin, cross-site scripting (XSS), does the same trick with HTML and JavaScript. The general rule: user input is data, never code.
• Least privilege. Every person, program, and API key gets the minimum access it needs. The web server's database account should not be able to drop tables. An intern should not be an administrator. A leaked key that can only read is a nuisance; one that can do everything is a disaster.
• Keep secrets out of code. Passwords, API keys, and client secrets go in environment configuration, never in source files and never in Git. Rotate any secret that has ever been exposed.
• Keep software updated and take backups. Most breaches exploit known holes in unpatched software. Managed services (PaaS, managed databases) patch for you, which is a security argument for them, not only a convenience one. And test that backups actually restore; an untested backup is a hope, not a plan.

The industry maintains a list of the ten most common web application risks, published by an organisation called OWASP. You do not need to memorise it, but "have we reviewed against the OWASP Top Ten?" is a question that any engineer or AI coding assistant can act on, and asking it marks you as someone who knows what matters.

5.7 Beyond the browser: mobile, desktop, embedded 10 min Slides

Everything so far has assumed the client is a browser. Most software you use is not a website, and yet almost all of it is built from the same parts. The distinction that matters is where the front end runs; the back end and the database are the same story.

This picture explains several things business people encounter:

• Why "we need an app" is a smaller decision than it sounds. If the back end and API already exist, a mobile app is a new front end, not a new system. If they do not exist, the app project is secretly also a back-end project.
• Why companies start with the web. A web app has no store review, no commission, instant updates, and one codebase. Native apps are added when the product needs the camera, notifications, offline use, or a home-screen presence.
• Why the API is the product's most durable asset. Front ends are rewritten every few years as fashions and devices change; a well-designed API and its database outlive several generations of them.
• Why embedded devices are the exception. A thermostat's software, its firmware, must still work in 2036 if the device was sold in 2026, may never be updated, and can physically harm someone if it fails. The engineering culture is correspondingly conservative, and the cost of a mistake is a recall rather than a redeploy.

5.8 Where AI fits 5 min Slides

Since this course is about building products with AI, the last question is where a model such as Claude sits in everything above. The answer is reassuringly familiar: an AI model is a third-party API called from your back end. It is the Claude API box that has been sitting at the edge of the diagrams since Session 3.

Three practical consequences:

• The key stays on the server. A model call from the browser would expose your API key to every visitor, who could run up your bill. All the reasoning of Section 5.4 applies.
• Your data is the differentiator. The model is the same one your competitors can rent. What makes an AI feature yours is the context your back end adds from your database (this customer's history, your product catalogue, your policies) before calling the model. That pattern, fetching relevant data and putting it in the prompt, is what people mean by retrieval-augmented generation (RAG).
• AI calls have cost, latency, and failure modes. A model call takes seconds and costs money per token (here a token is a fragment of a word, nothing to do with the login tokens of Section 5.3), so it is treated like any slow, paid third-party API: cached where possible, monitored, and given a fallback. When Claude Code builds an AI feature for you, these are the questions to ask it.

Step back and look at the whole module. A model such as Claude, the tool you are learning to build with, is itself served through exactly the architecture described here: a front end (the Claude app, or Claude Code in your terminal), load-balanced back ends behind an API, databases, caches, OAuth login, and an API key for programs. The next time you use it, you will know what is on the other end of the request.