· ToR Creative Studio · Engineering · 4 min read
How We Pick the Right Framework for Every Project
Clients ask us which framework is best. Wrong question. Here's the rule of thumb we use — from ecommerce stores to garages — and why the answer is almost never about the industry.
Every new project starts with the same question: what should we build it with?
Clients usually ask it as “which framework is best?” — as if there’s a ranking. There isn’t. There’s only fit. A framework is a tool, and you don’t ask which tool is best, you ask which one fits the job. Here’s the rule of thumb we actually use on client work, from ecommerce stores to auto garages.
The one-line rule
Follow the interactivity, not the industry.
Don’t pick a framework based on what the business is. Pick it based on what the website does. Three buckets cover nearly everything:
- Money, accounts, or state involved (cart, checkout, dashboards, logins) → Next.js
- People mostly read it (pages, menus, portfolios, blogs) → Astro
- Background work (APIs, webhooks, scheduled jobs, lead pipelines) → vanilla Cloudflare Worker
That’s it. That’s the whole philosophy. Everything below is just that rule applied.
The cheat sheet
Ecommerce → Next.js. Cart, checkout, inventory, order emails — that’s state, and state is what Next.js is for. The one exception: a pure catalog with no cart (customers buy via a link or WhatsApp) can be Astro.
Restaurant → Astro. Menu, hours, location, photos — that’s content. Take reservations through an embed like OpenTable or a simple form. Only reach for Next.js if bookings need customer accounts, which most restaurants don’t.
Garage / auto shop → Astro. Services, pricing, reviews, a quote form. Same shape as a restaurant: content plus a form, not an app.
Business directory → Next.js. Search, filters, listing accounts, saved items — that’s an app wearing a website’s clothes.
Nonprofit / community → Astro. Mission pages, event listings, donation links through embeds. Content all the way down.
Agency / marketing site → Astro. This very site is Astro. Fast, cheap to host, great SEO, almost no JavaScript shipped.
SaaS / product → Next.js. Dashboards, authentication, real-time state. If users log in, it’s Next.js.
Portfolio / blog / docs → Astro. The less JavaScript you ship, the faster it loads and the cheaper it runs.
Events → Astro — unless you’re doing real ticketing with customer accounts, in which case it’s Next.js.
Throwaway landing page → vanilla Worker. A single file, no framework. Don’t over-engineer a flyer.
Two modifiers
1. Does the client need to edit their own copy? Then it’s Astro plus a CMS (we use EmDash, Cloudflare’s Astro-native CMS). A CMS is the answer to exactly one question — “can I update the text myself?” — never add one just in case.
2. Does the client demand WordPress? Then it’s WordPress, full stop. Different stack, different pricing, their call. Some clients have internal teams built around it, and that’s a business decision, not a technical one.
The tiebreaker
When you’re torn between Astro and Next.js, ask one question: can this page work as static HTML with a form?
Yes → Astro. Does it need to remember who you are, what’s in your cart, or what you did last visit? → Next.js.
Why this matters to you
The wrong framework doesn’t just feel wrong — it bills wrong. An Astro site costs less to build, less to host, and loads faster. A Next.js site earns its weight the moment there’s real interactivity. Picking by habit instead of by fit means your clients either pay for complexity they don’t need, or outgrow a site that can’t do what their business requires.
We’d rather have the argument about frameworks once, up front, than the argument about rebuilds later.