A recommended default path for the solo builder
Here's a route that has worked for countless one-person projects. Each step is taken only when you actually need it.
-
Prototype: static + a managed service. Put your on static hosting (Cloudflare Pages, Vercel, or Netlify). For data and auth, lean on a managed backend like Supabase or Firebase so you skip running a yourself. Cost: effectively zero.
-
Early production: add or functions. When you need server-side logic — calls, webhooks, custom auth — add functions on the same platform. Still scales to zero, still cheap, still one .
-
Real product: move the backend to a platform. When the app outgrows functions (long-running processes, a that wants a persistent server, background jobs), containerize it and deploy to Railway, Render, or Fly.io. Have AI write the
Dockerfileand platform config. -
Scale or specialize: only then consider VMs or a cloud provider like AWS. This is where complexity (and your bill) jumps. Most solo builders never need this step, and that's a sign of doing things right — not a limitation.
A CDN (Content Delivery Network) sits in front of this path and changes the speed dramatically depending on whether it already has a copy. A HIT answers instantly from the edge; a cache MISS has to travel all the way back to your server first:
CACHE HIT (fast — most requests)
┌─────────┐ ┌───────────┐
│ BROWSER │ ───▶ │ EDGE CACHE│ ──┐ copy already here
└─────────┘ ◀─── │ (has it) │ ◀─┘ reply in milliseconds
└───────────┘
CACHE MISS (slow — first request)
┌─────────┐ ┌───────────┐ ┌──────────┐
│ BROWSER │ ───▶ │ EDGE CACHE│ ───▶ │ SERVER │ fetch + store
└─────────┘ ◀─── │ (empty) │ ◀─── │ (origin) │ next time = HIT
└───────────┘ └──────────┘
The mistake to avoid is starting at step 4 because it's what "real engineers" supposedly use. The opposite is true: starting simple is the senior move. You can always graduate to more control, but you can't easily get back the months you'd lose wrestling infrastructure you didn't need.