Continue an existing project with a new developer
To continue an existing project, a new developer first reads what is there, tells you honestly what state it is in, and then plans the next steps in milestones. A short first milestone to review the work is the safest start.
Last updated:
When this help type fits
Projects change hands for ordinary reasons. A developer moves on, an agency contract ends, a co-founder leaves, or a first version was built as a side project and now needs more time. If the product works at least in part and you want it to keep going, this is the right help type.
- Your developer stopped responding, or their availability changed.
- The first version is live, but the original builder cannot do the next stage.
- A friend or relative built it as a favour and has no more time.
- You inherited a product with a company or a team and need someone who can carry on.
If the project is stuck or in a bad state, the rescue help type may fit better. If you are moving code from an agency, see taking over an existing codebase.
What to prepare
- Access to the repository. Ask the previous developer to add the new one, or transfer ownership to you.
- Access to hosting, the domain, and the database, with accounts owned by you where possible.
- Any documents: the original brief, designs, a list of features and notes on what is done.
- A written list of what works, what is broken and what you want next.
- Logins for services the product uses, such as email, payments or maps. Share them through a password manager and never in a chat message.
Do not worry if documents are missing. A good developer can read the code and tell you what they find. Say clearly what you do not know, and the first milestone can fill the gaps.
How it runs in milestones
The first milestone should be about understanding, not building. The developer reads the code, runs the product and reports back in plain language. After that, the new work is planned with the real state in mind. Each milestone is funded before work starts and runs 1, 2, 3, 4, 6 or 8 weeks. Milestones are from 50 to 2,000 each in your project currency.
| Topic | What you get | Example timing |
|---|---|---|
| Phase 1: Review | A short written report: what works, what is risky, what to fix first | One milestone, for example 1 week |
| Phase 2: Stabilise | Access set up, the product runs on your own accounts, the most urgent problems fixed | One milestone, for example 1 to 2 weeks |
| Phase 3: Move forward | The next planned features, delivered one milestone at a time | Several milestones, planned after the review |
Phase 1: Review
- What you get
- A short written report: what works, what is risky, what to fix first
- Example timing
- One milestone, for example 1 week
Phase 2: Stabilise
- What you get
- Access set up, the product runs on your own accounts, the most urgent problems fixed
- Example timing
- One milestone, for example 1 to 2 weeks
Phase 3: Move forward
- What you get
- The next planned features, delivered one milestone at a time
- Example timing
- Several milestones, planned after the review
Example only: the weeks are for illustration. Developers set the length of each milestone in their proposal, and each real milestone runs 1, 2, 3, 4, 6 or 8 weeks.
Questions to ask developers
- Have you taken over code written by someone else before? How did it go?
- What would you look at in the first days, and what will you report back?
- Do you work with the technology used here, or would you suggest a change?
- How do you keep the product running for users while you work on it?
- What do you need from the previous developer?
More ideas are in the guide with questions to ask before hiring a developer. To add new functions to a stable product, see add features.
Frequently asked questions
What if the previous developer is not reachable?
Many projects continue without them. What matters most is that you hold access to the repository, hosting and domain. If an account sits with the previous developer, a recovery process with the provider can often move it to you.
Link to this answerWill the new developer want to rewrite everything?
Some will suggest it, and sometimes it is the right call. Ask for the reasons and for a cheaper alternative. The review milestone gives you facts for that decision before you commit.
Link to this answerHow do I know if the code is good?
You usually cannot tell yourself. That is the purpose of a review milestone, or an advice and code review by a second developer.
Link to this answerWho owns the new work?
Unless both sides agree otherwise in writing on the platform, the rights to the result of a milestone pass to the client once that milestone is paid in full. Rights to older parts of the code depend on what you agreed with the earlier developer.
Link to this answerWill the new developer write documentation?
Ask for it as part of a milestone. A short readme with how to run the project and where things live helps every developer after them.
Link to this answerRelated pages
- Take Over an Existing Codebase SafelyMoving code from another developer or agency? Use this handover checklist for access, documents and a first audit milestone.
- Rescue a Stuck App or Software ProjectYour developer disappeared or nobody can change the app anymore. See the first steps, a milestone plan and what to ask a rescue developer.
- Hire a Developer to Add New FeaturesYour product works and now it should do more. Learn how to describe a feature, plan it in milestones and pick a developer who fits your code.
- How to Hire a Developer SafelyHire a developer with confidence: pay per milestone, fund before work starts, keep payments on one platform, and get access to your code as you go.
- Build a web app with an independent developerHow to plan a browser-based web app: common technologies, an example milestone plan, what to write in the brief and how to judge a developer.
- ErdiBuilds vs Upwork: fees and how it worksA factual look at fees, applying and payment on ErdiBuilds and Upwork, with sources and check dates, for people hiring an app or SaaS developer.