Choosing help to finish an app a previous developer left
Guide to hiring a developer to complete your abandoned app. Evaluate existing code, spot project-takeover experience, and avoid costly restarts.
Taking over incomplete work is harder than starting fresh. A previous developer has left code, decisions, and often hidden assumptions behind. You're not just picking someone skilled—you're picking someone who can diagnose what was left, decide what's salvageable, and move forward without wasting money rebuilding what already exists.
The central trade-off is between cost and continuity. A developer who works with the existing codebase will be faster and cheaper because they're not rewriting from scratch. But if that codebase is poorly structured, or the original developer used tools or patterns unfamiliar to most in the market, you may pay more in the long run through slow fixes and future inflexibility. A fresh start costs more upfront but gives you clean code and no technical debt. The right choice depends on whether the existing work is salvageable and whether you can afford the gamble.
Can the existing code actually be picked up?
Before you even look for a developer, get someone to audit what you have. This doesn't mean a full rewrite assessment—it means an honest look at whether the code is documented, whether the original developer left handover notes, whether the app runs without crashes, and whether the underlying structure makes sense to a stranger. If the answer to most of these is no, you're in deep water.
When you interview candidates, ask each one to spend a day or two reviewing the existing code and then give you a written assessment: What works? What's broken? What architectural choices would need to change? What's the risk profile of continuing with what's there? A developer who won't do this work, or who immediately says "we should rewrite everything," may not be trustworthy. They might be right, but they might also be hedging their bets by starting from a blank slate.
Key questions in that assessment conversation: Can they build in the same programming language and framework the original developer used, or would they have to learn it on your time? Has the code been version-controlled properly, so you can see the change history? Are there any external services or APIs integrated that would break if your app goes dark for a few weeks during the takeover? Is there a database, and if so, is its structure documented?
Finding someone who thrives in incomplete projects
The developer you need for this job has a particular temperament. They're comfortable in ambiguity, they don't panic when they open a file and it makes no sense, and they're transparent about what they don't know. They've done this before.
When you ask for examples, listen for stories about refactoring, fixing bugs they didn't write, or inheriting legacy code. A developer whose portfolio is all greenfield projects (building from zero) isn't necessarily a bad fit, but they're riskier. Also ask how they'd communicate progress to you—especially the difference between "I'm writing new features" and "I'm untangling the old architecture so I can write new features safely." That distinction matters enormously. You want someone who explains the invisible work.
Setting expectations upfront is critical. Tell them the timeline and budget you have, but also tell them that the scope will change once they really dig in. A developer who commits to a fixed price without seeing the code is either naive or setting themselves up to cut corners. Instead, propose a phase: first, a detailed assessment (fixed fee or small daily rate); second, once you both understand the landscape, a revised scope and estimate.
Be wary of anyone who dismisses the previous work too quickly or seems fixated on technology choices. Your old codebase is not perfect, but neither is any new one. The question is whether the person in front of you can work with what exists, make pragmatic choices about what to repair versus replace, and explain those choices to you in plain terms.
When you're ready to move forward, set a trial period—perhaps two weeks of part-time work or a small, isolated feature—so you can see their pace, communication style, and how well they actually mesh with the existing code. Then verify any developer you're considering through Strove, where you can check their past work and see what others who've hired them say.
Common questions
- Should I always ask for a complete rewrite, or try to use the old code?
- Not necessarily. A full rewrite costs more and takes longer. The right developer will audit the existing code honestly and tell you which parts are worth keeping and which parts will slow you down. Build your decision on their assessment, not your initial gut feeling. The cheapest option upfront isn't always the best long-term choice.
- How do I know if a developer is comfortable with incomplete projects?
- Ask for examples of apps or features they've inherited from other developers, and listen for how they talk about the work—do they explain the detective work, or just skip to the solution? A good hire will have tackled this before and will ask your future developer smart diagnostic questions about the handover process.
- What should the first paid phase look like?
- Start with a fixed-fee assessment: give the developer a day or two to read the code, run the app, and give you a written report on what's salvageable, what's risky, and what architectural changes they'd recommend. This costs far less than guessing and often saves you months of trouble down the line.
- What if the original developer didn't document anything?
- That's a red flag, but it's common. A competent takeover developer treats missing documentation as part of the job—they read the code itself to understand intent. Budget extra time and money for this friction, and ask candidates upfront how they'd handle it before you commit.
Find a verified provider on Strove
Compare vetted mobile app design & build providers, check their credentials, and book or request a quote — all in one place.
Find a Business