VIBE CODING

A Complete Field Guide to Modern Web Development

From HTML to Production-Ready Deployment

What You Will Build

Full-stack web applications — from a static HTML page to a containerised, scalable product —
using AI tools, modern frameworks, and industry-standard deployment pipelines.

# Module What You Learn

00 Introduction What vibe coding is and how this course is structured

01 Prerequisites Git, Bun, HTTP, SQL, environment variables

02 SSR Path HTML, CSS, JS, backend basics, GitHub Pages

03 CSR Path React, AI scaffolding, [Link], Vercel

04 Backend Separate APIs, Railway/Render/[Link]

05 Auth + Database Supabase, PostgreSQL, RLS, secrets

06 CLI Tooling OpenCode, Claude Code, MCP servers

07 Production Docker, Kubernetes, scalability

08 Conclusion Roadmap, what to build next

 Module 00

Introduction
What is Vibe Coding, and why does this approach work?

What Is Vibe Coding?

Vibe coding is a modern approach to building web applications that prioritises speed, iteration,
and AI-assisted development. Rather than memorising syntax from scratch, you learn just
enough to direct AI tools intelligently, review their output critically, and ship working products
quickly.

This is not about shortcuts. It is about choosing the right tool for each layer of a project —
scaffold with AI builders where appropriate, reach for a CLI coding agent when precision
matters, and understand the underlying concepts well enough to debug anything.

How This Course Is Structured

The course follows a linear progression from concept to production. Each module builds on the
last:

1. Start with the mandatory foundations — tools and concepts every path depends on.
2. Choose your path: SSR (HTML-based) for simpler static projects, CSR (React-based) for
dynamic applications.
3. Learn backend, auth, and database as shared infrastructure that applies to both paths.
4. Add CLI tooling to accelerate your workflow.
5. Finish with production-grade deployment when your projects need to scale.

📌 Note
You do not need prior programming experience to start this course. You do need patience with the
command line and a willingness to read error messages carefully.

The AI-First Mindset

AI tools — Claude, ChatGPT, DeepSeek — are built into this workflow from day one. Use them
to:

• Generate boilerplate so you spend time on logic, not setup

• Explain code you do not understand — paste it in and ask
• Debug errors — copy the full error message, not just the last line
• Review your architecture decisions before committing to them

📌 Warning
The AI is a tool, not an authority. It will confidently generate broken code. Your job is to understand
what it produces well enough to catch and fix mistakes.
 Module 01

Prerequisites
The foundations every path depends on. Do not skip this module.

1.1 Git Basics

Git is non-negotiable. Every project in this course lives in a Git repository. You need to
understand:

• git init, git clone — starting a repository

• git add, git commit -m "message" — saving your work
• git push, git pull — syncing with GitHub
• git branch, git checkout -b name — working in isolation
• git merge, git rebase — bringing changes together

📌 Tip
Commit small and often. A commit message like "fix login bug" is useful. "updates" is not. Think of
commits as a diary of your decisions.

1.2 Bun (Your Runtime)

Bun is the preferred JavaScript runtime for this course. It replaces [Link] and npm with a
single, faster tool.

Core commands you will use daily:

• bun install — installs all dependencies from [Link]

• bun add <package> — adds a new dependency
• bun run <script> — runs a script defined in [Link]
• bun <[Link]> — runs a TypeScript or JavaScript file directly

📌 Note
Most tutorials and AI-generated code will use node and npm syntax. Mentally substitute: npm install
becomes bun install, node [Link] becomes bun [Link]. Bun is largely compatible with [Link]
APIs.

1.3 HTTP and REST — How the Web Actually Works

Before writing a single line of server code, understand the request-response cycle:
 • A client (browser, mobile app) sends an HTTP request to a URL
• The server receives the request, processes it, and returns a response
• Responses carry a status code: 200 OK, 201 Created, 400 Bad Request, 401
Unauthorized, 404 Not Found, 500 Server Error
• The body of most API responses is JSON

REST is a convention for designing APIs. The main conventions:

• GET /users — fetch a list of users

• GET /users/42 — fetch user with ID 42
• POST /users — create a new user
• PATCH /users/42 — update user 42
• DELETE /users/42 — delete user 42

1.4 SQL Basics

Supabase runs on PostgreSQL. You need enough SQL to read and write data without
depending on the Supabase UI for everything.

