I am Sajan Acharya, a Senior Software Engineer in Kathmandu. Choosing Next.js for production is less about hype and more about fit: your SEO goals, your team’s React depth, your hosting constraints, and how much of the product must ship as crawlable HTML. This how-to walks through the questions I ask clients before we commit a roadmap to Next.js—or politely recommend something else. Framework choice is a product decision wearing an engineering badge, and treating it as fashion is how roadmaps quietly burn six months.
Next.js is still React. That continuity is its strength when your designers and engineers already think in components. It becomes a liability when nobody on the team understands server rendering, caching, or Node deployment. Production is where those gaps surface as outages, stale pages, or silent SEO regressions. If you already know you need specialist delivery, my Next.js developer services describe how I run discovery and build. A short paid spike often answers more than a month of slide decks.
Match product surfaces to framework strengths
Ask what percentage of traffic lands on public marketing or content pages versus authenticated app shells. If organic search and shareable URLs matter, Next.js earning its keep is easier to justify. If you are building a strictly private tool behind login with no indexing goals, a Vite SPA plus a separate marketing site can still be rational—especially for small teams with limited ops appetite. Be honest about which surfaces create revenue; that honesty decides whether one codebase or two is cheaper over three years.
Also list integration needs: auth, payments, file uploads, multi-tenant dashboards, and CMS-driven pages. Next.js shines when you want one repo for content routes and application routes with shared design systems. It is weaker when your organization mandates a non-Node edge runtime your dependencies cannot meet, or when your backend team refuses any BFF patterns and forces awkward client-only calls for everything. Write those constraints down before someone sells the team on a demo that ignores them.
Evaluate team skills and operational readiness
Production Next.js rewards engineers who can reason about server components, fetch caching, and environment secrets. If your squad is strong in client React but new to server-first patterns, budget training time or senior pairing. Observability matters too: you need logs, error tracking, and performance budgets on key templates. Hosting on Vercel is simple; self-hosting on Node containers is fine when your platform team owns TLS, scaling, and image optimization alternatives. Choosing the framework without choosing who owns deploys at 2 a.m. is incomplete.
I also ask about release culture. Can you ship behind feature flags? Do you have staging that mirrors production caching? Are designers comfortable reviewing server-rendered HTML states, not only client demos? Teams that only validate the happy path in the browser tend to ship SEO and caching bugs that take weeks to notice. Operational maturity is part of the Next.js decision even when nobody puts it on the comparison spreadsheet. If your answer to most of those questions is no, plan enablement work into the same quarter as the framework adoption—otherwise you will blame Next.js for process debt it did not create.
- Clarify SEO and indexing goals for public routes before picking the stack
- Inventory React skill depth and willingness to learn App Router patterns
- Decide Vercel versus self-hosted Node early to avoid mid-project surprises
- Confirm auth, CMS, and API constraints that affect rendering strategy
- Estimate migration cost if you already run Pages Router or a SPA
- Define success metrics: CWV, conversion, and deploy frequency—not stars on GitHub
Greenfield versus migration realities
Greenfield products should start on the App Router unless a hard constraint blocks it. Migrations are different. A large Pages Router codebase with custom document hacks, legacy data fetching, and brittle tests should not be rewritten in one heroic sprint. Prefer incremental moves: shared UI packages, new routes on App Router, and a cutover plan for high-traffic SEO pages. For sequencing details, use how to migrate from Pages Router to App Router. The cost of dual-running briefly is usually cheaper than a big-bang outage.
When SEO is a primary reason for choosing Next.js, treat technical foundations as part of the same decision. Rendering mode, metadata, and sitemaps are not phase-two polish. I expand that playbook in how to build SEO-friendly apps with Next.js. Choosing the framework without choosing those practices usually produces a fast UI that search still ignores. Budget content and engineering together if organic acquisition is a stated goal.
When I advise against Next.js
I push back when the team needs a tiny static brochure with no React interactivity—plain HTML or a lighter static generator may win. I also push back when the product is a mobile-first native app with a thin web admin and no content strategy. And if your company standardizes on another full-stack framework with existing platform investment, switching solely for trend reasons burns trust. Saying no early is a Senior Developer service, not a missed sales opportunity.
From Kathmandu I work with startups and product companies who need honest trade-offs, not framework evangelism. If your checklist says Next.js is the fit, the next step is a thin spike: one marketing route, one authenticated route, metadata wired, and a deploy pipeline. Measure build time, cold starts if relevant, and Lighthouse on that spike before you migrate the whole product. If you want help running that spike or reviewing an existing decision, contact me with constraints, timeline, and the pages that must rank. We can decide with evidence instead of vibes.