Take Over an Existing Next.js Project After Your Developer Disappears

You own a Next.js and Sanity site, and the person who built it has stopped replying. You need to take over the existing Next.js project without breaking what is live, and without finding out three weeks in that the Sanity project belongs to someone's personal email. This is the order I work in: access first, then a read-only audit, then a decision about repair or rebuild.

Get ownership sorted before anyone writes code

The code is the least urgent part. Accounts are what can lock you out, so list every system the site touches and write down who the owner is on each one.

The domain is the one that matters most. If the registrar account is yours, you can always repoint the site. If it is not, fix that before anything else.

Vercel

Check whether the project lives under a team or under the developer's personal account. A project in a personal account can usually be transferred to a team, but this requires the developer's cooperation or a support request. If you cannot get that, the fallback is deploying the repository to a new project under your team and moving the domain across. That is why having the code matters.

Sanity

Only an administrator can add members or change roles. Open the project's members page in the Sanity management console and see who holds that role. If it is only the departed developer, contact Sanity support with proof of business ownership. Do not wait: the content is the one asset you cannot regenerate from a repository.

While you are there, list the API tokens. Anything with write access that you did not create should be rotated once you have control. Check the CORS origins and the webhook list too; stale webhooks pointing at old preview URLs are common.

The repository

If the repo is in your organisation, good. If it is in the developer's personal account, ask for a transfer or a full mirror including all branches and tags. If you have neither, look for the code in the hosting provider: Vercel keeps deployments, and the connected Git repository is shown in project settings. That tells you where to look, even if it does not give you access.

The first-week audit checklist

The audit is read-only. Do not upgrade packages, do not clean up, and do not push to the production branch. You are building a picture of risk.

1. Can it run locally? Clone, install, copy env vars from the host, start the dev server. If this takes more than a day, that is already your answer about maintainability.
2. Can it build in CI or on Vercel from a clean checkout? A site that only deploys from one laptop is a liability.
3. Which Next.js version and router? Note the major version, whether it uses the App Router, Pages Router, or both, and whether the build output shows pages that are statically generated or fully dynamic.
4. What does the content model look like? Open the Studio and read the schema folder. Count document types, check for unused ones, and check whether references are used or content is duplicated.
5. Environment variables. List every one the app reads. Mark which are secrets and which are missing from the host.
6. Data fetching. Search for how GROQ queries are written and whether the client uses the CDN.
7. Revalidation. Find out how content updates reach the live site: webhooks, time-based revalidation, or nothing.
8. Performance baseline. Run Lighthouse and look at field data in Search Console. Record it before you touch anything so you can show improvement later. My post on Core Web Vitals monitoring covers the setup.
9. SEO state. Check the sitemap, robots, canonical tags, and redirects.

A quick way to start the inventory:

# run from the repo root
git log --since="12 months ago" --pretty=format:"%an %ad %s" --date=short | head -50
grep -rn "process.env" src app lib --include=*.ts --include=*.tsx | sed 's/.*process.env.//' | cut -d' ' -f1 | sort -u
npm outdated

The git log tells you whether work was steady or abandoned, the grep gives a rough env var list, and npm outdated shows how far behind dependencies are.

Red flags in an inherited Next.js and Sanity codebase

None of these is fatal alone. Several together should change your plan.

• No lockfile, or two of them. Builds are not reproducible.
• Secrets committed to the repo. Rotate them immediately, whatever else you decide.
• A Sanity write token used in client-side code. Anything prefixed for the browser is public.
• Hard-coded content in components while the Studio holds unused equivalents. Editors will change things that do nothing.
• Fetching everything on every request with no caching strategy, which usually shows up as slow pages and a large Sanity bill. See avoiding N+1 queries with Sanity references.
• No types. Plain JavaScript with unvalidated query results means every change is a guess. TypeGen fixes much of this, as in fully typed GROQ queries.
• A very old Studio. If the Studio is on v2 or v3, it needs to move to the current major. The path is in the Studio upgrade post.
• No preview or an exposed one. Draft content visible to anyone with the URL is a quiet but real problem.
• Dozens of unused document types that confuse editors and slow the Studio.

A useful check for the token problem:

grep -rn "SANITY_API_TOKEN\|NEXT_PUBLIC_.*TOKEN" . --include=*.ts --include=*.tsx --include=.env* -I --exclude-dir=node_modules

Any token with a NEXT_PUBLIC_ prefix is shipped to every visitor.

Rebuild or repair

I decide this on four questions, not on how much I dislike the code.

Repair when the site runs locally, builds cleanly, uses a reasonable content model, and the pain is limited to performance, a few bugs, or missing features. Upgrading Next.js and fixing hot spots is cheaper than a rebuild nearly every time.

Repair the Studio, rebuild the front end when the content is healthy but the Next.js code is a tangle. The Sanity dataset is the valuable asset. A new front end can read the same content with better queries. This is the most common outcome I see.

Rebuild both when the schema is the problem: duplicated content, no references, fields named after pages rather than meaning. Migrating content into a clean model costs more up front, but it stops every future change from being expensive.

Move platforms when the site is on Gatsby; see migrating Gatsby to the App Router.

If you are comparing the cost of a rebuild against a series of patches, be wary of anyone who quotes without opening the codebase.

What to ask a developer before they touch it

• Will you audit before quoting, and will the audit be written down?
• Where will work happen: a staging URL and a branch, not production?
• Who will own the accounts at the end?
• How will you handle secrets you find in the repo?
• What is the rollback plan if a deploy goes wrong?

The proposal evaluation guide covers the contract side.

Work Nayan does

Taking over abandoned Next.js and Sanity sites is work I do. A fixed-price performance and Sanity audit starts from $800 and gives you the written risk list, account ownership steps, and a repair-or-rebuild recommendation before you commit to anything larger.