What a maintenance takeover means
A maintenance takeover means a new team becomes responsible for a product that is already live: keeping it deployed, fixing what breaks, updating dependencies and shipping small improvements. It starts with learning the system as it actually runs today, not as old documentation describes it, and only then changing anything.
Most products that need this were built by a freelancer, an agency or an AI builder such as Lovable, Bolt, Replit, Cursor or v0, and then the person who understood them moved on. The app still has users, but every bug report turns into a small crisis because nobody knows where to look. A takeover replaces that uncertainty with an owner, a written picture of the system and a predictable rhythm of work.
- The product is live, or very close to it, and has real users or paying customers.
- The previous developer, agency or in-house engineer is gone, unresponsive or leaving soon.
- You plan to keep running and improving the product for months, not shut it down.
What to do right now, even if you hire nobody
Before anyone touches the code, make sure you, the business owner, control the accounts the product depends on. These steps cost nothing, take a few hours and protect you whichever team you choose next. They also make any quote faster and more accurate, because the next team can see the real system instead of guessing.
List every account the product uses
Write down the domain registrar, DNS, hosting, database, code repository, app store accounts, payment provider, email sending service and any AI or API keys. Note who owns each one today.
Move ownership to a company login
Where an account sits in a former developer's personal name, ask them to transfer it or add your company email as an owner. For accounts you legitimately own, use each provider's normal transfer or account-recovery process.
Get a full copy of the code
Make sure the complete repository, including the deployment configuration, lives in an organisation you control. A zip file on someone's laptop is not enough.
Export the data
Take a database backup and store it somewhere separate from the hosting account. Check that the backup actually opens.
Rotate shared secrets
Once you control the accounts, replace API keys and passwords that former contractors knew, one at a time, and confirm the app still works after each change.
Write down how users report problems
Collect recent bug reports, support emails and known issues in one document. It becomes the first backlog for whoever maintains the product next.
Where to start depends on what you have
The first weeks of a takeover look different depending on how much access and documentation you hold. The table below shows common starting points and the usual first move for each. Where ownership of the code or the accounts is disputed with a former developer, that is a legal question and you need a lawyer, not an engineering team.
| Situation | Access you need | Likely path |
|---|---|---|
| Only a repository, no running app | Repository owner access and the list of environment variables | Rebuild the deployment from the code, then review before users return |
| Live product with no documentation | Hosting, database and repository access | Review the running system and write the missing documentation first |
| Deployment broken | Hosting dashboard, build logs and DNS | Restore a working deployment, then find out why it broke |
| Previous developer still holds the accounts | Ownership moved to your company login | Recover the accounts through each provider's normal process first; a lawyer if ownership is disputed |
| Built with an AI app builder | Builder workspace, database project and connected services | Review data access rules and secrets before taking on new features |
| Subscriptions or payments out of sync | Payment provider dashboard, webhook logs and the app's billing records | Compare provider records with the app's records before changing any billing code |
When payments or subscriptions silently drift
In a live product, the most expensive bugs are often quiet ones: a customer who paid but has no access, or a cancelled subscription that still unlocks paid features. These usually come from webhooks that fail without anyone noticing, or from the app trusting its own stored status instead of the payment provider's records.
- Pick a handful of affected customers and write down what the payment provider says and what the app shows for each.
- Check whether the app receives and verifies payment webhooks on the server, and whether failed deliveries are retried and logged.
- Test a purchase, a renewal, an expiry and a restore in the provider's test mode before changing anything in production.
- Until the cause is found, keep a documented manual check for affected customers instead of trusting stale records.
- Keep receipts and personal data out of public forums and support threads; share them only through private channels.
How the takeover works
Servify Labs runs a maintenance takeover in a fixed order: understand the system, reduce the biggest risks, then settle into regular sprints. Senior engineers do the review and use AI tools, including Claude, in their workflow to read unfamiliar code faster, but every finding is checked and written by a person who understands the running app.
Free intro call
You describe the product, who uses it, what is breaking and what access you hold. You get a quote and a written proposal within about 20 minutes after the call.
Second call and agreement
A second call the next day goes through the proposal. Work starts the day after the agreement is signed and the first sprint is paid.
Review of the running app
Engineers review the code, data access, payments and deployment of the live system and write ranked findings: what can hurt users or revenue first, and what can wait.
Stabilise
The most serious findings are fixed first, with backups and a way to roll back each change.
Regular two-week sprints
Maintenance and improvements continue in two-week sprints, paid upfront per sprint, with the option to pause or cancel anytime.
What you receive and what is out of scope
You receive a clear picture of the product you own and a team that is responsible for keeping it running. Everything produced stays yours: the code, the designs and the infrastructure belong to you from day one, and the written findings are yours to keep even if you later move to another team or hire your own engineers.
- Written, ranked findings on code, data access, payments and deployment.
- Documentation of how the system is deployed, configured and backed up.
- Fixes for the most serious findings, delivered in sprints.
- A maintained backlog and a short summary at the end of each sprint.
- Out of scope: legal advice on disputed code or IP ownership.
- Out of scope: getting into accounts you do not own or bypassing anyone's security.
- Out of scope: a compliance certificate; a review does not make any app permanently safe.
When Servify Labs is not a fit
A maintenance takeover only makes sense if the product will keep running and the budget matches the offer. Servify Labs is probably not the right choice in the cases below, and it is better to know that before the first call than after it. A short, honest call can still help you choose another route.
- The budget is below the offer: maintenance sprints start from $3,500.
- You need one quick patch so a demo works next week, and nothing after that.
- You plan to shut the product down soon and do not intend to keep building it.
- The main problem is a legal dispute with a former developer, which needs a lawyer first.
Related situations
Maintenance is often the last step of a longer story, so start from the page that matches where you are today. If your developer stopped responding, read what to do when your developer abandoned your app. If the build is unfinished, see project takeover. If an AI-built app has not launched yet, see the audit for AI-built apps.
Frequently asked questions
What access do you need to take over maintenance?
Owner or admin access to the code repository, hosting, database and the services the app depends on, such as payments and email sending. If some accounts are still in a former developer's name, the first job is moving them to your company through each provider's normal process. Servify Labs never advises getting into accounts you do not own.
Do you rewrite the app or keep what exists?
The default is to keep what works and fix what does not. The review shows which parts are sound, which need repair and which, if any, are worth replacing. A rewrite is only suggested when keeping the existing code would clearly cost more over time, and the reasons are written down so you can judge them.
Is a maintenance takeover a security audit?
The review covers data access, payments and deployment, and serious risks are ranked first. It is not a certification and it does not make any app permanently safe. If you need a deeper review of an AI-built app before launch, the audit for AI-built apps is the closer fit.
How much does maintenance cost?
Maintenance runs in two-week sprints from $3,500, paid upfront per sprint, and you can pause or cancel anytime. What the first sprint covers is set in the written proposal after the free intro call. The effort depends on the size of the system, how much documentation exists and how many accounts need to be recovered first.
How fast can you start?
After the free intro call you get a quote and a written proposal within about 20 minutes. There is a second call the next day, and work starts the day after the agreement is signed and the first sprint is paid.
Our app's subscriptions show the wrong status. Can you help?
Yes, this is a common reason live products need an owner. The work starts by comparing the payment provider's records with the app's records for affected customers, checking how webhooks are received and verified, and testing purchase, renewal and expiry in test mode before any billing code changes in production.
What happens after the takeover?
Maintenance continues in two-week sprints: fixes, dependency updates, watching the deployment and small improvements. You can pause or cancel anytime. If you later hire your own engineers, the documentation and findings are yours and make that handover easier.
Do I keep ownership of everything?
Yes. You own the code, the designs and the infrastructure from day one. Accounts stay in your company's name, not in Servify Labs' name.
Can you maintain an app built with Lovable, Bolt, Replit, Cursor or v0?
Yes. AI-built apps often run on the builder's own hosting and a managed database with its own access rules, so the review checks those rules and any exposed keys before new features are added.
Related
“These guys stepped in, fixed the issues, improved the UI and UX, and got us launched in just two weeks.”
Tell us about the product nobody is maintaining
A free intro call. You get a quote and a written proposal within about 20 minutes after it.
Book a free intro call