Someone else built your app. They have gone quiet, or they finished and moved on, or there was never a person in the first place because you built it with an AI tool and then hit a wall you cannot get past. The searches all end up in the same place, and so does the sentence you type: I need a developer to take over my project.
What nobody sells you is a definition of the thing you are buying. One owner put the whole question into a single line while asking a public forum for help: “Is it better to hire someone to host it… and then retain their services for updates/alterations?” They got opinions. Nobody told them what a finished answer looks like.
A takeover is finished when a new person can run your app, ship a change to it, undo that change, and see it fail, all through accounts your business owns. Accepting a repository invitation is not any of those four things.
This page gives you four checks: can a candidate run, change, undo, and monitor the app? It shows which accounts stay in your business’s name. It explains what a candidate reads before saying yes, how four seller types package the job, and how to keep the first job small.
What “take over my project” actually means when the app already exists
Taking over your app means one person or firm becomes the one who runs it, changes it, and answers for it, using access your business grants and can take back. The word covers a transfer of responsibility, not a transfer of property. Your app stays yours the entire time.
The one published definition worth quoting comes from a dev agency, Saritasa, on a page at saritasa.com/insights/time-for-a-code-takeover dated 27 May 2021. It is named here and deliberately not linked, because it sells what AxonBuild sells. Their wording: “A Code Takeover is when a company develops a software application using a software development firm and then wants another firm to take over the development of the software.” The page then describes their own process, which starts the incoming team on smaller tasks in isolated parts of the code and works outward as the team learns the application. Read on 16 August 2026, it publishes no price, no timeline, and no condition that says when the takeover is complete. It is a definition written for one company switching to another company, which is not most people typing this search.
The published guidance on how to take over a software project has the same tilt. The clearest one is a dev.to guide on taking over an existing project, which opens “Working as a developer means you need to know how dive into existing code bases” and walks five steps: know what the app does, know how source control is handled, know how to run it, know the testing process, know the deploy process. Good advice, written for the person doing the taking over. On the date it was read, 16 August 2026, it says nothing about cost, nothing about how to choose the person, and nothing about who owns the accounts.
Three different situations arrive at this same search, and they want different things. In the first, the builder went quiet: messages get slower, then stop, nothing is finished and nothing is written down, and what you need is someone who can start from the code alone. In the second, the builder finished and left. The work was delivered, a change is needed now, and there is nobody to make it. That one is the cleanest, because the app runs and the only open question is who carries it next.
In the third, there was never a builder. You made it with Lovable, Base44, Replit or Claude Code, it works well enough that people rely on it, and every new change now breaks something older. There is no person to hand it across from, only an account and a repository.
The third case is the one none of the older guidance was written for, and it has a particular shape: an app that gets more expensive to change every month does not usually break in a dramatic way. It just stops absorbing changes, and the person who built it, human or otherwise, stops being able to move it.
Two related situations are close enough to confuse and different enough to need their own answer: when the app is nearly finished and the builder stopped partway through, and when you already paid a developer and got a half finished app back. Both change what you ask for first.
Four things that have to work before someone has taken your app over
Four capabilities decide whether a takeover happened: a new person can run the app without you, ship a change through something that checks it first, undo that change, and see it when it fails. In the fixed June and July 2026 audit cohort, at least 17 of 21 third-party apps had no deploy gate at all.
That number, and every corpus number on this page, comes from the 26 AI-built apps AxonBuild audited in June and July 2026. It is a fixed study with fixed denominators, not a rolling count, so 21 means the third-party apps in that cohort and 26 means all of them including the founder’s own five.
Before any candidate receives private code, put confidentiality terms in writing. Give them the least access needed and use a test environment with sanitized sample data. Do not share production secrets or customer data for this test.
| What has to work | What it looks like when it is true | What the audit corpus found | What to ask before you pay |
|---|---|---|---|
| They can run it | They start the app on their own machine, from the repository plus a list of settings, without you on a call | The corpus does not measure this directly, and it is the one capability a candidate can prove to you in an hour | ”Can you get it running in a limited test environment after confidentiality terms are signed, without production secrets or customer data? Tell me what stopped you if you cannot.” |
| They can ship a change | A change goes out through a path that runs the tests and blocks the release when they fail | At least 17 of 21 third-party apps had no deploy gate, and all 5 founder-owned apps also lacked one. At least 23 of 26 apps had no working automated test | ”When you push a change, what has to pass before customers see it? If nothing does, what would you put in first?” |
| They can undo it | A bad release goes back to the previous version, and there is somewhere other than production to try things | One audited app tested every change directly against the production database because no staging environment existed | ”If a change goes wrong on a Friday, what is the exact sequence that puts it back?” |
| They can see it fail | An error a customer hits is recorded somewhere a person looks, and someone is told when the app stops answering | 17 of 21 third-party apps recorded errors nowhere. When a user hit an error, nothing kept a record of it | ”How will you find out something broke, and how will I?” |
The fourth one is the one buyers forget, and it is the one that decides whether the arrangement feels like it is working three months in. Without it, the only error reporting you have is a customer who bothered to email you, which means the errors you hear about are a small and badly chosen sample of the errors happening. Every conversation after that runs on guesswork, on both sides.
A takeover is done when someone else can run it, change it, put the change back, and find out it broke, rather than when they accept the invitation to your repository.
Three of the four are cheap to establish and none of them require you to read code. The second and third often travel together, because one database with no staging makes “undo it” impossible no matter how careful the new person is. If a candidate tells you those two are a week of setup before any feature work, that is a real answer, not a stall. If they tell you it is not needed, you have learned something useful for a few hundred dollars less than you would have learned it otherwise.
Code quality is deliberately absent from that list, and so is whether the app is written the way the incoming person would have written it. Both are opinions, both are usually correct, and neither one decides whether the next six months are easy or hard.
What moves across, and what stays yours
Access moves across; ownership stays where it is. The business keeps the domain, the repository, the database, the hosting account and the payment account in its own name, and the person taking over gets their own named access to each one, granted by you and removable by you. If a candidate wants the accounts moved into their name for convenience, that is not a technical requirement, and it is the single hardest thing to reverse later.
Then there is the part almost nobody separates. Giving someone access, invalidating a credential, and cleaning repository history are different jobs. Access can be revoked in a minute. If a secret was committed, revoke or rotate it first so the exposed value stops working. The central repository’s history can then be rewritten when the cleanup is warranted, but existing clones and forks may still retain the old object. In the audit corpus, 6 of 21 third-party apps had shipped a real secret, and 3 of those had retained it in Git history.
Rotate a credential when it was exposed, may have been exposed, or was available to someone whose access you can no longer trust. Do not rotate every key merely because a person joined or left when that person never had the credential. Named access and least privilege reduce how often a staffing change becomes a credential incident.
The honest counterweight: secrets handling was the best-scoring pillar in that corpus, at 84.4 out of 100 across the 21 third-party apps. A generated starter puts its keys in environment variables by default, and most of the corpus left them there. The 6 are the exception. They are worth planning around because invalidation and any required history cleanup still take focused work.
There is a longer list of everything to prepare before they start, covering accounts, access and the first few weeks of work, and it is a separate job from this one. This page is about deciding what to buy and from whom.
What the person taking over checks first, before they say yes
A real first look is two working sessions, not two weeks. The person reads the code to answer one question: whether the thing you want is a small job or a large one, and they tell you which. This guide recommends a free first look; paid discovery can also be legitimate when it produces named outputs such as a risk map, estimates, or documented findings, so judge it by what the buyer receives rather than by the fact it is paid.
The order below is read from AxonBuild’s own procedure and from the audit files behind the numbers on this page, rather than from a takeover staged for this article.
A first look reads three things, roughly in this order.
The first pass is the boring inventory. What does the app run on, what does it depend on, where does the data live, and does any of it still get security updates. This is fast and it is the part that most often produces the one genuinely bad surprise.
The second pass follows one path all the way through. Usually the one that touches money or customer data, because that is where a mistake is expensive. The reader is asking whether the server decides what the server should decide, or whether it accepts whatever the browser tells it.
The third pass is the four capabilities above. Can it be run, can a change ship safely, can it be undone, does anything record a failure. This is where the estimate actually comes from, because a change to an app with no way to test it and no way to undo it is a different job from the same change to an app that has both.
The AxonBuild version of this is worth stating plainly, because it sets a boundary you can hold any candidate to. The 20-minute call is free. If one broken behavior qualifies as a first repair, we agree on the blocker before requesting access. A new client pays $99 after seeing it work. If the job is larger, we quote it after reviewing the code and do not start without approval. If another provider charges before estimating, ask what concrete artifact or decision that payment buys.
Two related purchases sit next to this one and get confused with it. Having someone read the code first and report back is one thing to buy, and what a vibe coding cleanup specialist does is another, and neither of them is the same as someone carrying the app from here on. If the real question in your head is whether the app can be opened to customers yet, that is a third question again, and the answer to it does not require hiring anyone permanently. What the new developer does in their first week, once you have picked them, is its own subject.
Who can take over my app development: four shapes, and which to start with
Four sellers will take this on, and they price it four different ways. Prices checked 16 August 2026.
| Shape | What you actually buy | Published price | Start here when | Do not start here when |
|---|---|---|---|---|
| One repair for a new client | One blocker in a working app, agreed in plain words before work starts | AxonBuild: $99 once for a new client, completed within three business days once access works, paid after you see it work | You want to test the person and the app on a real blocker | The thing you need is a whole migration, rebuild, or new feature |
| Hourly or ongoing support | A person or firm available on a recurring basis, work billed as it happens | Varies by seller. Fingoweb’s 10 August 2026 hiring guide puts established independent developers at $70-130 an hour | The app is stable and what you need is availability rather than a specific fix | Nobody has read the code yet, so neither of you knows how much time the first month takes |
| Marketplace freelancer | One person, chosen from a category listing, priced by the hour | The same Fingoweb guide puts marketplace freelancers at a $18-39 an hour median band | The job is small, well defined, and you can tell whether it was done | You cannot yet describe the job in a way that a stranger could price |
| Agency code takeover | A firm’s process, a team rather than a person, and their own onboarding sequence | None published on the pages read for this article | The app is genuinely large, or a company needs a company on the other side of the contract | The app is one person’s project and you need a decision this month |
Those rate ranges belong to Fingoweb, a software house, on a page at fingoweb.com/blog/how-to-hire-an-app-developer/ published 10 August 2026. Named, not linked, for the same reason as Saritasa: they sell what AxonBuild sells. Their page also names ownership items to settle in writing, including the repository sitting under the client’s account and the app store accounts being registered to the client. It does not define when a takeover is finished.
The marketplace route appears through category listings such as upwork.com/hire/mobile-app-developers/, pro.fiverr.com/cat/technical/app-developer and toptal.com/developers/app. They are listings rather than answers, and they are not linked here for that reason. The Upwork page returned an HTTP 403 to an automated read on 16 August 2026, so nothing is claimed about its contents.
If you are choosing between the first two shapes, start by asking what each evaluation produces, then compare price. This guide recommends starting with one named repair when the problem is narrow enough, because it tests the person and the app on work you can see. Paid discovery can still be appropriate when it delivers a named analysis artifact or when the uncertainty cannot be narrowed before investigation. Who keeps the app running afterwards is a separate decision you get to make with real information. For rates beyond the comparison above, what developers charge for an app that already exists goes into the ranges properly.
How to buy the first job so a bad fit costs you almost nothing
Pick one thing. Not the app. One thing that is broken, risky, or unfinished, that you can describe without using a technical word, and that you will be able to tell has been done. The signup emails go to spam. The report page times out. The export button was never wired up. Any of those is a first job.
Then agree what “working” means for that one thing, in the plainest sentence you can manage, before anyone starts. “A new customer signs up and the confirmation email arrives in the inbox within a minute, on Gmail and on Outlook.” That sentence is the whole agreement. It takes two minutes to write and it removes the argument that otherwise happens at the end.
When it is delivered, the four capabilities from earlier are what you check. Can they run it without you, did the change go out through something that checked it, can it be put back, and would anyone find out if it broke at 2am. A person who delivered the fix and also left you with the second and fourth is worth keeping. A person who delivered the fix by editing production directly is not, no matter how quickly it went.
One owner wrote exactly the shape of the arrangement they wanted: “Looking for a real dev… bring my lovable project to production… maintain the project as well”. That is two purchases described as one, and separating them is what makes it affordable. The first is a defined result. The second is an ongoing arrangement you decide on after you have seen the first one land.
The honest boundary: a whole takeover is not one repair. AxonBuild’s first $99 repair covers one agreed blocker for a new client, not moving your app off its builder, rebuilding it, or staying available indefinitely. When the takeover is really a move off the builder platform, AxonBuild quotes it after reviewing the code. Starting with one repair gives you direct evidence of how the person works before you trust them with more.
Common questions about hiring a developer to take over your app
How do I find a developer to take over my project?
Start with people who already work on apps like yours rather than a general category listing. The search itself is polluted: the top results for this phrase are career advice for developers, not sellers. Ask a candidate to run the app in a limited test environment before you hire them, after confidentiality terms are signed. Give them the least access needed, use sanitized sample data, and share no production secrets or customer data.
What do I need to give a developer taking over my app?
Named access to the repository, the hosting account, the database and the domain, plus the list of settings the app needs to run. Grant access under their own account rather than sharing your password, so it can be removed later. Everything to prepare before they start is a longer list and a separate job from choosing the person.
Will a new developer just tell me to rebuild it?
Some will, and it is worth being suspicious of the ones who say it before they have run the app. Rebuilding is easier to quote and easier to deliver than working inside somebody else’s code, so the incentive runs that way. Ask what specifically blocks a fix. Whether to fix it or start over is its own decision.
How much does it cost to have someone take over my app?
There is no single number, because “take over” covers everything from one fix to permanent availability. The published rates on these searches, all from one 10 August 2026 hiring guide, run from an $18-39 an hour marketplace median to $75-250 an hour for North American agencies. A first defined result is the cheapest way to find your actual number.
What a cleanup costs, and what developers charge more generally, are covered separately.
Do I have to give up ownership of my app or my accounts?
No, and you should not. The domain, repository, database, hosting and payment accounts stay in your business’s name, and the person taking over gets their own named access that you can remove. If someone asks for the accounts to be transferred rather than shared, that is a preference of theirs, not a requirement, and the hardest thing here to reverse.
What if the original developer will not respond?
Assume they will not come back and plan from what you already hold. Change every password and rotate every key you can find, including any the app uses to talk to other services. Recovery depends on what the business controls: the repository, environment configuration, deployment and database access, domain settings, third-party integrations, and any signing or app-store accounts the app needs. The departed person’s memory is not the only path, but a repository and running app may not be enough.
How long does it take before someone can actually work on it?
Getting the app running on their machine is hours to a few days, depending on how many settings were never written down. Being able to change it safely takes longer, because that usually means adding a check before release and a way to undo a bad one. Ask for the first estimate as two separate numbers, not one.
Is it better to hire someone to host it and keep them on afterwards?
Buy one defined result first, then decide about the ongoing arrangement. Hosting and availability are worth paying for once you know the app can be changed safely, and worth nothing before that. Deciding both at once means committing to a monthly cost before anyone has established what the monthly work actually is.
Ongoing-support pricing, and who keeps it running afterwards, are a separate question.
Still the only person who can keep the app moving?
When staff or customers depend on it, AxonBuild can fix the next failure, ship the next change, and document the app so progress no longer waits on you.
