Every studio has a default stack. Ours has three, and we pick between them based on the work — not the calendar.
When we reach for Astro
Marketing sites, editorial portfolios, anything where the page is mostly content and the interactivity is local. Astro ships near-zero JS by default, so LCP is green before we’ve made an effort, and the component model is friendly enough that a designer can write a section without breaking the build.
We’ve shipped Thames, DM Maler, Star Home London, and most of our education work on Astro. The pattern: content-heavy, conversion-aware, no need for a logged-in surface area.
When we reach for Next.js
Anything with a product surface — dashboards, account areas, search that needs to feel instant, multi-step funnels with shared state. Server components keep the bundle honest; client components live in the spots that actually need interactivity.
Richmond and the architecture portfolios sit here. So does anything with internationalisation that needs to be deeper than a top-level locale switch.
When we reach for Spring Boot
When the API has real domain logic — pricing rules, inventory state, multi-tenant data, anything that has to survive load and stay consistent. Java’s enterprise reputation is a feature here, not a liability. Pata Pura’s 18,000-SKU catalogue runs on it. So does LetsRentalCar’s reservation engine.
Why we don’t pick one stack and force the work into it
Because the cost of the wrong stack compounds. A marketing site built on Next.js carries a runtime it doesn’t need. A product built on Astro will eventually need a state model Astro doesn’t ship. A bespoke API built on a thin Node layer will start losing transactions the first time concurrency matters.
We’d rather audit the problem in week one than rebuild in year two.