Lessons Learned from Migrating to Core & Bootstrapping Courses
1. Boundaries Pay Off
Extracting auth, DB, storage, MDX, telemetry, and email into @gilgamesh2243/core
created a clean boundary.
Starting new apps (Labs, Courses, future projects) now feels lightweight instead of heavy.
2. Publishing Isn’t Scary
Going through GitHub Packages was more mechanical than risky.
- Build pipeline (
prepare
,dist/
) worked. - Scoping to
@gilgamesh2243/core
aligned imports and future-proofed usage. - The token/auth dance was the only friction point, now documented.
3. Start Simple
We realized we don’t need to ship Stripe payments on day one.
- Free courses + enrollments already give a working loop.
- Stripe fields remain nullable so upgrading later is painless.
- Shipping something usable fast > waiting on a perfect commerce system.
4. Incremental Wins Compound
- First, core scaffolded.
- Then, Labs refactored onto it.
- Then, Courses planned (free first).
Each step was small, but combined they unlocked a bigger outcome: a true multi-app platform.
5. Energy Management Matters
It’s 6:30a after starting at 5a — the code moved forward, but so did clarity.
Noticing when to pause (reflection, MDX note, “breather labs”) is part of the build process.
This ensures the architecture is thoughtful, not just reactive.
6. Future Guardrails
- Always design additive DB migrations.
- Keep core surface area tight.
- Avoid hard-coding product logic in the first version.
- Publish regularly (semver bumps) so packages remain healthy.
Closing Thought
This morning sprint proved: with a solid core, new apps become mostly assembly, not fresh invention.
That’s the leverage we were aiming for — and now it’s real.