SESSION 4 · ~55M
Deploy: ship it
A tool isn't done until someone else can use it — deployment turns a local prototype into a shared link.
The last mile is making it shareable. A static export — HTML, CSS, and JavaScript files with no server — deploys free and fast to a global CDN. This is the whole point of the static-export setup: build locally, deploy as files, share a URL.
The deploy path
- Build — produce the static files (everything bundled into an output directory).
- Deploy — push that directory to a static host (Cloudflare Pages, Netlify, Vercel) via their CLI or dashboard.
- Share — the host gives you a URL instantly; optionally attach your own domain.
Tooling: the wrangler CLI (Cloudflare) deploys with one command from your terminal — no DevOps required. Other hosts offer equivalent one-command deploy. The barrier to shipping is now minutes, not a sprint.
Static means cheap, fast, and durable. No server means no server to secure, scale, or pay for at 3am. For most internal supply-chain tools — calculators, dashboards, prototypes — static hosting is not a compromise, it's the right architecture.
Domain and polish: a custom domain makes a tool feel real and shareable inside your team. Before sharing, run through it once as a user — the deploy step is also your final chance to catch the obvious bugs a fresh user would hit immediately.
TRY IT
Take any tool you've built in this session and deploy it. Grab the resulting URL, open it in a fresh browser, and use it as a stranger would. That end-to-end loop — build, deploy, open-as-user — is the repeatable rhythm of shipping tools.
CHECK YOUR UNDERSTANDING
What are the three steps of the deploy path described in the module?
What advantage does static hosting have for most internal supply-chain tools?
What does the module recommend doing before sharing a deployed tool?
NOTEBOOKLM
Connect your notebook
Paste a NotebookLM share link to embed your notebook for this module.