Tech & AI, Explained

first-webapp

19 min read

Reading path: I want to build my first webapp

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: The complete journey from “I have an idea” to “anyone can use it at my domain” — explained in the order things actually need to make sense.

What this is

A curated trail through the encyclopedia. If you read these entries in this order, by the end you’ll understand the whole pipeline of how a modern webapp gets built and shipped, and you’ll be able to explain it to others.

This path mirrors the journey you (George) actually took building St Mark’s Bible Quest. It’s organized by the natural sequence in which concepts become necessary, not by section number.

There are 30 stops on this path. Don’t try to read them all at once. A reasonable pace is 2–4 entries per sitting, with breaks to play with code or just let it settle.

How to use this path

Each numbered stop has:

  • 🎯 Why you’re here — what problem this stop solves in your journey
  • 📖 Read — the entries to read (with status badges)
  • 🧠 Anchor concept — the single most important takeaway

The status badges (🟥/🟨/🟩/🟦) show how polished each linked entry is. If a link goes to a 🟥 STUB, the entry is planned but not yet written — feel free to ask Claude to expand it next session.

Stage 1 — The mental map (4 stops)

You can’t reason about a webapp until you have the right mental model of what one is. Skipping this stage is the #1 reason later concepts feel like magic.

1. What even is the web?

🎯 Why you’re here: Before learning to build for the web, understand what the web actually is — a particular set of agreements between computers that lets them share documents.

📖 Read:

🧠 Anchor concept: Your browser talks to a server. The server sends back an HTML document. That’s it. Everything else is layers on top of that one transaction.

2. Client vs server — the most important split in all of web dev

🎯 Why you’re here: Almost every confusion in web development traces back to losing track of which side of this line code runs on. Lock this in now.

📖 Read:

🧠 Anchor concept: The client (the browser) is the side that asks. The server is the side that answers. Code that runs on the server can hold secrets and see the database. Code that runs on the client can see what the user is doing. They are completely different worlds — and modern frameworks like Next.js try to blur the line, which is powerful but the line still matters underneath.

3. The terminal — your steering wheel

🎯 Why you’re here: Almost every tool you’ll use is operated by typing commands into a terminal. Five minutes of “what does this even do?” pays back ten thousand times over.

📖 Read:

🧠 Anchor concept: A terminal is just a text box that runs programs. The program you type into is the terminal (e.g. Windows Terminal). The language it understands is the shell (PowerShell on Windows, Bash on Mac/Linux). When a tutorial says “run this command,” they almost always mean “type this in the terminal and press Enter.”

4. Your tools

🎯 Why you’re here: You’ll need an editor (where the code lives), a runtime (where JavaScript runs outside the browser), and a package manager (where you download libraries from). All three are free.

📖 Read:

🧠 Anchor concept: Modern dev environments are surprisingly thin. You really only need VS Code + Node.js + npm + a terminal, and you can build basically anything. Claude Code is the AI layer on top — it knows all your tools and can drive them for you.

Stage 2 — The languages of the web (4 stops)

The three classic languages every browser speaks, plus the layer (TypeScript) that catches bugs before they happen.

5. HTML — what’s on the page

🎯 Why you’re here: Every webpage is HTML underneath. Even React/Next.js eventually produce HTML. If you can read HTML, you can debug almost any frontend issue by opening DevTools.

📖 Read:

🧠 Anchor concept: HTML doesn’t do things — it describes things. “This is a heading. This is a paragraph. This is a link.” The browser turns that description into pixels.

6. CSS — how it looks

🎯 Why you’re here: Same content, different look — that’s the difference between an unstyled and styled page. CSS is how you control colors, layout, spacing, animations.

📖 Read:

🧠 Anchor concept: You almost never write raw CSS from scratch in 2026. Tailwind lets you compose styles directly in your HTML/JSX with utility classes (flex p-4 bg-blue-500). It feels weird at first — like styling is “in the wrong place” — but the speed and consistency it enables is why it took over.

7. JavaScript — what makes pages do things

🎯 Why you’re here: Static pages are documents. Interactive pages — the kind every modern app is — need code that runs in response to clicks, typing, network responses, timers. That code is JavaScript.

