Keep a sound website, repair a weak part or rebuild when the foundations block the business. A decision guide for Next.js, Sanity and headless Shopify owners.
Keep the existing website when its code can be maintained and it still supports the business. Rebuild when an audit shows that repairing it cannot deliver the required customer journey at a sensible cost. A developer leaving is a reason to organise a handover, not evidence that the whole site is unusable.
For Next.js, Sanity and headless Shopify sites, the useful first step is to check what you own, what works and what needs changing. That produces a scope you can compare with a replacement quote.
Take over, repair or rebuild?
| What you find | Likely direction | Evidence to ask for |
|---|---|---|
| The site works, but the original developer is unavailable | Take over management | A repeatable deployment, account access and a list of dependencies |
| Content updates are awkward, but the customer journey works | Improve the CMS | Specific publishing tasks the current content model cannot handle |
| A form, checkout or integration is unreliable | Investigate and repair the affected flow | A reproduced failure, its cause and a way to verify the fix |
| The design feels dated, while code and content remain useful | Redesign selected templates | Which parts can be reused and which need replacing |
| The platform cannot support required functionality | Compare a targeted replacement with a full rebuild | Technical limits, migration needs and costed options |
| Critical dependencies cannot be maintained, or essential source code cannot be recovered | Investigate a rebuild | Documented access attempts, dependency risks and replacement scope |
These are starting points. The audit should explain the recommendation with findings from your site.
What an audit needs to answer
Your new developer should be able to identify the production version, reproduce a build and explain how a change reaches the live site. They also need to inspect the content model, dependencies and the services connected to it.
Ask for a written record of:
- Repository access, ownership and the version currently deployed.
- Domain, DNS, hosting and billing access.
- CMS projects, datasets, backups and editorial permissions.
- Forms, email delivery, payments, booking and other integrations.
- Known failures, dependency risks and the order of proposed fixes.
- Deployment, rollback and checks for the customer journeys that matter.
Share secrets through an agreed secure method, not a public document. Preserve the live service while access and backups are checked.
A takeover can preserve useful work
For BlueRocket Therapy, we took over management of an existing website, migrated it to Vercel and added Sanity publishing tools. The original design by Ozone remained in place. We also added a shared referral starting point and continued technical management.
That project shows a reason to retain a site: the business can keep a familiar design while improving how the team publishes and manages it. It does not establish a price or timetable for a different codebase.
Our builds for Vibe Coder HQ and Compound show the kinds of functionality a takeover audit must account for. Vibe Coder HQ combines structured Sanity listings, moderated submissions and a Beehiiv newsletter connection. Compound combines editable service content with enquiry and booking forms. Those features need their own checks; a working homepage does not establish that the full site works.
Compare the ongoing scope as well as the build price
Studio Slate’s Headless Care Plan starts at $1,500 AUD per month and ranges to around $4,000, depending on site size, change volume and headless commerce requirements.
The published scope includes the takeover audit, hosting, monitoring, updates and an agreed number of change hours each month. Larger enhancements, such as a new template, content type or integration, are scoped and quoted as fixed-price projects on top of the retainer.
| Cost or responsibility | Takeover proposal | Rebuild proposal |
|---|---|---|
| Initial work | Audit findings, access recovery and priority repairs | Design, development, content and data migration |
| Ongoing work | Care plan and included change allowance | Hosting, maintenance and future changes after launch |
| Additional features | Identify what fits the allowance and what needs a separate quote | Identify what is in the build and what is deferred |
| Content and search | Preserve useful pages and check existing tracking | Map URLs, redirects, metadata and tracking before launch |
| Ownership | Client repository and accounts | Client repository and accounts, including the new setup |
Ask for the included hours, response arrangements, third-party charges, tax treatment and exclusions in writing. A care plan is not an unlimited development subscription. A rebuild quote also needs an operating plan for the period after launch.
If rebuilding is the better choice
Agree which pages, content, customer data and integrations must survive the move before design starts. Record the current URLs and decide which stay or redirect. Test the replacement on a preview environment with the people who use the CMS and handle enquiries.
Keep a rollback plan for launch. Confirm forms, booking, checkout where relevant, analytics and important redirects before retiring the old setup. Measure the new site against the agreed requirements rather than assuming a new platform improves results.
Our website redesign service covers replacement work. For a move to Shopify, the Shopify migration service has a separate scope for catalogue, customer data and connected systems.
What to bring to the first conversation
Send the site address, the stack if known, what is failing and the changes the business needs. List which accounts you can access and whether the previous developer is available for a handover. A repository link is useful; credentials can follow through a secure channel.
The next decision should be based on a documented scope: retain and maintain, fix a defined part, or replace the site with a migration plan.
Get a scope for the site you already own
Start with your existing Next.js, Sanity or headless Shopify site, the access you have and the work you need done.
Explore headless website takeoverFrequently Asked Questions
Can a new developer take over our existing website?
Often, yes. A takeover starts by checking the repository, hosting, domain, content system, integrations and deployment process. Missing documentation adds investigation; it does not automatically mean the site needs rebuilding. Access and the condition of the code determine the next step.
When is rebuilding better than a takeover?
Consider rebuilding when the current architecture cannot support the required customer journey, critical dependencies cannot be maintained, or the cost of repairing and operating the site exceeds a scoped replacement. A dated design or a departed developer alone is not enough evidence.
How much does Studio Slate charge for headless website maintenance?
The published Headless Care Plan starts at $1,500 AUD per month and ranges to around $4,000 depending on site size, change volume and headless commerce requirements. It includes the takeover audit, hosting, monitoring, updates and an agreed allowance of change hours. Larger enhancements are quoted separately.
Can we keep the current design and improve the CMS?
Yes, where the existing architecture supports the changes. A takeover can preserve the visual design while improving publishing tools, fixing problems and adding scoped features. BlueRocket Therapy is an example of Studio Slate managing and extending an existing website.
Who owns the code after a takeover?
You retain the code, domain and hosting accounts. Work stays in your repository. The handover should document access, deployment, integrations and ongoing responsibilities so another developer can continue later.
