Day 11 of 28 · Vibe Coding Challenge
Building Full-Stack Apps
⏱ 8 min
📊 Intermediate
Until now, you've built things that live in the browser — frontends. Today you add the other half: a backend. Your apps will be able to process data, store information, and run logic that happens on a server — not just in the user's browser.
This is where vibe coding gets powerful.
Frontend vs. backend
Frontend — What the user sees and interacts with. The buttons, the forms, the layout. Runs in the browser.
Backend — What happens behind the scenes. Processing payments, saving data, sending emails, running business logic. Runs on a server.
Full-stack — Both together. A complete application.
Think of a restaurant: the dining room (what customers see) is the frontend. The kitchen (where food is prepared) is the backend. A full-stack app is the whole restaurant.
Knowledge Check
Why can't everything run in the frontend (browser)?
A
Browsers aren't powerful enough
B
Some operations need to be secure and controlled — like processing payments, accessing databases, and handling sensitive data
C
Frontend code runs too slowly
D
There's no technical reason — it's just tradition
Anything in the browser is visible to the user and can be manipulated. You'd never process a credit card payment in frontend code — anyone could change the amount. Backend code runs on a secure server where users can't see or modify it.
Building a full-stack app with AI
The magic of modern vibe coding tools is that they handle both frontend and backend in one prompt. You don't need to set up a separate server — tools like Bolt and Replit Agent create everything together.
Let's build a real app: a link shortener — like Bitly, but yours.
Build a link shortener app. Users paste a long URL, click "Shorten", and get a short URL they can copy. Features:
- Paste long URL and generate a short code
- Click to copy the short URL
- Show a list of recently shortened links
- Track how many times each short link has been clicked
- Clean, minimal design
Use React frontend with a Node.js/Express backend. Store data in a SQLite database.
Building your link shortener...
Done ✓
**Frontend:**
📎 URL input field with "Shorten" button
📋 One-click copy for shortened URLs
📊 Recent links table with click counts
**Backend:**
🔗 POST /api/shorten — generates a random 6-character code
↗️ GET /:code — redirects to the original URL and increments click count
📈 GET /api/links — returns all shortened links with stats
**Database:**
💾 SQLite with links table (original_url, short_code, click_count, created_at)
Full stack running. Try pasting a URL!
↻ Replay conversation
Frontend is what users see. Backend is what makes it work.
Knowledge Check
What did the AI create that couldn't exist in a frontend-only app?
B
The backend API routes and database that store links and track clicks
C
The copy-to-clipboard button
D
The input field styling
The link shortener needs a server to store URLs in a database and handle redirects. When someone visits a short link, the server looks up the original URL and redirects them — that can only happen on a backend. The frontend just provides the interface.
The tech stack — decoded
When AI builds a full-stack app, it picks a "tech stack" — the set of technologies used. Here are the most common ones you'll see:
Frontend frameworks:
- React — The most popular. Used by Facebook, Netflix, Airbnb.
- Next.js — React with extra features (routing, server rendering). Used by Vercel, TikTok, Notion.
- Vue — Simpler alternative to React. Popular in Asia and Europe.
Backend frameworks:
- Express (Node.js) — The simplest backend framework. Great for APIs.
- Next.js API routes — Backend and frontend in one framework. Becoming the default.
- FastAPI (Python) — If you prefer Python. Fast and clean.
Databases:
- SQLite — Simple file-based database. Great for prototypes and small apps.
- PostgreSQL — Production-grade database. Handles millions of records.
- Supabase — PostgreSQL with a nice dashboard and built-in auth. Very vibe-coding friendly.
You don't need to choose — the AI picks what fits. But knowing the names helps you communicate.
Let's build something bigger
A link shortener is nice. Let's build something with more features — a feedback board where users can submit and vote on feature requests.
Build a feature request board (like Canny or Nolt). Users can:
- Submit feature requests with a title and description
- Upvote other people's requests
- Sort by "Most Votes" or "Newest"
- See the status of each request (Planned, In Progress, Done)
Admin can change the status of requests. Use a modern card-based design. Full stack with React, Express, and SQLite.
Feature request board built ✓
**User features:**
💡 Submit requests — title + description form
👍 Upvote with one click (can't vote twice from same session)
🔀 Sort by "Most Votes" or "Newest"
🏷️ Status badges: Planned (blue), In Progress (yellow), Done (green)
**Admin panel:**
🔑 Access via /admin route
✏️ Change status of any request
🗑️ Delete spam requests
**Backend:**
📡 Full REST API — CRUD endpoints for requests + voting
💾 SQLite database with requests and votes tables
Live and functional. Try submitting a feature request!
↻ Replay conversation
A full feature request board — voting, filtering, status tracking, and admin controls.
Knowledge Check
What makes the feedback board a "full-stack" application?
B
It has a lot of features
D
It has both a frontend (the user interface) and a backend (the API and database that store and process data)
Full-stack means the app has both halves — the part users see (frontend) and the part that processes and stores data (backend). The feedback board has a React frontend for the interface and an Express backend with a SQLite database for persistent data.
When to go full-stack
Not every project needs a backend. Here's a quick guide:
Frontend only (no backend needed):
- Landing pages and portfolios
- Calculators and converters
- Static blogs and documentation
- Local-only tools (data stays in the browser)
Full-stack (you need a backend):
- User accounts and authentication
- Data that persists across sessions and devices
- Payment processing
- Sending emails or notifications
- Admin panels and dashboards
- Multi-user features (voting, commenting, collaboration)
When in doubt, start frontend-only and add a backend when you need persistence or security.
Final Check
Which of these projects would require a backend?
A
A booking system where multiple users can reserve time slots
C
A personal portfolio page
D
A CSS animation playground
A booking system needs a backend because multiple users need to see the same data (available time slots), and reservations need to be stored permanently in a database. A calculator, portfolio, or CSS playground can all work entirely in the browser.
🏗️
Day 11 Complete
"Frontend is what they see. Backend is what makes it real. You just built both."
Tomorrow — Day 12
Databases Made Easy
Your apps need memory. Tomorrow you'll add databases so your data persists — even after users close their browser.