📖 Read:

🧠 Anchor concept: JavaScript runs both in the browser AND on the server (via Node.js). The same language, the same code style. That’s why one person can build a whole webapp — front and back — without switching languages.

8. TypeScript — JavaScript that catches mistakes

🎯 Why you’re here: Plain JavaScript silently lets bugs through (“you sent me a string but I expected a number — fine, I’ll just produce nonsense”). TypeScript catches these at edit time.

📖 Read:

🧠 Anchor concept: TypeScript is JavaScript with type annotations that get checked by a compiler. The compiler is your tireless intern who reads every line of your code and yells when it sees a contradiction. After you’ve used it, going back to plain JS feels like driving without a seatbelt.

Stage 3 — Putting it together with React & Next.js (3 stops)

You don’t write raw HTML/CSS/JS for serious modern apps. You use React to build UIs from reusable components, and Next.js as the framework that handles routing, server rendering, and everything else around React.

9. React — building UIs from components

🎯 Why you’re here: Hand-writing HTML and manually updating it from JavaScript gets impossible at any real scale. React lets you describe what the UI should look like given the current data, and figures out the updates automatically.

📖 Read:

🧠 Anchor concept: A React component is just a function that returns JSX (HTML-flavored markup). Components compose: a <Page> is made of a <Header>, a <Sidebar>, a <Content>. State (data that changes) lives in components, via hooks like useState. When state changes, React re-renders the affected parts of the page.

10. Next.js — the framework

🎯 Why you’re here: React is just the UI library. To build an actual webapp you need routing, server-side rendering, API endpoints, image optimization, and a dozen other things. Next.js bundles them.

📖 Read:

  • Next.js 🟩 (written as part of this session)

🧠 Anchor concept: In Next.js’s App Router, the folder structure under app/ IS your routes. app/page.tsx is the homepage. app/blog/[slug]/page.tsx is every blog post URL. Server Components run on the server (can read your database directly). Client Components run in the browser (can use state, events). You mix them freely.

11. Styling your Next.js app (Tailwind + shadcn)

🎯 Why you’re here: Tailwind is your styling system. shadcn/ui gives you beautiful pre-built React components (buttons, modals, dropdowns, forms) that use Tailwind underneath. Together they let one person ship something that looks like it came from a design team.

📖 Read:

🧠 Anchor concept: shadcn/ui is not a library you install — it’s a CLI that copies component source code into your project. That makes the components yours to customize. Combined with Tailwind, this is the fastest path from blank page to polished UI in 2026.

Stage 4 — Saving your work with Git (2 stops)

Until you have version control, every change is risky and every collaboration is chaos. Git solves both.

12. Git — the time machine

🎯 Why you’re here: Git lets you save snapshots of your code, branch off experiments, and roll back when things break. It’s a hard prerequisite for hosting on Vercel (which deploys on git push).

📖 Read:

🧠 Anchor concept: A Git commit is a snapshot of your project at a moment in time. A branch is a parallel line of commits. You can switch between branches, experiment safely, and merge good experiments back into the main line. Once you grasp these two ideas, 80% of Git is in reach.

13. GitHub — Git on the internet

🎯 Why you’re here: Your local Git repo is private to your laptop. GitHub gives it a permanent home online, lets you collaborate, and is what Vercel listens to for deploys.

📖 Read:

🧠 Anchor concept: GitHub is just Git hosting + collaboration tools on top. Push your code to GitHub, and now it’s safely backed up, viewable from anywhere, and can be wired into automated deploys.

Stage 5 — Adding a database (4 stops)

The moment your app needs to remember anything — users, posts, scores, settings — you need a database.

14. What is a database, really?

🎯 Why you’re here: A database isn’t magical; it’s a server program that stores data in tables and answers queries about that data. The query language is SQL.

📖 Read:

🧠 Anchor concept: A relational database (like Postgres) stores data in tables of rows and columns, with strict types. You ask it questions in SQL. “Give me all users where active = true and signed up after January” is one SQL query away.

15. Postgres — the gold standard

🎯 Why you’re here: Of all the relational databases, Postgres is the most powerful, the most open, and the one Supabase is built on. You don’t need to install or operate it directly — Supabase handles that — but knowing what it is matters.

