Full Stack Survey → the Workshop Cut
memory/reference_stack_inventory.md · prospects/jobhub/workshop-stack-decision.mdPart 1 — The full stack, by layer
The survey's own finding
Layers 1–9 are commodity — anyone can buy them. Layer 10 is the product. It's why the same tools produce different results here, it's what transfers to a client, and it's what a syllabus can't be copied from.
Part 2 — The filter
Every candidate scored on one question: capability delivered ÷ setup cost for someone with zero technical background. Anything that adds an account, a console, or a concept without unlocking a visible new power got cut.
1 · One platform, not best-of-breed per layer. We run Neon + Supabase + Firebase because each wins its niche. A beginner needs one login. Firebase wins on consolidation alone: database + storage + auth + hosting behind a Google account they already have, in a visual console where progress is seeable.
2 · No layer that only pays off at scale. n8n, Vercel, Redis, ZenRows, Playwright, worktrees — real capability, invisible inside six hours.
3 · Teach the method, not the tool list. Layer 10 transfers to any assistant on any stack, and it's what actually makes someone effective.
✅ In — taught
- AI assistant — Claude / ChatGPT / Gemini (their choice)
- Firebase — Firestore + Hosting (+ Storage as needed)
- The browser — everything runs in it
Total footprint: two accounts, one browser.
⚠ Stretch — session 4 / fast rooms
- Connectors (Gmail, Calendar, Drive/Sheets) — highest wow available
- GitHub — version safety + recruiter-visible portfolio
- n8n / scheduled automations — things that run without you
✕ Out — ours, not theirs
- Neon · Supabase · Vercel · Cloudflare
- Elestio / Hetzner VMs · Redis
- Playwright · ZenRows · Apify
- Next.js / React / Tailwind toolchain
- Monday · Notion · Green Invoice
- MCP authoring · worktrees · Python layer
Part 3 — Layer 10, translated for participants
| Our practice | Workshop language | Session |
|---|---|---|
Context hierarchy (CLAUDE.md) | The context file — CV, target roles, standing instructions read every time | 1 |
Codified corrections (feedback_*.md) | Standing caveats — corrections written in once, never repeated | 2 |
| Verification discipline | Make it prove it — demand real output, never accept "done" | 2 |
| Voice / screenshot input | Feed it reality — record and screenshot instead of describing | 2 |
| Skills (repeatable procedures) | Save your winning prompts as reusable recipes | 2 |
| Goal acceptance criteria | Define "done" before starting — the plan prompt in every recipe | 3 |
| State continuity (session log) | The project notes file that lets you resume where you stopped | 3 |
| Deliverables as URLs | Ship a link, not a file — the interview artifact | 3 |
Part 4 — What we run the cohort on
Invisible to participants, zero new tooling for us: mockups on *.octomonic.com for handouts and the syllabus · WhatsApp (Evolution API) for reminders and the no-show chase · Monday for cohort tracking · Google Calendar for scheduling · Firebase for a graduates gallery if that direction lands.
The one open decision
Connectors. Adding Gmail/Drive moves a graduate from "built a tool" to "my assistant works my inbox" — a materially bigger interview claim and the strongest hook into the corporate product. It costs about an hour and carries the highest in-room failure risk (OAuth consent screens are where beginner rooms fragment).
Recommendation: keep it out of the pilot, run it as the session-4 upsell once the three-session flow is proven. Revisit with the first cohort's friction data.