From Code to Cloud: How a Web App Gets Built and Deployed

This article exists because of a chain of steps.

Someone wrote text in a code editor on a laptop. They saved the file. They ran a command (git commit) that saved a snapshot of every changed file with a message describing what changed. They ran another command (git push) that sent that snapshot to GitHub — a website where the code lives online.

GitHub told Vercel that new code had arrived. Vercel pulled the code, ran a build (30–45 seconds), and distributed the output to its edge servers across the world. The next person who loaded this page got it from a server probably in their own country.

Total time from saving the file to the article being live: about two minutes.

The Tools in the Chain

Git is version control software — it tracks every change ever made to a codebase. Every edit, every save, every decision is recorded. You can go back to any previous state. Multiple developers can work simultaneously on branches and merge their work later. Git doesn't care about the internet; it works entirely on your local machine.

GitHub is where the code lives online. When you git push, you're sending your local commits to GitHub. GitHub stores every version of every file, lets other people view the code, review changes, and discuss decisions. It's also where CI/CD pipelines live — automated processes that run whenever new code arrives.

Vercel is the deployment platform. It watches GitHub; when new code is pushed to the main branch, Vercel automatically triggers a build and deploy. There's no button to press, no server to configure. Push the code, done.

These three tools are separate because they do separate things. Git tracks history. GitHub stores and shares. Vercel builds and serves. Confusing them is like confusing a pen (Git), a library (GitHub), and a printing press (Vercel).

What a Build Step Does

The source code of this app is not the code that runs in your browser. TypeScript doesn't run in browsers — it has to be compiled to JavaScript first. MDX files (Markdown with embedded React components) have to be parsed and converted to HTML. Tailwind CSS utility classes have to be processed into real CSS.

The build step does all of this transformation:

1. Type checking — verifies the TypeScript is correct, catches errors before they reach users
2. Compilation — converts TypeScript and JSX to browser-compatible JavaScript
3. Static generation — runs each page's code and saves the output as HTML files (so serving them later is instant — no computation required, just file serving)
4. Bundling and minification — combines JavaScript files, removes whitespace, shortens variable names — backgroundColor becomes a — making files 5–10× smaller
5. Image optimisation — resizes and compresses images for different screen sizes

The result is a /dist or .next folder full of files: HTML for each page, JavaScript bundles, CSS, images. These are what actually get served to users. A user never "runs" the source code — they receive the pre-compiled output.

CI/CD: The Automated Safety Net

Humans make mistakes. Without automated checks, a typo in source code could silently break every user's experience before anyone noticed.

CI/CD (Continuous Integration / Continuous Deployment) is a pipeline of automated checks that runs on every push:

1. Code pushed to GitHub
2. GitHub triggers the CI pipeline
3. Pipeline runs: type checking, tests, build verification
4. If anything fails: deployment is blocked, developer is notified with the error
5. If everything passes: Vercel is told to deploy

This means developers can push small changes frequently without fear. The pipeline catches errors immediately, in a controlled environment, before they reach users. Good CI/CD makes software development faster and safer simultaneously.

What "The Cloud" Actually Is

The cloud is a marketing term for rented server infrastructure. It is physical.

There are buildings — large ones, sometimes the size of several city blocks — filled with racks of servers, cooling equipment, generators, and redundant power supplies. These buildings are called data centres. A large one uses as much electricity as a small city.

Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure are the dominant providers. Between them they operate hundreds of data centres on every continent except Antarctica. When you store a photo in iCloud, it's on servers in an Apple-managed AWS data centre. When you stream a Netflix video, it's from AWS servers — Netflix runs almost entirely on AWS.

Vercel itself runs on AWS. When Vercel deploys Waypoint to its "edge network," it's pushing files to servers in AWS data centres around the world. Every layer of the cloud stack sits on another layer of the same few physical infrastructure providers.

The Journey of This Article

To make this concrete: here is the complete chain for the article you're reading.

1. Editor — Written in VS Code (a text editor) on a MacBook
2. Git commit — git commit -m "add code-to-cloud waypoint" saved the snapshot locally
3. Git push — git push origin main sent the commit to GitHub
4. GitHub → Vercel webhook — GitHub told Vercel new code had arrived
5. Vercel build — Vercel ran npm run build, which ran Next.js's build process: parsed the MDX, generated static HTML for this page, compiled all components to JavaScript, minified everything
6. Edge deployment — Vercel distributed the built files to edge servers in North America, Europe, Asia-Pacific, and other regions
7. Your request — You loaded this URL; your browser contacted the nearest Vercel edge server; the pre-rendered HTML arrived in ~50ms
8. Your browser — Rendered the HTML, requested the JavaScript bundles, made the page interactive

Each step in this chain is a piece of software built by different engineers, running on physical hardware that exists somewhere on Earth. The abstraction makes it feel like magic. But every layer has a physical address, consumes real electricity, and is maintained by real people.

The remarkable part isn't that it's invisible — it's that the invisible machinery is this reliable, and this fast.