GSoft Consulting
Web Development

Why We Standardised on Next.js for Every Client Project

AA

Ahmed Anis

CTO

18 July 2024

6 min read
Why We Standardised on Next.js for Every Client Project
Web Development

Standardising on a single framework is an unconventional decision for a consultancy. Most shops pride themselves on being technology-agnostic, recommending 'the right tool for the job.' We tried that model. What we found was that the overhead of maintaining deep expertise across five frameworks — keeping hiring pipelines filled, maintaining starter templates, keeping engineers current — was eroding delivery quality. In July 2024, we made the call: Next.js for all new web projects.

The Reasoning

  • Full-stack in one repo: Next.js covers UI rendering, API routes, server-side logic, caching, and edge functions. For most product teams, this eliminates the frontend/backend split that creates coordination overhead.
  • Deployment model is production-ready: Vercel deployments with preview URLs, automatic SSL, edge CDN, and ISR work with zero configuration. We don't spend client budget on DevOps setup that Next.js solves for free.
  • App Router + RSC is architecturally sound: React Server Components are a genuine improvement to the component model for data-heavy applications. The App Router's colocation of data fetching with rendering eliminates the prop-drilling and context abuse that plagued SPA architectures.
  • Ecosystem depth: The Next.js community produces high-quality third-party integrations, UI libraries with RSC support, and documentation. When a client has a specific requirement (analytics, payments, auth), there's almost always a well-maintained Next.js integration.

The Tradeoffs We Accepted

ℹ️ When we still reach for something else

We use Astro for pure content sites with no dynamic functionality. We use React Native for mobile. We use Hono or Express for standalone API services that don't have a UI component. Next.js is our default, not our only tool.

  • Vercel lock-in risk: We're honest with clients about this. Most of our client projects live on Vercel, and switching would require migrating ISR and edge middleware behaviour. We accept this tradeoff for the operational simplicity it buys.
  • Overkill for pure APIs: Next.js adds overhead for services that don't have a frontend. For backend-only work, we use standalone Node.js services.
  • App Router learning curve: Engineers coming from Pages Router or other frameworks need 2–3 weeks before they're productive with the App Router mental model.

100%

New web projects use Next.js

35%

Faster project kickoff vs multi-framework

18 mo

Since the standardisation decision

0

Regrets (so far)

Tags

Next.jsReactArchitectureStrategyFull-Stack

Work with us

Ready to build your product?

We help product teams across the UK, Netherlands, Australia, and North America ship faster without compromising quality. Let's talk about your project.

Talk to our team →