A personal platform for hosting AI experiments, 3D print projects, and creative tools — built to share with an inner circle first, then the world. Designed from day one to scale, link, and grow.
v1 target: Q3 2026
hosted · Vercel + Railway
auth · shared pw → open
3 pillars · N modules
Purpose
Why this exists
Three interlocking goals that shape every decision in this architecture.
Share what I build
A single URL for every project. Inner circle first. Public when security is right. Tools, games, models — all in one place people can actually use.
Stay on the wave
Building this forces the crawl → walk → run progression in AI. Search, research, build local, host live. Each module pushes the skill ceiling.
A creative outlet
Replace doom-scrolling with building. Something to do in the evening, involve Brittani, and feel proud of. The usage limits are a feature — natural off switch.
Design principles
What guides decisions
Six rules that apply to every layer of this system.
01
Linkability first
Every module and post gets a stable URL and metadata from day one. The knowledge graph drops in later without a rewrite.
02
Embed, don't redirect
HTML tools load inside the site. Users never leave. Android or external apps get a module page with a link out — never the default.
03
Archive, never delete
Old modules go to archive state. Nothing disappears. The admin cockpit tracks every state: idea → in progress → live → archived.
04
Design for scale today
Parked features (cross-module data, analytics, knowledge graph) need hooks in the schema now. Don't build them, but don't block them either.
05
Security proportional to risk
A game score and a financial dashboard are different threat models. Each module defines its security level; architecture enforces it.
06
Low friction to add
Adding a module should be a conversation and a few config values, not a code deploy per item. The shell handles the rest.
Roadmap
Three phases
Phased delivery from inner circle MVP to public platform.
Phase 1 — Day 1
Inner circle MVP
Shared password auth
3 pillars live (Personal, Business, 3D)
HTML module embedding
Admin cockpit + tracker
Status badges, reactions
Bug reporting (manual)
Custom domain (camkennedy.ai)
Phase 2 — Growth
Public ready
Auth removed (open access)
Multiplayer / room-link modules
Real backend (Railway)
Save states for tools
AI/fuzzy search
Per-pillar password option
Error bot (Discord webhook)
Phase 3 — Platform
Knowledge layer
Blog / digital garden
Knowledge graph view
Agent bug pipeline
Cross-module data hooks
Analytics (post-bot-trust)
Admin idea tracker module
SSO (if warranted)
Key constraint to design around: The blog and knowledge graph sit alongside camkennedy.ai, not inside a pillar. Every piece of content needs a stable URL and tag metadata from Phase 1 so the graph layer drops in during Phase 3 without a rewrite.
Interactive explorer
Architecture layers
Click each layer to explore the decisions, properties, and open questions for that level of the system.
Authentication
Shared password on launch (CamFriends / TEST123). Removed once public trust is established. No SSO at site level — per-module only if warranted by data sensitivity.
shared pw · Day 1removed on public launch
Admin cockpit
Jarvis-style command view. Only visible to Cam. Tracks module progress (idea → in progress → live → archived), cross-pillar idea flow, and surfaced metrics.
admin modemodule trackerquick-capture (Phase 2)
Global site features
SearchAI/fuzzy across all modules and pillars. Phase 1: basic text. Phase 2: semantic/AI-powered.
About pageMinimal presence — who this is, what the site is for. Not a portfolio, not a résumé.
ContactDiscord or email (TBD). Accessible from every page.
Module status badgesNew · Updated · Beta. Visible on grid cards and module pages.
Archive stateModules are never deleted — only archived. Archive is hidden from users, visible in admin.
ReactionsEmoji reactions and share links per module. No comments (bot risk). No global leaderboard.
Error alertingDiscord webhook or email bot when something critical fails. Phase 2 — low effort, high value.
Personal AI
Games, fun tools, creative experiments. Where most modules will live initially.
live at launch
Business AI
Work-adjacent tools. Often spawns from something built for Personal that has professional use.
live at launch
3D models
In-browser 3D viewer, download STL, photo + description. Gallery pattern, not app pattern.
live at launch
Pillar rules — applies to all three
VisibilityLive or "coming soon" display. Admin can hide a pillar entirely from the nav.
Per-pillar authEach pillar can add its own password layer, independent of site-level auth.
MobileResponsiveness is decided per module, not per pillar. Pillar shell is always responsive.
ConnectionPillars are visually unified. Data sharing hooks built in for Phase 3 — not wired in Phase 1.
Coming soon statesFuture pillars (Blog) show as "coming soon" in nav — not hidden, not broken.
Every time a new module is started in Claude, run through these four question groups before writing a line of code. Answers drive the tech stack, security posture, and hosting needs.
Identity & type
→What type? Game / Tool / Model / Collab. Type drives which metadata fields appear on the module page.
→Single or multi-user? Determines whether room/session logic is needed.
→Mobile: Must-have, nice-to-have, or N/A? Decide before building — retrofitting responsive is expensive.
Access & visibility
→Hidden from users? Or visible with optional module-level password?
→Public shareable links? e.g. a planning poker room link. Needs URL generation + expiry logic.
→User-facing admin role? Room management, kick, reset — needed for collab tools. Not the same as site admin.
Data & state
→Fresh start or save state? Save state requires a backend and user identity model.
→Where does data live? Client-only / Vercel KV / Railway DB / Anthropic artifact storage — pick based on sensitivity and persistence needs.
→Security sensitivity level: Game score (low) vs. financial dashboard (high) require very different approaches. Ask explicitly — don't assume.
→Cross-module data? Flag now if this module's data might feed another. Don't wire it — just leave the schema hook.
Tech & connectivity
→AI-connected or static? Claude API calls require API key management and cost awareness per module.
→Where is it hosted? HTML embed (iframe in-tab), own route in shell, external link, or download.
→SSO needed? Only ask if data sensitivity warrants it. Most modules don't.
Module page — the pre-launch screen
Every module gets a dedicated page before the experience launches. The page serves three jobs: inform (what is this, who is it for), engage (reactions, share), and launch (embed or link out).
Hero sectionModule name, type tag, description, status badge. The pitch in under 3 lines.
Info chipsPlayer count, mobile support, AI-powered flag, share link availability. Auto-generated from module metadata.
Launch mechanismHTML tools: embedded iframe, stays in tab. 3D models: viewer renders on page. External/native: description + link out button.
ReactionsEmoji reactions (heart, fire, star etc.). Share button. No comments. Counts visible to all.
EvolutionModule pages evolve over time — more screenshots, changelogs, related modules — without changing the shell.
recommended · start here
Vercel
$0/mo to start
✓ Dead-simple GitHub deploys
✓ Free HTTPS + custom domain
✓ Serverless functions (API routes)
✓ Vercel KV for light data
✗ No persistent backend
✗ Cold starts on free tier
Best for: HTML tools, site shell, simple API routes, Phase 1 everything
Railway
$5–20/mo
✓ Real persistent backend
✓ PostgreSQL + Redis included
✓ WebSockets (multiplayer)
✓ Docker support
✗ Monthly cost even idle
Add when: first module needs save states, multiplayer, or a real DB
GitHub Pages
$0/mo always
✓ Free forever
✓ Custom domain
✗ Static only — no backend
✗ No server-side logic
Only viable if no module ever needs a backend. Skip — go Vercel.
VPS (DO / Hetzner)
$6–12/mo
✓ Full control
✓ Run anything
✗ You manage SSL, updates
✗ Highest maintenance overhead
Phase 3 consideration when running 5+ persistent services.
Recommended path: Start on Vercel — free, instant, custom domain ready. Add Railway as a companion service when the first module needs a real backend (multiplayer, save states, user data). Pair them: Vercel handles the frontend + edge functions, Railway handles the persistent layer. Total cost stays under $20/mo for well into Phase 2.
Knowledge graph / digital garden
The blog sits alongside camkennedy.ai — not inside a pillar. Posts can be about anything: AI, faith, family, building things. The graph layer connects posts to modules they inspired, posts to each other, posts to external sources. Users can explore the web of ideas, not just scroll a feed.
Stable URLsEvery module and post needs a permanent, linkable address. Design this in Phase 1 even if the graph view is Phase 3.
Metadata structureTags, topics, related IDs — so nodes can reference each other. Add to the module schema now.
Link typesModule → post, post → post, post → external, post → module. Four edge types minimum.
Graph viewNeural-net visual. Nodes + edges, click to explore. Reference: Obsidian graph view as the UX target.
Key insightDon't build the graph in Phase 1. Do plant the metadata hooks. The graph view drops in without a rewrite if the schema is right.
These are real decisions — not abandoned. They're deferred because building them now would be premature. Each has a trigger condition for when to revisit.
Admin idea tracker
Quick-capture, voice → idea, kanban inside admin cockpit. Trigger: when the module backlog exceeds 10 ideas and manual tracking breaks down.
Agent bug pipeline
Report → Claude reviews → Cam approves fix. Trigger: when bug volume justifies automation. Day 1 is email/form.
Analytics
Basic module open counts, engagement. Trigger: when bot traffic is manageable and privacy approach is defined. Low priority.
Cross-module data
Modules sharing state or feeding each other. Design schema hooks now. Trigger: when a specific use case demands it.
Error reporting bot
Discord webhook when something critical breaks. Trigger: Phase 2 launch. Low effort, high value — easy win.
SSO
Only warranted if a module handles data sensitive enough to need it (financial tools, personal data). Most modules never need this.
Technical architecture
System diagram
End-to-end view of the system — from domain to data layer — across Phase 1 (solid) and Phase 2 additions (dashed). Click any component for details.
Component notes
Key decisions explained
Rationale for the non-obvious architectural choices.
Why Vercel + Railway (not just one)?
Vercel is the best static/serverless host with zero ops. Railway adds the persistent backend (WebSockets, DB) that Vercel can't do. Together they cover Phase 1 and 2 without a VPS. Add cost only when a module demands it.
Why a Module Registry?
A config-driven registry (JSON or DB) means adding a new module doesn't require a code deploy. Update the registry → the shell reads it → module appears. Low-friction, no re-deploy per module.
Stable URLs — why it matters now
The knowledge graph in Phase 3 needs every module and post to be a stable, linkable node. If URLs change between phases, all the graph edges break. Design the URL schema once and freeze it.
Security model per module
No blanket security approach. Each module declares its sensitivity level at build time. Low: client-only, no auth. Medium: Vercel KV + session. High: Railway DB + per-module SSO. The shell enforces the declared level.
iframe embed — why not full routes?
Self-contained HTML apps embed cleanly in an iframe with no rewrite. The user never leaves the shell. Full routes are better for modules that need deep shell integration (admin, reactions, search) — use routes for those, iframes for isolated apps.
Cloudflare in front of Vercel
Cloudflare adds DDoS protection, WAF rules, and caching at the edge before requests even hit Vercel. Free tier covers Phase 1 and 2 comfortably. Also handles the DNS for camkennedy.ai and makes moving hosts later painless.
For your architect colleagues: The diagram separates Phase 1 (solid borders) from Phase 2+ additions (dashed borders). The core stack is intentionally minimal — Next.js or plain HTML on Vercel, a module registry in KV, Cloudflare in front. Railway is additive, not foundational. The data layer scales from KV → Postgres → Graph DB as use cases demand it, without changing the frontend contract.
action plan
How to build this without boiling the ocean
Every step tagged as permanent, throwaway, or evolves — so you always know what you're committing to.
Recommendation: Build a module first. Not the shell. The shell only matters when something lives inside it. Pick the module closest to done, get it working and shareable, then build the minimal frame around it.
Suggested order: Hot Takes Tribunal (already exists as HTML) → minimal shell → GitHub + domain → then scale.
Permanent — keep forever
Throwaway — scaffolding, replace later
Evolves — starts simple, gets better
Phase 1 · days 1–14
Prove it works
Get one real thing working and shareable. Resist adding features. The goal is a URL you can text Div that actually works.
01
Pick your first module and define it properly
Run the module checklist before writing a line of code
permanent1–2 hrs
›
Hot Takes Tribunal is the obvious pick — it already exists. Start a Claude conversation and define it using the module checklist.
Type: Game · Users: 2–8, multiplayer · Mobile: must-have
Data: stateless per game · AI: yes · Security: low
Embed: iframe in-tab
Permanent — this conversation becomes the source of truth for that module.
new module · from scratch
I am building a personal platform called camkennedy.ai — a site that hosts my AI experiments, games, tools, and 3D print projects. I want to define a new module for this platform before writing any code.
Please walk me through the following module checklist and record my answers as a structured markdown README I can save as the module spec:
IDENTITY & TYPE
- What type is this? (Game / Tool / Model / Collab / Other)
- Single user or shared/multiplayer?
- Mobile responsive: must-have, nice-to-have, or N/A?
ACCESS & VISIBILITY
- Should it be hidden from users until ready, or visible with optional password?
- Does it need to generate public shareable links (e.g. a room link)?
- Does it need a user-facing admin role (room management, kick, reset)?
DATA & STATE
- Fresh start every session, or does it need to save state?
- Where should data live: client-only, Vercel KV, Railway DB?
- Security sensitivity: low (game score) / medium / high (personal/financial data)?
- Should this module's data ever connect to another module? Flag if yes.
TECH & CONNECTIVITY
- Does it connect to AI (Claude API)?
- Can other devices join in real time (Jackbox-style)?
- How is it hosted: HTML iframe embed, full route, external link, or download?
- Does it need SSO?
Ask me one group at a time. After all answers are collected, produce a completed module README with a summary, the checklist answers, recommended hosting approach, and any security flags you spotted.
existing module · import & audit
Here is an existing project I want to define as a module for camkennedy.ai — a personal platform that hosts my AI experiments, games, tools, and 3D print projects inside a unified shell site.
Read the attached code carefully, then:
1. Infer as many of the module checklist answers as you can directly from the code (type, users, mobile, data model, AI usage, security level, embed approach, etc.)
2. Flag anything that concerns you from a security or architecture standpoint — exposed API keys, unvalidated inputs, assumptions that break when embedded in an iframe, missing rate limits, hardcoded URLs, etc.
3. Ask me only the questions you genuinely cannot answer from the code — don't ask things the code already makes obvious.
4. Produce a completed module spec as a markdown README I can save as the source of truth for this module going forward.
The README should include: module name, type, one-line description, full checklist answers, recommended hosting/embed approach, security flags, and any recommended changes before it goes live on the platform.
02
Set up GitHub
One repo — decide monorepo vs separate now
permanent1 hr
›
GitHub is permanent infrastructure. The structure decision sticks, so think before creating repos.
Recommended: Monorepo — camkennedy-ai/ with /shell, /modules/hot-takes etc.
Add a README.md per module folder with checklist answers — that's the module spec
The repo structure is permanent. 20 minutes of thought saves a painful migration later.
03
Deploy to Vercel with a temp URL
Get something live before you buy the domain
evolves1 hr
›
Connect GitHub → Vercel. Every push to main auto-deploys. You get a shareable URL before spending a dollar.
Test the iframe embed — make sure the module loads in-tab correctly
The Vercel URL is throwaway — replaced by camkennedy.ai. The Vercel connection itself is permanent.
04
Build the minimal shell
Nav, pillar tabs, module grid, module page — nothing more
evolves4–6 hrs
›
The mockup is the target. Resist building admin, search, reactions, animations. Hard constraint: no features not in the mockup.
Module metadata from hardcoded JSON config for now (becomes the registry later)
Use the architecture mockup HTML as the design reference in Claude
Visual design will evolve. The URL structure and module config format are what to get right now.
minimal shell build
I am building the Phase 1 minimal shell for camkennedy.ai — a personal platform that hosts my AI tools, games, and 3D print projects.
HARD CONSTRAINTS — do not add anything outside this list:
- Top nav: logo, pillar tabs (Personal AI / Business AI / 3D Models / Blog—soon), search button (non-functional placeholder), admin button
- Module grid: cards showing name, description, status badge (new/beta/updated), reaction count
- Module page: hero with name + description, info chips, launch button, about section, embedded iframe for the app
- Module metadata comes from a hardcoded JSON config (not a database yet)
- No admin cockpit, no working search, no reactions backend, no animations beyond basic hover states
URL SCHEMA TO USE (freeze this — do not deviate):
- Pillar pages: /personal, /business, /3d
- Module pages: /modules/[slug] e.g. /modules/hot-takes-tribunal
DESIGN REFERENCE: I will attach the mockup HTML — match the visual direction (dark theme, DM Serif Display + Instrument Sans + DM Mono, purple accent).
TECH: Plain HTML/CSS/JS or Next.js — recommend what fits a solo developer deploying to Vercel.
Start by confirming the URL schema and tech choice, then build the shell. Flag any decision you make that could be hard to reverse later.
05
Add shared password auth
Simple gate — deliberately throwaway
throwaway1–2 hrs
›
You need a gate before sharing the URL. Don't over-engineer it — it gets deleted in step 13.
Vercel Edge Middleware password check — ~20 lines of code
Store password in a Vercel environment variable, not in code
One shared password, no user accounts
Explicitly throwaway. Don't spend more than 2 hours on it — its lifespan doesn't justify more.
throwaway auth · vercel edge
I need a deliberately simple, throwaway shared password gate for my Vercel site. This will be deleted when the site goes public — do not over-engineer it.
REQUIREMENTS:
- Vercel Edge Middleware that checks for a shared password before serving any page
- Password stored in a Vercel environment variable (SITE_PASSWORD) — never hardcoded
- If no valid session cookie: show a minimal password form (matches my site's dark theme)
- If correct password submitted: set a session cookie and redirect to the requested page
- No user accounts, no database, no JWT — just a cookie check
- The admin route (/admin) should require a separate env var (ADMIN_PASSWORD) checked the same way
- Maximum ~30 lines of middleware code — I want to be able to delete this cleanly in one go later
Output: the middleware file, the password form HTML (inline in middleware or as a separate file), and the exact environment variable names to set in Vercel.
06
Buy camkennedy.ai + connect Cloudflare
Namecheap → Cloudflare DNS → Vercel
permanent1 hr
›
Buy the domain. Put Cloudflare in front (free tier). Point to Vercel. This is the moment it becomes real.
camkennedy.ai on Namecheap (~$15–20/yr) · Add to Cloudflare (free) · Update nameservers
The domain is the address — everything else can change. Cloudflare gives DDoS protection and caching for free from day one.
07
Send it to your inner circle
Div, colleagues, Brittani — real humans, real usage
permanent habitongoing
›
The first time you send the link is the real milestone. That feedback loop is more valuable than any feature.
Watch someone use it in person if you can — you'll see things no bug report catches
Don't fix everything immediately — triage and pick the one thing that matters most
Phase 2 · weeks 3–8
Make it real
Add infrastructure that makes the site feel intentional. More modules, proper data layer, admin cockpit, and the features that make it shareable beyond your inner circle.
08
Build the Module Registry
Config-driven — adding a module requires no code deploy
permanent3–4 hrs
›
Move modules from hardcoded to a config the shell reads — editing JSON, not code.
Phase 2a: modules.json in repo · Phase 2b: Vercel KV or Postgres when you want admin-UI editing
Freeze slug format now: /modules/hot-takes-tribunal
The slug/URL format is permanent. Storage mechanism evolves. Get the schema right, not the storage.
module registry
I need to build a module registry for camkennedy.ai — a config-driven system so I can add new modules without touching the shell code or doing a code deploy.
FROZEN URL SCHEMA (do not change this):
- Module pages: /modules/[slug] e.g. /modules/hot-takes-tribunal
- Slugs are kebab-case, permanent, never change once set
REQUIRED SCHEMA FIELDS (every module must have these):
- id: unique string
- slug: kebab-case, matches the URL
- name: display name
- pillar: "personal" | "business" | "3d"
- type: "game" | "tool" | "model" | "collab"
- status: "live" | "beta" | "wip" | "archived" | "coming-soon"
- embedUrl: path to the HTML file or null if external
- embedType: "iframe" | "route" | "external" | "download"
- description: one or two sentence string
- tags: string array
- chips: array of {icon, label} for the module page info row
- reactions: object with emoji keys and count values
- createdAt: ISO date string
- updatedAt: ISO date string
- relatedModules: slug array (for future knowledge graph — include now, leave empty)
- relatedPosts: slug array (same)
PHASE 2a: Start with a modules.json file in the repo root. The shell reads it at build time.
PHASE 2b: Show me how this same schema maps to a Vercel KV or Postgres table for when I want admin-UI editing — but don't build that yet.
Output: the modules.json file pre-populated with my current modules (Hot Takes Tribunal, Emoji Movies, Wordle Blitz, Snake Oil Inc., Anchor), a TypeScript or JS type definition for the schema, and the shell utility function that reads and filters the registry by pillar and status.
09
Add a second and third module
Stress-test the shell with variety — include a tool, not just a game
permanentper module
›
The shell only gets validated when it handles different types. Add one game + one tool + one 3D model.
Follow the module checklist for each — it catches questions you'll discover at 11pm otherwise
If any module needs a backend, that triggers step 10
10
Add Railway only when a module demands it
Don't provision infrastructure ahead of the need
permanent when added2–3 hrs
›
Trigger: first module that needs to persist data beyond a session, or needs WebSockets for real-time multiplayer.
Examples: agile planning poker (real-time rooms), FinOS (save state), live join code games
Vercel still handles frontend — Railway is additive, not a replacement
Once added, Railway is permanent. Everything needing a backend uses it.
11
Build the Admin Cockpit
Module tracker, idea backlog, status management
evolves4–6 hrs
›
Phase 2: protected page reading from module registry — update status, add ideas, archive. The Jarvis vision is Phase 3.
Stat cards: live / in-progress / ideas · Module list with edit, archive, hide controls
Protected by admin session separate from shared site password
Phase 2 is functional CRUD. Phase 3 adds quick-capture, analytics, the idea tracker as its own module.
admin cockpit · phase 2
I need to build the Phase 2 admin cockpit for camkennedy.ai. This is a protected page only I can access — it is not the public-facing site.
VISUAL DIRECTION: Dark theme, command-centre feel. DM Serif Display for headings ("The cockpit."), DM Mono for labels and data, Instrument Sans for body. Compact, dense, no wasted space. Think Jarvis, not a settings page.
PROTECTED BY: Admin session cookie (ADMIN_PASSWORD env var, separate from the shared site password). Already handled by middleware — just assume the user is authenticated if they reach /admin.
PHASE 2 FEATURES ONLY — do not add anything beyond this list:
- Stat row: three metric cards showing count of live modules / in-progress / ideas
- Module tracker: full list of all modules from modules.json with status indicator (live = green dot, wip = amber, idea = gray), pillar tag, and inline controls to: change status, toggle visibility, archive
- Idea capture: a simple text input to add a new idea entry to the registry with status "idea"
- No analytics, no charts, no file upload, no voice capture, no agent features — those are Phase 3
DATA: Reads from and writes to modules.json (or Vercel KV if the registry has already been migrated). Show me both options and let me choose.
Flag anything in this build that would be hard to extend in Phase 3 when I want to add quick-capture, analytics, and the idea tracker as its own module.
12
Add reactions + bug reporting
First social layer — no comments, just signals
permanent2–3 hrs
›
Reactions in Vercel KV (emoji + module slug + count). Bug reports via form → email or Discord webhook. Both per-module.
Pattern is permanent. Storage backend evolves.
13
Remove shared password — go public
Delete the throwaway scaffolding from step 05
delete throwaway30 min
›
When confident in what's live and each module's security — delete the site-level password entirely.
Remove Vercel Edge Middleware · Verify sensitive modules still have per-module protection
Admin cockpit stays behind its own separate auth — that doesn't go away
This step is literally deleting the throwaway auth from step 05. Satisfying.
Phase 3 · months 3+
Build the platform
The features that turn the site into something genuinely interesting. None of this is urgent — all of it is worth having.
14
Launch the blog + digital garden
Standalone — not inside a pillar
permanentongoing
›
Start with markdown files in the repo. Every post needs: stable slug, tags, optional relatedModules and relatedPosts arrays. Write before the graph view exists — content is the foundation.
The metadata schema you add to posts now is what makes the graph possible later without a rewrite.
Bug form → webhook → Claude API reads module code → proposes fix → admin review → approve → GitHub PR → Vercel deploy. Treat it as its own module project — it's the best showcase of the AI progression.
17
AI/fuzzy search
Semantic search across modules, posts, metadata
permanent4–6 hrs
›
Phase 2: Fuse.js fuzzy text match — fast, no backend. Phase 3: embeddings-based semantic search via Vercel AI SDK. Start simple, upgrade when content volume warrants it.
Step
Longevity
Effort
Why it matters
01 · Module definition
permanent
1–2 hrs
Source of truth for everything that follows
02 · GitHub
permanent
1 hr
Foundation — every file lives here
03 · Vercel deploy
evolves
1 hr
Temp URL now, real domain later
04 · Shell
evolves
4–6 hrs
Structure stays, design and features grow
05 · Shared password
throwaway
1–2 hrs
Deleted in step 13 when you go public
06 · Domain + Cloudflare
permanent
1 hr
The address — freeze it and never move it
08 · Module Registry
permanent
3–4 hrs
No code deploy per module
URL / slug schema
freeze forever
20 min
Moving URLs breaks the knowledge graph
The one thing to get right above everything else
The URL schema. Decide now: /modules/hot-takes-tribunal — whatever you pick, freeze it. Every other decision can be changed or undone. Changing URLs later breaks the knowledge graph, breaks shared links, breaks everything bookmarked. Twenty minutes of thought now saves a painful migration in Phase 3.