The old Nuxt codebase already proved the business case: SlashCode can design, build, and ship. The next step is not to copy every component into a new framework. It is to choose the surfaces that still matter and rebuild them in a way that stays maintainable.
That is why the Astro migration begins with the blog.
Why start here
A blog is a high-signal feature for a migration:
- it exercises routing, layouts, metadata, and content loading
- it benefits immediately from static generation
- it lets the new design language show up in public before every page is rewritten
This keeps the first Astro release small without making it feel disposable.
What we are not bringing over
The old app included a wide UI layer around dropdowns, form helpers, toasts, and other shadcn-style abstractions. Some of those patterns may still earn a place later, but they do not need to arrive on day one.
For the blog we only need:
- a shared layout
- a header and footer
- content collections
- simple article cards
- readable prose styling
Everything else stays out until it solves a real problem.
What this unlocks next
Once the journal is in place, the rest of the Astro migration gets easier. We already have a shared shell, brand tokens, and a clean path for adding more sections without dragging legacy clutter forward.
That is the real win: not just moving frameworks, but reducing surface area while we move.