• SELECT * FROM users WHERE id = 1 — fetch a row

• INSERT INTO users (name, email) VALUES ('Krishna', 'k@[Link]') — add a row
• UPDATE users SET name = 'K' WHERE id = 1 — edit a row
• DELETE FROM users WHERE id = 1 — remove a row
• JOIN — combining rows from two tables based on a shared key

📌 Tip
Supabase has a built-in Table Editor that lets you run SQL queries directly in the browser. Use it to
learn SQL interactively before writing queries in code.

1.5 Environment Variables and Secrets — Critical

This is the most common mistake beginners make. Every project that connects to an API or a
database has secrets — keys, tokens, connection strings. These must never be committed to
GitHub.

The rules:

6. Create a file named .env in the root of every project

7. Add .env to your .gitignore file immediately — one line: .env
8. Store all secrets there in the format KEY=value
9. Access them in code via [Link] or [Link]
10. On each deployment platform, enter secrets in the Environment Variables settings panel

📌 Warning
Supabase gives you two keys: ANON_PUBLIC (safe to use in frontend code) and SERVICE_ROLE
(never expose — backend and server-side only). Confusing these two is a serious security mistake.
 Module 02

SSR Path — HTML, CSS, JS

Build and deploy static websites from scratch.

2.1 HTML and CSS Foundations

Start here even if you want to learn React eventually. Understanding the fundamentals makes
every framework easier.

• HTML provides structure — headings, paragraphs, links, forms, images

• CSS provides style — layout, spacing, colour, typography, responsiveness
• Flexbox and CSS Grid are the two layout systems to master first

Use AI throughout this phase. Paste code you do not understand and ask Claude or ChatGPT
to explain it line by line. Ask it to generate a specific layout and then study how it works.

📌 Tip
Build a personal portfolio page as your first project. It is small enough to finish, complex enough to
touch all the fundamentals, and immediately useful.

2.2 JavaScript for Functionality

Once HTML and CSS feel natural, add JavaScript for interactivity:

• DOM manipulation — changing content and styles after the page loads
• Event listeners — responding to clicks, key presses, form submissions
• fetch() — calling external APIs and displaying the response
• Local state — storing values in variables and updating the UI

📌 Note
JavaScript runs in the browser. It has no access to files on your computer or environment variables.
Secrets that go in .env are for server-side code only — never write API keys in JavaScript that gets
served to the browser.

2.3 Backend Basics (Same Learning Approach)

SSR backend development follows the same pattern: learn the concepts, use AI to generate
boilerplate, study what it produces.
Start with Hono or Elysia running on Bun — both are lightweight and beginner-friendly:

• Define routes that respond to GET and POST requests

• Parse incoming JSON from a request body
• Return JSON responses with the appropriate status code
• Connect to a database and run queries

Build the backend as a completely separate project from the frontend. They communicate over
HTTP — the frontend calls the backend's API endpoints.

2.4 Deploy via GitHub Pages

GitHub Pages hosts static files — HTML, CSS, and JavaScript — for free. It is the correct
deployment target for pure frontend projects with no server-side logic.

11. Push your project to a GitHub repository

12. Go to Settings > Pages in the repository
13. Set the source branch to main and the folder to /root or /docs
14. GitHub generates a live URL within a minute

📌 Warning
GitHub Pages is for static files only. If your project has a backend server that needs to run
continuously, use Railway or Render instead (covered in Module 04).
 Module 03

CSR Path — React

Build dynamic, component-driven applications with AI scaffolding.

3.1 Scaffold with AI Builders

Do not start a React project from a blank file. Use AI builders to generate a working foundation,
then customise from there.

• Lovable — describe your app in plain English, get a working React codebase
• [Link] — generate UI components from a description; export to your project
• Replit — browser-based IDE with AI assistance; good for quick prototypes

Workflow: Generate a base on the platform, customise it in the platform's editor until the
structure is stable, then push to GitHub and switch to Cursor for all further development.

3.2 React Fundamentals to Know

You do not need to master React before using it. You do need to understand:

• Components — reusable functions that return JSX (HTML-like syntax)

• Props — data passed into a component from its parent
• State (useState) — data that belongs to a component and triggers re-renders when it
changes
• useEffect — running code when the component loads or when data changes
• Fetching data — calling an API inside useEffect or with a data-fetching library

