Why We Use Next.js App Router for New Products
Next.js App Router gives a small team one framework for a fast landing page, a secure application, and the product work in between.
When we start a new project at Legacies - whether it's a one-page landing page or a full application - the technical choice has been the same for a few years now: Next.js, App Router.
One framework, every stage
A client starts with a presentation page. Six months later they want authentication, a dashboard, an API. With App Router we don't switch stacks - we add routes. app/services/page.tsx and app/api/contact/route.ts live in the same project, with the same conventions.
Server Components cut down on client-side JavaScript
For content pages - like this blog - we render on the server, read files directly from the filesystem at build time, and send the client only the HTML and CSS it needs. We don't need a separate CMS or an intermediary API for static content.
Clear conventions, fewer decisions
Folder-based routing, layout.tsx for shared UI, a metadata export for SEO without external libraries. The fewer infrastructure decisions we have to make per project, the more time is left for the part that matters - the product.
The tradeoff we accept
App Router has a steeper learning curve than Pages Router, especially around caching and the client/server boundary. But once internalized, delivery speed goes up - and for a studio that ships often, that matters more than initial familiarity.
For Legacies, that shared foundation also means a landing page can grow into a useful product without a forced rewrite. We can start with a clear public site, then add the small workflows a business actually needs as the work becomes more operational.