GitHub

Founders note: Most people think of GitHub as code storage and part of their SDLC. I think of it as a very secure file store, a CDN for static assets, and a hosting platform—with almost no lock-in because git is universal.

What GitHub is

GitHub is Microsoft’s developer platform built on git: distributed version control, branches, pull requests, and collaboration. That is the headline—and it is true. It is also incomplete.

Under the same account you get:

• Secure file storage — every commit is hashed, signed, and auditable; private repos with fine-grained access; releases for versioned binaries and docs.
• CDN-like delivery — raw.githubusercontent.com and release assets serve static files on a global edge without you standing up Cloudflare or S3 first.
• Hosting — GitHub Pages publishes static sites from a branch or folder; custom domains and HTTPS included on free tiers for public repos.
• Lightweight ops — Issues, Projects, and Discussions when you want a backlog without buying Jira on day one.
• Automation — Actions when you need CI/CD (SDLC territory—optional, not the whole story).

It sits next to Render and Cloudflare Pages for git-backed hosting, and next to Surge as the thing Surge beats for hot deploy—but GitHub wins when you want history, portability, and agent-readable context in one place.

The mental model most people miss

The SDLC framing is a trap. Founders hear “GitHub” and think:

• developers only
• pull requests and code review
• something that happens after Notion and before production

The reframed stack role:

First-login trap: the UI assumes you already speak branches, forks, and merge strategies. Time-to-wow stays low until someone shows you Pages, a release URL, or wires MCP so an agent reads history for you.

Why I reach for it

Portable by default. Git is not a GitHub proprietary format. Clone elsewhere tomorrow; you lose Actions YAML and Pages config, not your files or history. On the depth-of-value axis—where low means safe entanglement—GitHub’s core is a two, not a Cloudflare five.

Agent-native context. In Stephan’s MCP workbench, GitHub is the backwards-looking layer: what changed, why, and whether this feature is greenfield or a reaction to prior commits. Marry that with Sentry and the agent sees usage and runtime—not just the latest snapshot.

Free tier that ships. Private repos, Pages for public sites, releases, and raw file URLs—production-shaped for early-stage stacks without a second hosting bill.

Secure enough for real work. Access controls, audit log on paid tiers, Dependabot and secret scanning when you want them—without running your own git server.

What it is not for

Not everything belongs on GitHub alone.

• Hot client demo in 60 seconds — use Surge; Pages wants a repo, a branch, and patience.
• Full-stack API + Postgres in one dashboard — use Render or Fly.io.
• Edge Workers, R2, DNS in one vendor — use Cloudflare.
• Non-technical co-founder owns deploys with zero git vocabulary — send them to Render first; GitHub second once an agent or CTO shepherds Pages.

GitHub Pages is not a substitute for a product SDLC you have not defined—it is static hosting plus git history. Know which job you are hiring it for.

GitHub Pages vs Surge vs Render

Surge literally says Pages wants ceremony Pages does not need for throwaways:

GitHub Pages wants a repo, a branch, a build step, and patience. Surge wants a folder.

For repo-backed marketing sites, docs, and Astro builds you intend to keep, Pages (or Render Static Sites connected to the same GitHub repo) is the right lane. For Zoom-in-ten-minutes previews, Surge first; commit to GitHub when the demo survives the meeting.

At a glance

• What it is: Git hosting plus secure storage, static Pages hosting, release CDN URLs, issues, and Actions—one account most agents already assume exists.
• Best for: Founders who want portable history, agent-readable change context, static sites from git, and versioned file delivery without a separate object store on day one.
• Not a fit: Non-technical owners who need click-click hosting today; hot static deploy with zero git; edge compute and managed Postgres (Render, Fly).
• Pairs with: Cursor + GitHub MCP for shared context; Sentry for production plus history; Cloudflare when Pages is not enough CDN or DNS control.

When to reach for it

Reach for GitHub when you want secure, versioned storage and optional hosting under one roof—with exit ramps because git is universal. Set up the repo early, wire MCP in Cursor, and treat Pages and raw URLs as features you turn on when needed—not as proof you run a “real” SDLC.

If your co-founder will never touch branches, still use GitHub for the repo—but let Render or Cloudflare own the deploy button until the agent bench is wired.

Related playbook entries

• Cursor — desktop surface where GitHub MCP turns repo history into shared founder context.
• Surge — hot static deploy before you commit to Pages ceremony.
• Render — git-connected hosting when the dashboard must be founder-friendly.
• Cloudflare — DNS, CDN, and edge when GitHub Pages is not enough.
• Sentry — production observability; pair with GitHub history for agent debugging.

Tech Stack Clarity Check (15 min) — Book a slot if you want help deciding whether GitHub Pages, Render, or Cloudflare should own your static ship path—not resume comfort, actual exit risk.

AI prompts for vibe coding