📖 Read:

🧠 Anchor concept: Postgres is the relational database that punches above its weight. Free, open source, ridiculously feature-rich. When experts list “should everyone just use Postgres?” — the answer is almost always yes.

16. Supabase — Postgres as a service, plus a lot more

🎯 Why you’re here: Supabase gives you a managed Postgres database, plus auth, file storage, realtime, and auto-generated APIs — all without managing servers. The default backend for solo developers in 2026.

📖 Read:

🧠 Anchor concept: Supabase = Postgres + Auth + Storage + Realtime + APIs, wrapped in a dashboard so you don’t need to be a DBA. The free tier covers small projects; pricing scales gently from there.

17. Row-Level Security (RLS) — the killer feature

🎯 Why you’re here: Without RLS, you have to trust your backend code to filter “what this user can see.” With RLS, the database itself enforces it on every query. Mistakes become impossible instead of just unlikely.

📖 Read:

🧠 Anchor concept: RLS lets you write rules like “a user can SELECT a row only if user_id = auth.uid()” — and the database enforces them automatically, no matter which API or function asks. This is what makes Supabase safe for solo developers. Without RLS, one bug in your app exposes everyone’s data.

Stage 6 — Knowing who’s who (2 stops)

A webapp that actually stores user data needs to know who’s logged in and what they can see.

18. Auth — the basics

🎯 Why you’re here: “Sign up, log in, log out, stay logged in across visits” is a surprisingly deep iceberg. You don’t need to implement it from scratch (Supabase Auth handles it) but you need to understand the pieces.

📖 Read:

🧠 Anchor concept: Authentication = proving who you are. Authorization = what you’re allowed to do once you’re authenticated. Supabase handles both: it stores users, gives you sign-up/login UI components, and issues a JWT that your app uses to identify the user on every request.

19. Hooking auth up to your data with RLS

🎯 Why you’re here: Auth + RLS together is the magic combination. When a logged-in user makes a query, Supabase knows who they are (via the JWT), and RLS uses that to filter what they can see — automatically.

📖 Read:

🧠 Anchor concept: You write the RLS rule once (user_id = auth.uid()). You add auth once. After that, every query the user makes is automatically filtered to just their data. No per-query if-checks. No “did I forget to add a filter?” worries.

Stage 7 — Getting it on the internet (3 stops)

You have a working app on localhost:3000. Now it needs to be live for anyone to use.

20. Hosting fundamentals

🎯 Why you’re here: “Hosting” is renting a computer on the internet that runs your app for visitors. Modern hosting is a lot more sophisticated than that — but that’s the kernel idea.

📖 Read:

🧠 Anchor concept: Modern hosting (Vercel, Netlify, Cloudflare Pages) does continuous deployment: every time you push to GitHub, the platform builds your app and deploys the new version automatically. You write code → push → it’s live.

21. Vercel — your deploy target

🎯 Why you’re here: Vercel makes Next.js. Vercel is the path of least resistance to deploying a Next.js app. Every other detail (regions, env vars, custom domains) gets handled in the dashboard.

📖 Read:

🧠 Anchor concept: Vercel turns “git push” into “live on the internet” with no infrastructure work. Free tier is enough for hobby projects. The integration with Next.js is so tight that for new projects, Vercel is the default choice unless you have a specific reason otherwise.

22. Custom domain + DNS

🎯 Why you’re here: your-app.vercel.app is fine for prototypes. For anything you want people to remember, you want yourname.com.

📖 Read:

🧠 Anchor concept: A domain is the human-readable name (stmarkbible.com). DNS is the internet’s phone book that maps it to the IP address of Vercel’s servers. You buy the domain, point its DNS records at Vercel, wait a bit, and you’re live with HTTPS (Vercel handles certificates automatically).

Stage 8 — Keeping it safe (3 stops)

You now have a live, real-world webapp. Time to make sure it stays safe.

23. The OWASP top 10

🎯 Why you’re here: Almost every hack in history falls into one of about ten categories. Knowing them by name is the difference between “I don’t know what could go wrong” and “I know what I’m defending against.”