3.3 Choose the Right Framework

Plain React (Create React App) is rarely the right choice for a new project. These frameworks
add the missing pieces:

[Link]
React with server-side rendering, static generation, and file-based routing built in. The standard
for production React apps. Deploy to Vercel with zero configuration.
Remix
Full-stack React with server-side data loading and mutations. Better default behaviour around
forms and progressive enhancement. Good for apps that need fast server-rendered pages.

Astro
Ships minimal JavaScript by default. Ideal for content-heavy sites like blogs, documentation,
and marketing pages. Supports React, Vue, and Svelte components inside Astro pages.

📌 Tip
If you are not sure which to choose: pick [Link]. It has the largest community, the most tutorials,
and the best AI training data — meaning Claude and other tools will give you more accurate help.

3.4 Edit and Debug with Cursor

Cursor is your primary IDE for React development after the initial scaffold. Key workflows:

• Inline edits — select code, press Cmd/Ctrl+K, describe the change you want
• Chat with codebase context — Cursor reads your entire project, so questions like "why is
this component re-rendering?" get accurate answers
• Error handling — paste a stack trace directly into the chat and ask what caused it
• Refactoring — ask Cursor to split a large component into smaller ones, or convert a class
component to a function

3.5 Deploy Frontend via Vercel

Vercel is the natural home for [Link] and React applications:

15. Connect your GitHub repository to Vercel

16. Vercel detects the framework automatically and configures the build settings
17. Add environment variables in the Vercel dashboard under Project > Settings >
Environment Variables
18. Every push to main triggers an automatic deploy; every pull request gets a preview URL

📌 Note
Never add secrets to your code or commit them to GitHub. Environment variables set in the Vercel
dashboard are injected at build time and at runtime — they are never visible in your repository.
 Module 04

Backend
Build and deploy your API independently from the frontend.

4.1 Separate Frontend from Backend

Build the backend as an entirely separate project with its own repository and its own
deployment. The frontend calls the backend over HTTP — they are connected by a URL, not by
code.

This separation gives you:

• Independent deployments — update the API without touching the frontend

• Independent scaling — run more backend instances without changing the frontend
• Clean architecture — clear boundary between what the user sees and what the server
does

4.2 Building Your API

Use Bun with Hono or Elysia to build the API. A minimal API structure:

19. Define routes for each resource (users, posts, products, etc.)
20. Validate incoming request data before processing it
21. Connect to Supabase for database reads and writes
22. Return consistent JSON responses with appropriate status codes
23. Handle errors explicitly — never let unhandled exceptions crash the server

Use Cursor throughout development. Ask it to generate route handlers, write database queries,
and add input validation. Review everything it produces.

4.3 Where to Deploy Your Backend

Vercel is for frontends. Use one of these platforms for a standalone backend server:

Railway
The easiest option. Connect your GitHub repo, select your start command (bun run start), add
environment variables, and deploy. Generous free tier. Recommended for first backends.
Render
Similar to Railway. Good for persistent services that need to stay running. Also supports cron
jobs and background workers.

[Link]
More control over regions and runtime configuration. Steeper learning curve but better options
for latency-sensitive applications that need to run close to specific users.

📌 Warning
Vercel serverless functions work for simple use cases but are not the right home for a stateful
backend server. If your server needs persistent connections (WebSockets, long-running jobs, cron
tasks), use Railway, Render, or [Link].

4.4 Connecting Frontend to Backend

Store the backend URL as an environment variable in the frontend:

• In development: NEXT_PUBLIC_API_URL=[Link]
• In production: NEXT_PUBLIC_API_URL=[Link]

In [Link], environment variables prefixed with NEXT_PUBLIC_ are safe to expose to the
browser. Variables without this prefix stay server-side only.

📌 Note
Set CORS (Cross-Origin Resource Sharing) headers on the backend to allow requests from your
frontend domain. Without this, the browser will block requests even if the API URL is correct.
 Module 05

Auth + Database
Supabase handles both — no need to build auth from scratch.

5.1 What Supabase Gives You

Supabase is a hosted PostgreSQL database with authentication, real-time subscriptions, file
storage, and edge functions built on top. For most projects you will use:

• Database — PostgreSQL with a visual editor, SQL runner, and REST API generated
automatically
• Auth — email/password, magic links, OAuth (Google, GitHub, etc.) with session
management
• Storage — for uploading files and images
• Row-Level Security — database policies that control who can access what data

5.2 The Two API Keys — Critical

Supabase gives every project two keys:

Key Usage
ANON_PUBLIC Safe to use in frontend code. Subject to Row-Level Security policies.
SERVICE_ROLE Backend and server-side ONLY. Bypasses all security policies. Never
expose in frontend code.

📌 Warning
Exposing your SERVICE_ROLE key in frontend code gives anyone full read and write access to
your entire database, bypassing every security rule. Store it only in server-side environment
variables.

5.3 Row-Level Security (RLS)

RLS policies are SQL rules attached to database tables that control what each user can see
and modify. Enable them on every table.

Examples:

• A user can only read rows where user_id = [Link]() — their own data
 • A user can only insert rows where user_id = [Link]() — prevents writing to others'
records
• Public tables (like a product catalogue) can allow SELECT for all without authentication

📌 Note
Do not rely on frontend checks alone to protect data. A determined user can bypass JavaScript
logic entirely. RLS enforces security at the database level — it is the last line of defence.

5.4 Auth Flow in Practice

Use the Supabase JS SDK in the frontend for all auth operations:

• [Link]() — new user registration

• [Link]() — email/password login
• [Link]() — Google, GitHub, etc.
• [Link]() — end the session
• [Link]() — check if a user is currently logged in

Once a user is signed in, Supabase attaches their identity to every database request
automatically. RLS policies can then reference [Link]() to enforce per-user access.
 Module 06

CLI Tooling
OpenCode and Claude Code — the current AI coding agent market.

6.1 What CLI Coding Agents Do

CLI coding agents are AI assistants that run in your terminal and have direct access to your
codebase. Unlike a browser-based chat interface, they can:

• Read every file in your project simultaneously

• Write and edit files directly
• Run commands, tests, and build scripts
• Understand the full context of a bug without you copying and pasting

Both OpenCode and Claude Code follow the same basic workflow: run the agent from your
project directory, describe what you want, and it makes the changes. You review, accept or
reject, and continue.

6.2 OpenCode
OpenCode is the open-source option. It is free to use, actively developed, and supports multiple
underlying AI models.

Choose OpenCode if:

• You want a free tier with no subscription
• You prefer open-source tools you can inspect and modify
• You want to use different AI models depending on the task

Key features: slash commands for common operations, plugin system for extending
functionality, community-maintained integrations.

6.3 Claude Code

Claude Code is Anthropic's paid CLI agent. It has tighter integration with Claude's models and a
polished agentic workflow.

Choose Claude Code if:

• You are already on an Anthropic subscription

 • You want the most capable agentic coding experience available today
• You need consistent, reliable output on complex multi-file tasks

Key features: same slash commands and plugin architecture as OpenCode, deep codebase
understanding, strong performance on architecture-level tasks.

6.4 MCP Servers — The Multiplier

Both tools support MCP (Model Context Protocol) servers. MCP is how CLI agents connect to
external services and tools beyond your local codebase.

With MCP, the agent can:

• Read and create GitHub issues and pull requests

• Query your Supabase database directly
• Search Notion or Confluence for documentation
• Read Slack messages for context on a bug
• Interact with any service that exposes an MCP server

📌 Tip
Learning to configure MCP servers is one of the highest-leverage skills in this stack. An agent that
can read your GitHub issues, check the database schema, and write code to fix a bug in one step
is qualitatively faster than one that cannot.

6.5 Slash Commands

Both CLI agents support slash commands for common tasks. Examples:

• /fix — analyse and fix the current error

• /test — write tests for the selected code
• /review — review the current diff or file for issues
• /explain — explain a file or function in plain language
• /commit — write a commit message based on staged changes

The specific commands available depend on the agent and installed plugins. Both tools have a
/help command that lists what is available.
 Module 07

Production Deployment
Docker and Kubernetes — for when scale becomes a real requirement.

7.1 When You Need This

Docker and Kubernetes are production infrastructure tools. You do not need them for:

• Projects with a handful of users

• Hobby projects and hackathon demos
• Early-stage products where you are still validating the idea

You need them when:

• You are deploying for an organisation with strict infrastructure requirements

