Static page(s)
Landing page, portfolio, docs — content changes rarely
$0 + domain · Minimal
△ You need per-user content or a form that does more than send email
Drawing set · L0–L3
ship a website solo
AI made writing the code the easy part. What nobody hands you is the infrastructure map: what shapes a website can take, which shape fits a one-person project, and which monthly bill each shape drags behind it. Below is the full architecture landscape from a single static page to microservices — most of it exists so you know what NOT to build yet.
Design philosophy
A website is a promise that an address will keep answering. Everything else — speed, looks, features — is negotiable; a dead link is not.
URLs are forever
Once a page is public, other sites, search engines and AI models remember its address. Changing it without a redirect silently deletes your own history.
Content first, runtime last
Most websites are documents, not programs. Bake pages ahead of time and only add a server when a page truly has to be computed per visitor.
One page, one question
Every page should answer exactly one question for exactly one kind of visitor. If you cannot name the question, the page should not exist yet.
One person, first real site? Start static or edge-fullstack (both marked). Everything to the right of them on the map is for the day you have users, revenue, or a team — upgrade when the signal fires, not before.
SheetL0
Prototype
Used byJust you and a few friends
Per month$0
①Why move up
You want to find out whether the idea is worth anything. Nobody depends on it yet, so there is nothing to protect — speed of trying is the only thing that matters.
②Architecture
Files on a CDN. No server, no database, no login. Every page is baked at build time and copied to data centers near the reader.
Δ New at this level
- + A domain
- + A repo that deploys on push
Shapes on the map: Static page(s) · Static site generation (SSG)
③Tools
Pick the stack your agent writes most fluently, not the one with the most features. At this level the framework barely matters; the deploy loop does.
④Code and tests
- One repo, one branch, push to deploy. No staging environment yet.
- Open every page on a real phone before you call it done.
- Run a link check: a prototype with dead links teaches you nothing about the idea.
SheetL1
Real users
Used byStrangers who found you
Per month$0–5
①Why move up
People you have never met are arriving. Some pages now need logic — a form, a language switch, a search — and search engines have started judging you.
②Architecture
Static pages stay static; a thin layer of edge code handles the few requests that must be computed. Still no server of your own, and still no database.
Δ New at this level
- + Edge functions for the dynamic bits
- + One source of truth for SEO tags
- + Automatic checks before every deploy
- + Visitor analytics
Shapes on the map: Edge full-stack (this site's shape) · Static front + serverless functions
③Tools
Choose a host whose free tier covers real traffic and whose runtime your framework officially supports. An adapter nobody maintains is the most expensive free thing you can pick.
④Code and tests
- Lint, type-check and build in CI on every push; a red check blocks the deploy.
- Test in the real runtime (a local preview of the edge worker), not the dev server — they behave differently.
- After each deploy, fetch the live pages and check their content, not just the status code. 200 is not the same as correct.
SheetL2
Money and data
Used byPeople who pay you or trust you with data
Per month$5–25
①Why move up
Accounts, payments or personal data have appeared. A bug is no longer embarrassing; it can cost someone money or expose them. You now owe people a duty of care.
②Architecture
The edge app gains a real database, and the risky parts — login and payments — are handed to specialists (a hosted auth provider, a payment processor) instead of built by hand. Secrets leave the code for good.
Δ New at this level
- + A managed database with backups
- + Auth and payments delegated to specialists
- + Secrets stored outside the repo
- + A privacy policy that matches the code
Shapes on the map: Edge full-stack (this site's shape) · Frontend + BaaS (hosted backend)
③Tools
Buy what can hurt people, build what makes you different. Never hand-roll password storage or card handling; pick providers with signed webhooks and a clear export path so you can leave.
④Code and tests
- Validate every input at the boundary and verify every webhook signature.
- Back up the database and actually rehearse a restore. An untested backup is a hope, not a backup.
- Write tests for the money and permission paths first; they are where a bug has victims.
- Scan every commit for keys and personal data before it is pushed.
SheetL3
Scale
Used byMany people, all at once
Per month$50–300+
①Why move up
The database groans before anything else does, an outage at 3 a.m. now costs real money, and more than one person is shipping code. Only move here when a measurement tells you to.
②Architecture
Put a cache in front of the database first, then split reads from writes. Only when writes themselves are the bottleneck do you shard, and only when many teams collide do you split into services. Each step is a new floor, not a remodel of the whole building.
Δ New at this level
- + A cache layer
- + Read replicas
- + Monitoring with alerts
- + Staged rollouts
Shapes on the map: Cache layer + read/write splitting · Containerized monolith (Docker) · Classic three-tier (web / app / DB) · Sharded databases (分库分表) · Microservices
③Tools
Every tool at this level trades money and complexity for headroom. Add one, measure, then decide on the next. If you are solo and reading this, you almost certainly belong on an earlier floor.
④Code and tests
- Load-test with realistic traffic before launch, not after the outage.
- Release to a small slice of users first and watch error rates before going wide.
- Every alert must name an action; an alert nobody can act on trains people to ignore alerts.
The architecture map
Every shape this can take. Most exist so you know what not to build yet.
Static site generation (SSG)
Blog, docs, this site — many pages built from data at deploy time
$0 + domain · Low
△ Content must update without redeploying, or per-request logic appears
Edge full-stack (this site's shape)
Solo projects needing APIs, i18n, dynamic bits — without owning servers
$0–5/mo · Low–mid
△ Long-running jobs, websockets at scale, or heavy relational data
Static front + serverless functions
Mostly-static site with a few API endpoints (forms, payments, auth)
$0–10/mo · Low–mid
△ Functions multiply and start sharing state — you're building a backend in fragments
Frontend + BaaS (hosted backend)
App-like products needing auth, database, realtime — fast
$0–25/mo · Low–mid
△ Pricing curve bends steeply with users, or you need logic the platform won't allow
VPS monolith (one server, everything on it)
Full control, weird runtimes, or long-running processes on a budget
$5–20/mo · Mid — you are now the ops team
△ The server dying at 3am is your problem; when that stops being acceptable, move
Containerized monolith (Docker)
Same app must run identically on laptop, VPS and cloud
$5–30/mo · Mid
△ One container can't hold the load, or deploys need zero downtime
Classic three-tier (web / app / DB)
Team-built business apps; the textbook enterprise shape
$20–100/mo · Mid–high
△ Read traffic crushes the database first — caching is the usual next move
Cache layer + read/write splitting
Read-heavy traffic outgrows one database
$50–300/mo · High
△ Writes themselves become the bottleneck — sharding territory ahead
Sharded databases (分库分表)
Write volume or data size exceeds any single database
$300+/mo · Very high
△ Cross-shard queries and team coordination pain → service boundaries beckon
Microservices
Many teams shipping independently on one product
$1000+/mo + a platform team · Extreme
△ This is the last stop. If you're solo and reading this — close the tab, go build
Concepts you'll actually need
One plain sentence and one metaphor each. Click any tool module for the same treatment.
- Domain & DNS
- The domain is your address; DNS is the phonebook that maps it to whichever server actually answers.
- ≈ A shop sign that can point to a new kitchen overnight without customers noticing.
- Hosting models
- Static hosting serves files; serverless runs your code per-request; a VPS is a whole computer you rent.
- ≈ Vending machine, food stall staffed on demand, or renting the whole restaurant.
- SSG vs SSR
- SSG bakes pages once at deploy; SSR cooks each page fresh per request. Baked is cheaper and faster if content allows.
- ≈ A bakery's morning batch versus a made-to-order kitchen.
- Edge computing
- Your code runs in hundreds of locations near users instead of one region — low latency, no server to manage.
- ≈ Convenience stores on every corner instead of one warehouse across the country.
- CI/CD
- Every push triggers automatic checks and deployment — humans stop being the release process.
- ≈ A factory line where the conveyor belt inspects and ships each item untouched by hand.
- Environment variables & secrets
- Config and keys live outside the code, injected at runtime — never committed to the repo.
- ≈ The safe combination is in your head, not written on the safe door.
- Caching
- Store the answer to an expensive question and reuse it until it goes stale.
- ≈ The barista writes the regular's order on a sticky note instead of asking every morning.
- i18n routing
- Each language gets its own URLs (/zh, /ja) so search engines index every version separately.
- ≈ One museum, three fully-signposted routes — not one route with a translation earpiece.
Take the skill.md with you
The Skill-Centric starter file for this scenario — hand it to your agent before the first prompt. It carries the plan, the stack and the known pitfalls.