📖 Read:

🧠 Anchor concept: Modern frameworks (React, Next.js, Supabase’s parameterized queries) prevent the worst attacks by default. But you have to know what they’re preventing — because you’ll occasionally need to opt out (e.g. dangerouslySetInnerHTML re-opens the XSS door).

24. Secrets — keeping the keys safe

🎯 Why you’re here: Your app has API keys, database credentials, service tokens. If any of them leak — to a public GitHub repo, into a client-side bundle, into a log — bad things happen.

📖 Read:

🧠 Anchor concept: Two iron rules. (1) Never commit secrets to Git (use .env.local, gitignore it). (2) In Next.js, anything you put in NEXT_PUBLIC_* env vars is exposed to the browser — so secrets must NEVER have that prefix.

25. Production-build discipline

🎯 Why you’re here: Code that runs in npm run dev often breaks in npm run build — TypeScript errors, missing env vars, case-sensitivity issues. Catching this locally is much cheaper than catching it in Vercel.

📖 Read:

🧠 Anchor concept: Always run npm run build before pushing to main. Always. The minute it takes locally beats the cycle of pushing, watching Vercel fail, fixing, pushing again.

Stage 9 — Making it polished (3 stops)

Functional ≠ delightful. These are the upgrades that distinguish a hobby project from something people actually want to use.

26. Mobile-first design

🎯 Why you’re here: Over 60% of your users will see your app on a phone first. Design for the phone, then enhance for the tablet and desktop.

📖 Read:

🧠 Anchor concept: With Tailwind, “mobile-first” is literally how the framework works — base styles apply to mobile, prefixes like md: apply on tablets and up.

27. Accessibility — building for everyone

🎯 Why you’re here: A subset of your users use screen readers, keyboard-only navigation, or have low vision. Designing for them makes the app better for everyone — and is often a legal requirement.

📖 Read:

🧠 Anchor concept: Semantic HTML (using <button> instead of clickable <div>s), alt text on images, sufficient color contrast, visible focus indicators, and keyboard navigation get you 80% of the way. The remaining 20% is testing with a screen reader and fixing what doesn’t make sense.

28. Dark mode + PWA

🎯 Why you’re here: Users in 2026 expect dark mode and “install to home screen.” Both are weekend-effort features that punch way above their weight.

📖 Read:

🧠 Anchor concept: Dark mode in Tailwind is essentially “add a dark: prefix to color classes” plus a tiny script that respects system preferences and remembers the user’s choice. PWAs add a manifest file and a service worker — Vercel makes both easy.

Stage 10 — Keeping it alive (2 stops)

Webapps don’t ship and stop. They need ongoing care.

29. Logs, monitoring, and debugging

🎯 Why you’re here: When something goes wrong in production, you can’t open DevTools on the user’s machine. You need logs that you can read.

📖 Read:

🧠 Anchor concept: Vercel keeps function logs for every deployment — they’re your second-best debugging tool after browser DevTools. Get comfortable opening them.

30. Iterating with Git, PRs, and AI

🎯 Why you’re here: You’ll keep adding features. Doing it well — small commits, good messages, reviewable PRs, AI as a second pair of eyes — is the difference between a project that grows healthily and one that calcifies.

📖 Read:

🧠 Anchor concept: Future-you is a different person from present-you. Commit messages that explain why (not what — the diff shows what) are gifts from present-you to future-you. Same for clean PRs. Same for letting Claude review your changes before you ship.

When you finish this path

You’ll be able to:

  • ✅ Explain to a non-technical friend what happens when they visit your webapp, from typing the URL to seeing the page
  • ✅ Read a Next.js project and tell what each file does
  • ✅ Set up a new Supabase project, design a few tables, enable RLS
  • ✅ Deploy a Next.js app to Vercel and connect a custom domain
  • ✅ Diagnose most “why isn’t this working?” problems by checking three or four obvious places
  • ✅ Know what you don’t know — and have a map back to the encyclopedia when a new term appears

You won’t be writing the code yourself — that’s not the goal. But you’ll be a competent, informed collaborator in any conversation about a webapp. You’ll be comfortable in the territory.

Where to go after this

Graph View

Backlinks