• Your app needs to handle thousands of concurrent users reliably
• You need predictable, reproducible deployments across multiple environments
• You are joining a team that already uses container infrastructure

7.2 Docker
Docker packages your application and all its dependencies into a container — a self-contained
unit that runs identically on any machine that has Docker installed.

The core concepts:

• Dockerfile — a script that defines how to build your container image

• Image — the built, immutable snapshot of your application
• Container — a running instance of an image
• docker build — creates an image from a Dockerfile
• docker run — starts a container from an image
• docker-compose — runs multiple containers together (app + database + cache)

Learn Docker before touching Kubernetes. Every Kubernetes concept builds on container
fundamentals. If you cannot write a Dockerfile, you are not ready for Kubernetes.

7.3 Kubernetes
Kubernetes orchestrates containers at scale. It answers the question: if I have ten containers
running my API, how do I manage deployments, route traffic, restart crashed containers, and
scale up under load?

The core concepts:

• Pod — the smallest deployable unit, wrapping one or more containers

• Deployment — defines how many pods to run and how to update them
• Service — a stable network endpoint that routes traffic to pods
• Ingress — routes external HTTP traffic to the right service
• ConfigMap and Secret — store configuration and sensitive data separately from the
application

📌 Warning
Kubernetes has a steep learning curve. Do not introduce it until you have a genuine scaling
problem. Many successful production applications never need it — Railway and Render handle the
infrastructure so you do not have to.

7.4 Learning Path for This Layer

24. Get comfortable with Docker locally — build images for your existing projects
25. Use Docker Compose to run your app and database together in development
26. Deploy a Docker container to Railway or [Link] to understand production containers
27. Learn Kubernetes concepts through Minikube (local) before touching a cloud cluster
28. Only move to a managed Kubernetes service (GKE, EKS, AKS) when the project
justifies it
 Module 08

Conclusion
What comes next and how to keep building.

8.1 What You Now Have

By completing this course you have a complete, practical framework for building and shipping
web applications at every scale:

• Foundations that make every tool and framework easier to learn

• Two frontend paths — SSR for simplicity, CSR for dynamism — with clear deployment
targets for each
• A backend architecture that scales independently from the frontend
• Auth and database handled out of the box via Supabase
• CLI agents that multiply your development speed
• A production deployment path when the project demands it

8.2 What to Build Next

The fastest way to consolidate this knowledge is to build something real. Suggested projects in
order of complexity:

29. A personal portfolio with a contact form backed by Supabase — covers SSR, a simple
backend, and database basics
30. A CRUD task manager built in [Link] with Supabase auth — covers the full CSR stack
from scaffold to deployment
31. A small SaaS product with paid features — adds payment integration (Stripe) and more
complex RLS policies
32. A containerised API deployed to Railway with a [Link] frontend on Vercel — covers the
full separation-of-concerns architecture

📌 Tip
Pick the simplest project on this list that still stretches you. Finishing a small project completely is
worth more than starting a complex one and abandoning it.

8.3 Staying Current

This stack will evolve. The tools that matter most are the ones with the best fundamentals
underneath them — Git, HTTP, SQL, and component-based UI will remain relevant regardless
of what replaces React or Bun.

Where to follow the ecosystem:

• GitHub release pages for Bun, [Link], Supabase, and Cursor

• Changelog and docs for OpenCode and Claude Code
• The MCP ecosystem — new server integrations are being added constantly
• Hacker News and X/Twitter for early signals on tooling shifts

Quick Reference — Complete Tool Map

Purpose Tool Tier

Runtime Bun (preferred), [Link] Free
SSR Frontend HTML + CSS + Vanilla JS Free
CSR Scaffold Lovable, [Link], Replit Free/Paid
React Framework [Link], Remix, Astro Free
IDE / Editing Cursor Free/Paid
Frontend Deploy Vercel Free/Paid
Backend Deploy Railway, Render, [Link] Free/Paid
Static Deploy GitHub Pages Free
Auth + Database Supabase (PostgreSQL) Free/Paid
CLI Agent (OSS) OpenCode Free
CLI Agent (Paid) Claude Code Paid
Containers Docker Free
Orchestration Kubernetes Free

The One Rule

 Ship something. Then make it better.
A working project with rough edges teaches more than a perfect architecture that never
launches.