Why I Added Astro to My Stack (And Why It Challenged Everything I Thought I Knew)

I thought I had it all figured out.

TanStack Start for web apps. Hono.js for microservices. A clean, isomorphic stack that handled everything I needed as a freelancer. When I started taking on more design-centric static sites and blogs, I assumed I could just keep using what I knew. After all, TanStack Start supports static generation, right? The ecosystem was familiar. The patterns were comfortable.

Then a simple conversation stopped me cold.

The Friction I'd Been Ignoring

A friend asked about my blog — not the content, but the experience of building and maintaining it.

That question hit hard. My blog worked, but it felt like a constant workaround. I'd taken a framework built for complex, interactive applications and forced it to handle content. Markdown felt bolted on. Every new post pulled me back into app-developer mode instead of letting me focus on writing.

I had become so comfortable with my tools that I stopped asking the important question: Are these the right tools for the job?

The Question That Changed Everything

"What if the framework itself was designed for content first?"

That led me to Astro.

My first reaction was resistance. I was productive in TanStack Start. Learning something new felt like unnecessary backtracking.

But as I explored Astro, the appeal became clear:

• Zero JavaScript by default — Content ships as clean HTML, not a React bundle waiting to hydrate.
• Markdown as a first-class citizen — Drop .md files in a folder and get real blog posts instantly.
• Content Collections — Type-safe, organized content without building a custom CMS layer.
• Islands architecture — Use React (or other frameworks) only where interactivity is truly needed.

The best part? I could bring my existing React components with me. I wasn't abandoning my skills — I was simply using them more intentionally.

Framework Comparison: App-First vs Content-First

The Perspective Shift

This wasn't about replacing TanStack Start. It was about recognizing that different problems deserve different tools.

I wasn't losing productivity. I was gaining intentionality — choosing the right tool instead of forcing one tool to do everything.

What This Means for My Freelance Work

What I Wish I'd Known Sooner

Your tools should disappear so the content (or the experience) can shine.

When writing a blog post, I no longer want to think about routing, data fetching, or loading states. I want to focus on what I'm saying. Astro gives me that freedom for content-heavy work.

When building complex interactive experiences, I still reach for TanStack Start — it's unmatched there. The real skill is knowing the difference.

My Updated Stack

• TanStack Start — For web apps, hybrid projects, and anything with rich interactivity
• Astro — For content-driven sites, blogs, and portfolios
• Hono.js — For lightweight microservices and APIs

Three focused tools. Each doing what it does best. No more square pegs in round holes.

Lessons Learned

1. Friction is a signal — If something constantly feels like a workaround, it probably is.
2. Tools shape your thinking — The framework you default to influences how you approach every problem.
3. Specialization beats generalization — Using the right tool for the job almost always wins.
4. Your skills transfer — Learning Astro didn't mean abandoning React; it meant using it more strategically.
5. Right tool, right job — The best stack is the one that fits the actual project, not your comfort zone.

Conclusion

I didn't abandon TanStack Start — I added Astro to my toolkit. In doing so, I gained clarity about when to use each one.

The real win wasn't just better performance or easier content management. It was the mental shift toward intentional, specialized development.

If you're building everything with a single framework, pause and ask yourself:
Is the framework serving your content and users, or is your content serving the framework?

The answer might open up better ways of working.