When a site migration gets too ambitious too early, the public-facing result often stalls. Too many pages, too many components, and too many inherited abstractions compete for attention.
Shipping the blog first is a way to avoid that trap.
The blog is a useful constraint
The journal gives us a compact problem set:
- list pages
- article pages
- metadata and dates
- reusable layout pieces
- content authoring in markdown
That scope is large enough to prove the architecture, but small enough to finish without carrying every legacy dependency along the way.
It also clarifies the design system
The old Nuxt app leaned on a UI kit for some interactions and wrappers. That can be productive in the right context, but it also introduces default decisions that can make a rebuild feel generic.
By starting with content, we can define the new visual system around:
- type
- spacing
- cards
- navigation
- article readability
Those primitives are more durable than a long list of imported components.
A small launch still counts
There is no penalty for starting with one strong surface. In fact, it usually creates momentum:
- content can go live sooner
- the codebase stays easier to reason about
- each later migration step has a proven pattern to follow
That is the shape of this Astro rollout: smaller slices, shipped with intention.
