If you've never written a line of web code, this article is where you start. By the end, you'll understand what actually happens when you type google.com and hit enter -- and you'll have a clear roadmap for turning that knowledge into the ability to ship your own SaaS.
No marketing fluff. Just an honest mental model of the web, followed by the learning path we'll walk together across this series.
Why You Need a Mental Model First
Most people who try to learn web development fail for the same reason: they start memorising syntax before they understand what the syntax is for. They learn that fetch('/api/users') makes an HTTP request without ever understanding what "HTTP" or "request" actually mean. Then when something breaks -- and things always break -- they have no mental model to debug from.
This chapter is your mental model. Every line of code you write for the rest of this series will slot into the picture you build here.
The Whole Web in One Paragraph
When you visit a website, your browser asks a server somewhere on the internet to send back some files. The server usually consults a database first to figure out what to send (your profile, your feed, your cart). The files travel back to your browser as text -- HTML for structure, CSS for styling, JavaScript for interactivity -- and your browser renders them into the page you see. Every click, every scroll that loads new content, every form submission, every "like" button is the same loop happening again: your browser asks, a server answers.
That's it. That's the whole web. Everything else is detail.
The Five Actors: Browser, DNS, Server, Database, CDN
Before we walk through what happens when you press enter on a URL, let's meet the five main characters in every web story -- and see how they connect.
Figure 1 — The five actors in every web request. Solid arrows are requests, dashed arrows are responses.
1. The Browser (the client)
Chrome, Safari, Firefox, Edge -- these are all programs that know how to ask servers for files and render those files into a page. The browser lives on your computer or phone. In web development, we also call it "the client" because it's the thing requesting things.
2. DNS (the phonebook)
Computers on the internet talk to each other using numbers called IP addresses (like 142.250.80.46). Humans prefer names like google.com. DNS -- the Domain Name System -- is a worldwide phonebook that translates names into IP addresses. When your browser needs to reach simpleappshipper.com, it asks DNS: "what's the IP for this name?" and gets back a number it can actually connect to.
3. The Server (the kitchen)
A server is just another computer, usually sitting in a data centre, running a program that listens for incoming requests and sends back responses. Think of it like a restaurant kitchen: it doesn't decide what to cook -- it waits for orders, and when one comes in, it cooks and sends the dish back. "Server" is both the machine and the program running on it.
4. The Database (the fridge)
Most interesting websites don't just serve the same files to everyone. Twitter shows your feed, Gmail shows your inbox, Amazon shows your cart. That personalised data lives in a database -- a specialised program designed to store and retrieve structured information fast. When a server gets a request, it typically asks the database for the right data, then assembles the response.
5. The CDN (the local delivery depot)
The internet is physical. Data has to travel through fibre-optic cables under oceans. If the server is in Virginia and you're in Tokyo, the round trip takes time. A CDN (Content Delivery Network) solves this by copying your website's static files to hundreds of "edge" servers around the world, so users get files from the one closest to them. Cloudflare -- whose stack we'll use in this series -- is one of the biggest CDN providers on earth.
What Happens When You Type a URL
Let's trace a single request end-to-end. You're at a café. You open Chrome and type simpleappshipper.com and press Enter. Here's every message that flies between the actors, in order:
Figure 2 — A full HTTP request-response cycle, from pressing Enter to seeing pixels.
Every single website in the world -- Google, your bank, Instagram, this page -- follows this same loop. The only things that change are:
- What runs inside the Origin / Worker (could be PHP, Ruby, Python, Node.js, Go, or -- in our case -- a Cloudflare Worker).
- What comes back as the response (HTML, JSON, an image, a video).
- How much work the browser does after (a static site does almost nothing; a React app runs a full JavaScript engine).
HTTP: The Language Everything Speaks
Step 4 above said the browser sends GET / HTTP/1.1. That's HTTP -- the Hypertext Transfer Protocol -- and it's the single most important thing to understand on the web. Every interaction on every website uses HTTP. It's the shared language between browsers and servers.
An HTTP request has four essential parts:
GET /api/users/42 HTTP/1.1 ← method + path + version
Host: simpleappshipper.com ← which website (a server can host many)
Authorization: Bearer eyJhbGci… ← headers (metadata about the request)
Accept: application/json
(optional body — used by POST/PUT requests)
A response has the same shape:
HTTP/1.1 200 OK ← status code + message
Content-Type: application/json ← what kind of data is in the body
Cache-Control: max-age=60
{ "id": 42, "name": "William" } ← the body
The methods you'll use constantly
| Method | Meaning | When you use it |
|---|---|---|
| GET | "give me this" | Loading a page, reading data |
| POST | "create a new thing" | Signup form, uploading a file |
| PUT / PATCH | "update this thing" | Editing your profile |
| DELETE | "remove this thing" | Deleting a post |
The status codes you'll see daily
| Code | Meaning |
|---|---|
| 200 OK | Success |
| 301 / 302 | Redirect -- the thing is somewhere else |
| 400 Bad Request | Your request was malformed |
| 401 Unauthorized | You're not logged in |
| 403 Forbidden | Logged in but not allowed |
| 404 Not Found | That URL doesn't exist |
| 500 Internal Server Error | The server crashed |
Frontend vs. Backend vs. Full-Stack
You'll hear these three words constantly. Here's what they actually mean, and where each skill lives in the picture.
Figure 3 — Where frontend, backend, and full-stack work lives.
In 2026, "full-stack" is the default for indie developers and small startups, because one person needs to ship end-to-end. You're going to be full-stack.
The Stack We'll Teach (and Why)
There are dozens of possible stacks in 2026. For this series, we're teaching the exact stack used by the projects I actually ship -- so that by the end, you're not just a tutorial graduate, you're shipping the same tools I use in production.
Figure 4 — The three tiers of the stack we'll teach, in order of complexity. Each tier is optional — you can ship a full business on Tier 0 alone.
Why Cloudflare, not Vercel?
Most tutorials push Vercel. It's a great product. But its pricing scales quickly, and its search results are saturated with tutorials from Vercel's own employees. Cloudflare's free tier is absurdly generous (100,000 requests/day, free database, free storage), the global edge network is the fastest on earth, and the "Cloudflare SaaS" tutorial space is wide open. We'll own it together.
Why not skip straight to React?
Because React is built on top of HTML, CSS, and JavaScript. Every React component eventually becomes HTML. Every style eventually becomes CSS. Every interaction eventually becomes JavaScript. If you skip the foundation, you'll spend years copy-pasting code you don't understand. We'll learn the foundation first, then graduate to frameworks once you can explain what they're solving.
The Full Learning Roadmap
Here's the path from this article to shipping a real subscription SaaS on Cloudflare.
Figure 5 — The 25-chapter roadmap. The current chapter is highlighted in orange; the three 📖 "Project Study" chapters (6, 14, 23) open my actual shipped code and walk you through it line by line.
A few notes on the roadmap:
- Parts 1 and 2 alone are enough to ship a real Tier-0 + Tier-1 business. Many profitable indie apps never need Part 3.
- Part 3 is the modern React/Next.js layer. It's powerful but optional -- add it when you need real dashboards and user accounts.
- Part 4 is the capstone: one weekend, one subscription SaaS, no Apple in the loop.
Next Steps
You now have the mental model. You know what a browser, server, database, DNS, and CDN are. You understand HTTP. You know what "frontend" and "backend" mean. You've seen the full roadmap.
Here's what to do next:
- Install a code editor if you haven't -- Cursor or VS Code. Both are free.
- Open your browser's DevTools -- press
Cmd+Option+I/Ctrl+Shift+I. Poke around the Network and Elements tabs. Read requests on any site you visit. - Read the next chapter -- HTML Fundamentals. That's where you write your first real web page.
The best time to start learning web development was when the web launched in 1991. The second-best time is now.
Ship your apps faster
When you're ready to publish your Swift app to the App Store, Simple App Shipper handles metadata, screenshots, TestFlight, and submissions — all in one place.
Try Simple App Shipper