11.1 Launch: Beyond GitHub Pages¶
GitHub Pages can host static sites. A project that needs a backend, database, custom domain, or form delivery requires a platform decision with current terms, costs, data handling, ownership, and operational work.
What you will learn
- Map the hosting tiers: static, serverless platforms, and when you'd need more.
- Launch on a modern platform (Vercel/Netlify class) with a custom domain.
- Run the launch checklist that separates "live" from "launched."
Builder principle
Match the platform to the project and verify current terms. A free plan is an option to evaluate, not a permanent cost guarantee.
The tiers, demystified¶
Tier 1 — Static hosting (GitHub Pages, and the static side of Netlify/Vercel/Cloudflare Pages). Files are served without your own application server. Verify current eligibility, limits, ownership, and cost, and stay with the simpler tier while it meets the documented need.
Tier 2 — Serverless platforms (Vercel, Netlify, Cloudflare). Static hosting plus small pieces of on-demand backend (form handling, API routes, auth) and niceties: deploy-on-push, preview URLs per branch, custom domains with automatic HTTPS. Free-plan terms, quotas, data handling, and commercial/client eligibility vary and change. Check the current terms for the actual owner and workload before promising a platform or price.
Tier 3 — Real infrastructure (VPS, containers, managed cloud). For when you have persistent processes, big databases, or traffic that outgrows tier 2. If you genuinely need this, you'll know — and the same delegation pattern applies, so we won't pretend it needs its own course. Rule of thumb: being scared of tier 3 is fine; reaching for it out of vanity is expensive.
The launch, delegated¶
Platform choice made (your agent can brief the tradeoffs for your specific project — ask), the launch itself is an agent task with human gates exactly where you'd expect:
This project is ready to launch on [platform]. Set it up:
deploy config, connect the GitHub repo for deploy-on-push, and
walk me through the account/domain steps you can't do — one at
a time, telling me what each does.
Done means: the site is live on its platform URL, a test change
deploys automatically when pushed, and you've shown me the
preview-URL flow for branches.
Two notes on what just happened. Deploy-on-push is your Git rhythm (3.3) growing its final limb — commit, push, live — with your harness and hooks (9) standing between you and shipping breakage. And preview URLs per branch quietly upgrade your whole Chapter 10 practice: every team lane's PR now carries a clickable live preview — your acceptance pass (4.4) and reviewer subagent can inspect real deployed behavior per lane. The stack keeps composing, right to the end.
The custom domain can improve recognition, but price, renewal, privacy, taxes, and ownership vary. Put the domain and hosting accounts in the long-term owner's name, record renewal responsibility, enable spend alerts, and verify current terms before purchasing. A platform URL is valid when a domain adds cost without user value.
Live ≠ launched¶
The checklist that separates the two — run it on everything you ship from now on:
- The basics read right: real page title, favicon, social-preview card (test by pasting your URL in a chat — that unfurl is your first impression at scale).
- Representative environment: run the 4.4 acceptance matrix on relevant devices and assistive configurations you can access; document coverage gaps.
- The form actually arrives (if there's a form): submit it, receive it. "Deployed" and "delivers" are different claims.
- Data is justified: collect only what is needed, state purpose/retention, get required consent, secure transport/storage, and provide a deletion or contact path.
- Rights are traceable: licenses and permission for code, fonts, images, quotes, and generated assets are recorded; material AI involvement is disclosed when it affects trust.
- People can use it: keyboard path, visible focus, contrast, alt text, zoom/reflow, representative content, and an automated accessibility scan are checked.
- Abuse has a plan: forms, uploads, automations, and accounts have reasonable limits, moderation/escalation, and a human contact or recourse path.
- Something watches it: choose an uptime check whose current terms, retention, access, and cost fit the project. Test that an alert reaches the owner. (11.2 goes deeper.)
- The handoff or announcement: tell the authorized intended audience where the result lives and what to expect. A private handoff is valid; public promotion is optional.
A managed platform can be a professional setup when its current terms permit the intended work. This week, compare two platforms on ownership, commercial eligibility, quotas, data handling, accessibility, support, renewal, and spend controls. Move your best Chapter 6 build only if the change solves a real need; a domain is optional.
Make the delegation the exercise only within an authorized disposable or low-risk deployment. A green harness can block known failing checks before push-to-main; it cannot prove that a deployment has no defect. Record the checks, blind spots, account gates, and final human approval.
Try it now¶
- Decide whether your best project needs tier 2. Record current terms, commercial eligibility, ownership, data handling, limits, and likely spend; migrate only if the evidence supports it.
- Decide whether a domain adds user value. If yes, put ownership and renewal in the right hands; if no, keep the platform URL.
- Run the full live-≠-launched checklist, using a private handoff or an authorized announcement as appropriate.
- Journal: total time from "decided to launch" to "announced." (Keep this number. It's about to become part of your pricing story in 11.4.)
Check your understanding¶
- Name the three tiers and the graduation trigger between 1 and 2.
- What do preview URLs per branch do to your Chapter 10 workflow?
- Pick three checklist items and explain what each protects.
- Why is "announced" part of the definition of launched?