What this covers

Your site is live but you cannot explain the path from your keyboard to someone's browser. This step builds the mental model that connects every piece.

What I did

Footybeat was live. The splash page worked. Push-to-deploy worked. But if someone had asked me to draw the path from editing a file on my laptop to that file appearing on footybeat.com, I could not have done it. I knew the pieces. I did not know the chain.

So I traced it. I opened a file, changed one word, and watched what happened at each stage.

The chain has five links. The local folder is where I edit files. Git tracks those changes and creates a snapshot called a commit. GitHub receives the commit when I push, storing the code online where other services can access it. Vercel watches the GitHub repo, and every time a new commit arrives, it pulls the code and builds the site. The build output goes to Vercel's servers, and DNS points footybeat.com to those servers.

Local folder. Git. GitHub. Vercel. Live site. Five boxes, four arrows. I drew it on a napkin and kept it next to my keyboard for a week.

The confusion I had to sort out was the difference between GitHub and Vercel. I had been treating them as roughly the same thing, two websites that "did something with my code." They are not the same thing at all. GitHub is a warehouse. It stores your code and keeps a history of every version. It does not run anything, build anything, or serve anything to visitors. Vercel is the storefront. It takes what is in the warehouse, builds it into a finished product, and puts it on the shelf where customers can see it.

The build step is the part I had been ignoring entirely. Source code is written for humans. Browsers need something different. When Vercel builds the project, it transforms the source code into optimized HTML, CSS, and JavaScript that loads fast in a browser. This is where most errors happen, because something that looks fine in your editor can break during the build. Knowing the build step exists means knowing where to look when something goes wrong.

One word changed in a file on my laptop. Five links later, the word appeared on the live site. That is the whole thing.

Skip the mistakes

Draw the chain once. Literally draw it. Five boxes on a piece of paper with arrows between them. Local folder, Git, GitHub, Vercel, live site. Keep it visible. When something breaks, this drawing tells you which link to check first.

GitHub is not deployment. Vercel is not storage. This distinction matters every time something goes wrong. If the code on GitHub looks right but the live site is broken, the problem is in the build step on Vercel. If the live site is fine but GitHub shows old code, you forgot to push. Knowing which service does what turns a confusing failure into a specific question.

The build step is where errors happen. When you push code and the site does not update, check the Vercel build logs before you check anything else. The build is the translation from your source code to what the browser receives, and it is the step most likely to fail. Vercel shows you the error in the dashboard. Learn to read that screen early.

Every change goes through all five links. There are no shortcuts. You cannot edit something on Vercel directly. You cannot push to GitHub and skip the build. The chain is the chain. Understanding that it is always the same five steps, in the same order, makes the whole system predictable.

What's next

The model makes sense on a napkin, but the terminal keeps asking me to run commands I do not understand.