Why We Chose Astro for Tools.Town — and What We Learned After 150+ Pages

When we decided to rebuild Tools.Town from scratch, the first question was the framework. We’d been on Next.js, and it was fine — but “fine” wasn’t the bar we wanted.

Here’s the full picture: what we chose, why, and what building 150+ pages on Astro taught us.

The problem with our previous setup

We had a Next.js app with a growing number of tool pages. Each tool had its own pages/tools/[slug].tsx file — hand-crafted, inconsistent, and increasingly hard to maintain. Adding a new tool meant copying and editing a previous page, drifting further from consistency each time.

Three problems were compounding:

1. No single source of truth for tool metadata (name, description, SEO, category)
2. Too much JavaScript shipped for pages that were mostly static
3. No structured content layer — everything was hardcoded JSX

Why Astro

After evaluating options (including sticking with Next.js but adding a content layer), we landed on Astro for three reasons:

1. Content Collections with Zod validation

Astro’s content collections let us define a schema for tools, categories, and articles — and validate every MDX file against it at build time. Adding a new tool now means dropping a single .mdx file; the page, SEO metadata, sitemap entry, and search index all flow from it automatically.

No more copy-paste pages.

2. Zero JS by default

Astro ships HTML. No JavaScript unless you explicitly add a React/Vue/Svelte island. For a tool site where most content is static (categories, about, learn articles, API docs), this is a big deal:

• Smaller bundles → faster load times → better Core Web Vitals
• Only the tool calculator components (React islands) ship with JS
• Everything else: pure HTML + CSS

3. Hybrid rendering

With output: "server" and per-page export const prerender = true, we can mix:

• Static: category pages, blog posts, learn articles — built at deploy time, served as HTML
• SSR: API reference pages, dynamic tool pages — rendered on request

The Cloudflare adapter handles this seamlessly at the edge.

What surprised us

Content collections are powerful but have dev server quirks. New collection directories sometimes require a dev server restart to register. The data-store caching in Astro 5 is fast, but the file watcher doesn’t always catch brand-new folders. This trips you up once; then you know to restart.

MDX + React islands is the right boundary. We use MDX for all content (learn articles, blog posts) and React for interactive tool islands. The boundary is clear: MDX = content, React = interactivity. Never mix them. This discipline kept the codebase clean.

Tailwind v4 with @theme instead of tailwind.config.js is excellent. No config file — tokens go in the CSS file’s @theme block. It’s a better mental model and the HMR is faster.

What we’d do differently

Start with the schema, not the UI. We designed components first in our original build and retro-fitted the content schema later. In the rebuild, we flipped the order: define the MDX schema first, then build the page templates that consume it. Much cleaner.

Don’t add apiDocs as a separate collection when tools already carry API data. Early in the rebuild, we created a separate apiDocs content collection for API reference pages. We ended up moving all that data into the tools collection’s api: block — one source of truth, no sync overhead.

The result

150+ pages, Lighthouse 98+ on mobile, sub-500ms TTFB on Cloudflare’s edge network, and a codebase where adding a new tool is a 20-minute task rather than a half-day one.

Astro was the right call.