When a founder inherits a shaky Next.js — or "Next.js-shaped" — SaaS, the first agency sales call often pitches a full rewrite. Previous shop gone, deploys scary, AI features stuck behind a brittle front end, nobody sure which cloud account owns production. Sometimes a rewrite is right. Often it freezes revenue for months while the team rediscovers every edge case the old system already handled for good reasons. This post is a decision framework for founders hiring an agency for web product work: when to stabilize and modernize in place, when a strangler rewrite is justified, and what a responsible engagement looks like before anyone opens a blank repository. The goal is not purity. It is twelve more months of shipping without fear — and without paying for a second pitch deck disguised as engineering. Bring the deploy story you fear to the first call.
Stabilize first when the product still takes money
Rescue playbooks for inherited SaaS converge on the same opening moves: get the repository, cloud, domain, and data into accounts you own; make one safe production change so the machine works again; then add tests, CI, and monitoring where money breaks ( Eight Mile on rescuing a SaaS someone else built ). Incremental modernization keeps shipping value while you retire risk screen by screen ( modernize a legacy SaaS without a rewrite ). If customers pay and demos are on the calendar, a big-bang rewrite is a business risk, not a purity upgrade. Ask the agency for a written audit and a ranked risk list before you entertain a rewrite quote. "We would rather start clean" is not a risk analysis — it is a preference that may cost you a quarter of roadmap while competitors ship.
When incremental rescue or strangler beats a greenfield
Prefer incremental work when domains are messy but understandable, data is trustworthy, and the roadmap needs continuous delivery. The strangler pattern — reverse proxy in front, route-by-route cutover, feature flags, dual-write where needed, fast rollback — is the standard shape for live products ( keeping a live app up during a rewrite ). Modernization guides for Next.js SaaS in 2026 make the same point: put the new app in front of the old one and move paths without stopping the world. A Pages Router to App Router migration is also not a rewrite. Both routers can coexist in one Next.js application; inventory routes and port them while features keep shipping from the same trunk. An agency that opens a months-long migration branch with no production releases is optimizing for billable archaeology, not for founder outcomes. Demand vertical slices you can roll back in minutes, with metrics you already watch (errors, checkout success, login failure rate).
When a rewrite or platform escape is justified
Rewrite or escape when you cannot safely change the system, the platform is non-portable — builder lock-in, auth tied to a subdomain you do not control, a schema with no migrations — or engineers refuse to work in the codebase because every change is weeks of archaeology. Greenfield is cheaper when there are few users, no paying customers, and no unreplayable data. Strangler overhead (proxy, flags, dual-write, auth bridging) is real cost; do not pay it for a prototype nobody depends on. Even then, sequence ownership first: GitHub, cloud billing, DNS, secrets, database backups, Stripe webhook endpoints. A rewrite on infrastructure you do not own is still rented. Day-one ownership is part of rescue, not a nice-to-have after the new launch party. Transfer accounts before you fund parallel builds.
How to brief the agency so you do not buy theatre
Put success in writing: reversible releases on a cadence, not a single cutover date. Require observability, staging parity with production secrets management, and a kill switch for each migration slice. Separate "make deploys boring" from "add AI features." Bundling them hides which work reduces risk and which work is a product bet with evals and human-in-the-loop. Refuse rewrite pitches that skip reading the existing code. A competent rescue team will walk the repository and the deploy story you fear before they sell a blank canvas. Ask for the first production change they would make this month if you hired them tomorrow. Vague answers are a signal to keep interviewing until someone can name a boring, reversible first step.
What CodeFlamme asks on week one
Who owns GitHub, Vercel or cloud, DNS, Stripe, and the database today? What was the last successful production deploy, and who can reproduce it from a clean laptop? Which paths take money or regulated data? Where do logs and error tracking live? Those answers decide stabilize versus strangler versus rewrite faster than any framework debate. We scope web product work so founders keep shipping while the foundation gets safer — not so a rewrite pitch deck becomes the product. If you are stuck between "too scared to deploy" and "too expensive to rebuild," start with ownership and one boring release, then choose the path with eyes open and milestones you can demo in staging before production.
Related reading: if your rescue includes a Next.js upgrade, see our Next.js 16.4 Cache Components plan before Next.js 17 makes it the default . When you price the engagement, our breakdown of fixed-price vs milestone billing when hiring a product agency shows how to tie payment to reversible releases. And if auth is part of the mess you inherited, read build vs buy auth for B2B SaaS . Stuck between too scared to deploy and too expensive to rebuild? Talk to the CodeFlamme team .
