Site Launch Plan

The site should launch as a public, static MkDocs personal website first.

The paid skill library should remain a second phase until the offer, access model, and fulfillment loop are real enough to test.

The safe deployment boundary is this personal-site/ directory. Do not publish the parent workspace root.

Working Goal

Publish a durable personal site that makes the work legible:

• who this is
• what problems the work clusters around
• what writing is worth starting with
• how to collaborate
• how to verify credibility
• how to contact

The first launch should cost zero in hosting. Domain registration is separate; halotj.com is the chosen owned-domain candidate.

Architecture Decision

MkDocs is the right first form factor because it keeps the site close to the writing system:

• Markdown source is easy to edit.
• The generated site is static and hostable almost anywhere.
• Material for MkDocs gives search, navigation, and enough visual control without turning this into a frontend project.
• The public site can later point to a paid product without becoming the paid product.

Hosting Decision

Use Vercel first because the site is personal and non-commercial for now.

Use Netlify or Cloudflare Pages later if commercial Stripe access becomes real and the site should remain on a free static-hosting plan.

The reason is policy, not technical capability. Vercel Hobby supports personal projects and custom domains, but commercial use requires a paid plan.

Host	Free launch URL	Custom domain on free plan	Paid/Stripe fit	Use when
Vercel Hobby	*.vercel.app	Yes	Poor fit for paid access because Hobby is non-commercial	You want the smoothest personal/non-commercial launch
Netlify	*.netlify.app	Yes	Good for a small commercial static site within usage limits	You want the least awkward zero-cost path from personal site to paid offer
Cloudflare Pages	*.pages.dev	Yes	Good for commercial static hosting and later Cloudflare-native controls	You want DNS, hosting, and access-control options in one ecosystem
GitHub Pages	*.github.io	Yes	Poor fit for an e-commerce/SaaS-like site	You want a public project/personal site tied closely to GitHub

Domain Decision

The current domain decision is:

• halotj.com as the owned canonical domain
• *.vercel.app as the temporary deployment URL

The fallback free-hosted domains are:

• halotj.vercel.app
• tjchalokia.vercel.app
• the generated Vercel project deployment URL

Use a community subdomain only if owned-domain registration is deferred:

• halotj.is-a.dev
• tjchalokia.is-a.dev

The durable asset is the owned domain plus the Git repository. Vercel is the first host, not the thing the site depends on forever.

Stripe Decision

Stripe can be added without rebuilding the whole site if payment is initially manual.

The first paid experiment should use:

• Stripe Payment Links for checkout
• Stripe Customer Portal for subscription management
• manual access to a private repo, folder, or download

Automated per-seat access requires a real entitlement system. That means identity, subscription state, webhooks, storage, and revocation. MkDocs should not pretend to solve that.

The upgrade ladder is:

1. No paid access: the public site contains only writing, resume, user manual, and contact.
2. Manual paid access: the public site links to Stripe Payment Links; fulfillment happens by hand.
3. Semi-automated access: Stripe webhooks update a subscriber list or private repository invitations.
4. Automated access: a small authenticated app checks subscription entitlements before serving private materials.

Do not put secret keys, private skill files, or customer-only downloads inside the MkDocs public build.

Versioning Decision

Use Git for website history.

Use mike later only if the skill library develops release lines such as:

• skills/0.1
• skills/0.2
• skills/latest

Website versioning before a stable product line would create ceremony without improving trust.

For now, use this workflow:

1. Draft pages in docs/.
2. Run mkdocs build --strict locally.
3. Commit source files, not the generated site/ directory.
4. Let the host rebuild from the repository.
5. Tag meaningful public launches as site-v0.1, site-v0.2, and so on.

When paid skills exist, split the workflow:

• website releases describe the public site state
• skill releases describe paid content state
• payment/subscriber state lives outside Git

Only introduce mike when old skill docs need stable URLs after the current docs move on.

Ownership Decision

Own the site through:

• halotj.com
• the GitHub repository
• local Git clones
• release tags

Treat hosting as replaceable. If Vercel becomes the wrong host later, rebuild the MkDocs site and point halotj.com at a new static host.

Launch Checklist

Do these in order:

1. Buy halotj.com and enable auto-renew.
2. Create a standalone Git repository from this directory, not from the parent workspace root.
3. Confirm these files exist:
4. mkdocs.yml
5. requirements-docs.txt
6. netlify.toml
7. vercel.json
8. docs/
9. Run mkdocs build --strict.
10. Push the source files to GitHub.
11. Import the GitHub repository into Vercel.
12. Confirm Vercel reads vercel.json.
13. Deploy once on the generated *.vercel.app URL.
14. Add halotj.com to the Vercel project.
15. Set site_url in mkdocs.yml to https://halotj.com/.
16. Commit and push the site_url update.
17. Deploy again and verify HTTPS.
18. Tag the first public release as site-v0.1.
19. Add the public URL to the contact surfaces that matter.

Done Criteria

The first public launch is done when:

• local mkdocs build passes
• the site deploys from a GitHub repository to Vercel
• the homepage, user manual, resume, writing index, and contact route are coherent
• the public URL is added to site_url in mkdocs.yml
• paid-access copy is absent or clearly marked as future/manual
• the generated host URL is stable enough to share

The custom-domain launch is done when:

• halotj.com is registered
• DNS verifies
• HTTPS is active
• site_url points at https://halotj.com/
• old host URLs redirect or are no longer shared