Why won't localhost:3000 open on a friend's computer?
localhost is a specially reserved domain name with exactly one meaning: "this very computer." Its actual IP address is 127.0.0.1, but typing that every time is tedious, so the whole world agreed on a single name for it. When your friend types localhost:3000 into their own browser, it simply points to port 3000 on their machine. There is no server, no domain, no DNS, no HTTPS yet — and filling that gap is the entire process called deployment.
Why was deployment such a hard problem?
In the early days, deployment meant copying files over FTP. It looks simple, but accidents never stopped: miss a single file and the site keeps running half-updated; two teammates upload to the same server and overwrite each other's work; your machine runs Node 18 while the server runs 14, so "it worked on my computer" repeats endlessly.
Each of the three problems found its own solution. The lack of history was solved in 2005 by Git with commits and branches. Environment mismatch was solved in 2013 by Docker, which packs code and its runtime environment into one box like a meal kit. Errors caused by human hands went to CI/CD: one push sends tests, build, and deploy flowing automatically down a pipeline. That is how the era of hundreds of deploys a day began.
How did Nginx become the standard web server?
At one point Apache powered over 70% of the world's web servers. But Apache created one process per visitor — ten thousand concurrent connections meant ten thousand processes, and memory could not hold. This was the C10K problem. Nginx, built in 2004 by Russian developer Igor Sysoev, broke through it head-on with an event-driven architecture in which a small number of processes take turns handling vast numbers of requests; today it holds the top market share. It also doubles as a reverse proxy — a hospital information desk — serving static files itself and handing requests that need code execution to the WAS behind it.
What does Vercel do for you, and what does it take away?
Renting a server, installing Nginx, configuring Docker, building a CI/CD pipeline, issuing SSL certificates — doing it all yourself takes days. Vercel replaces all of it with connecting a GitHub repository. Every push triggers an automatic redeploy, and attaching a custom domain applies HTTPS automatically.
The price is control. The more convenient the platform, the harder it is to touch fine-grained server settings. That is why the common path is to start prototypes on Vercel or Railway and, once requirements grow complex, move to AWS, where almost every setting is available.
Why should a non-developer know this map?
You can use all of this without understanding it. But if you understand it, you can sense which stage broke when something fails. The person who tells AI "deploy this" and the person who asks "I think the environment variable isn't being recognized at the build stage" or "I'm connecting my registrar's domain to Vercel — how should the CNAME be set?" inevitably end up with different results. In non-developer vibe coding, skill divides along the specificity of these questions. That is why SH Consulting's AX training gives deployment as much weight as writing code.