When we started building CalendarMe in early 2024, we evaluated several frameworks: Next.js, Remix, SvelteKit, and a plain React SPA with a separate API. We ended up choosing Next.js, and when we built Emailsdaily six months later, we didn't even consider alternatives. Here's why.
The honest pros
Server-side rendering out of the box. Our scheduling pages need to be fast — when someone opens a CalendarMe link, they should see content instantly, not a loading spinner. Next.js makes SSR the default rather than something you opt into.
The file-based router is genuinely good. Both our products have straightforward URL structures, and having the route map visible in the file system makes onboarding and maintenance easier.
API routes living alongside frontend code is convenient for smaller teams. We don't need a separate backend repository for simple endpoints. For CalendarMe's webhook handlers and Emailsdaily's email processing endpoints, this keeps things simple.
Vercel deployment is seamless. Push to main, get a production deployment. Preview URLs for every PR. This matters when you're a small team and don't want to spend time on deployment infrastructure.
The honest cons
The abstraction can be leaky. Understanding when code runs on the server vs. client isn't always intuitive, especially with the App Router. We've hit hydration bugs that took hours to debug.
Bundle size requires attention. It's easy to accidentally ship large client-side bundles if you're not careful about what you import where. We use bundle analysis regularly.
The pace of change is fast. Major versions bring breaking changes, and the ecosystem moves quickly. We've had to update patterns and approaches multiple times.
Why we'd choose it again
Despite the cons, Next.js gives us the best combination of developer experience, performance, and deployment simplicity for our use case. We're building SaaS products that need to be fast, SEO-friendly, and maintainable by a small team. That's exactly what Next.js optimizes for.
The key is being pragmatic. We don't use every new feature the day it launches. We let patterns settle, read the migration guides carefully, and upgrade on our own schedule. The framework is a tool, not a religion.