C.E.O. Bee
Project Recovery

Who should take over your software project? Five options, twelve questions and a scoring sheet

C.E.O. Bee Engineering17 min read

An unfinished software project can be taken over by the previous team, a new software company, an independent developer, your own hire, or a split in which one party assesses and another builds. Which fits depends on why the project stopped and what you must be able to prove afterwards. Secure the access first, keep the assessment separate from the work, and ask every software project rescue partner you consider the same twelve questions in writing. The guide adds a comparison table, a green-amber-red reading and a scoring sheet.

Five kinds of party that can take over a stalled project

A software project can be taken over by five kinds of party, and the right one depends on why the project stopped, how much you can manage yourself and how much you need to be able to prove afterwards:

  1. The previous team, under a new written scope.
  2. A new software company that assesses first and then continues or rebuilds.
  3. An independent developer for a bounded job or a second opinion.
  4. Your own hire, when the product will keep evolving and you can manage engineers.
  5. A split: one party writes the assessment, another does the work.

None of these is correct in general. The table below shows when each tends to fit and what it risks; every cell is qualitative on purpose, because the real answer depends on facts about your project that no article can see.

Option Tends to fit when Main risk What to secure first
Previous team The project stalled over scope or budget, they are reachable and willing, and you can write a new, smaller scope The cause of the stall returns; knowledge stays only with them Access and a full copy in your own accounts, before any new work
New software company You want one accountable party for the assessment and what follows The same party that assesses may also quote the rebuild, so how the two are separated matters Access into your own organization; the assessment scope written separately from the build
Independent developer The job is small and well bounded, or you want an outside reading of the code One person holds all the knowledge; availability Repository in your organization; written run and handover notes
Your own hire The product will evolve for years and you can manage engineers Someone must be able to judge inherited code from day one The same access list, plus an outside reading of what the hire inherits
Assessor, then builder The stakes are high, or you want a report that does not depend on who will bid for the work Two handovers and more coordination A report that any team can act on

We are a software company, so this guide is written to work whichever row you choose, including the ones that are not us. If your project is a half-finished build and you are weighing these rows, our page on software consulting and modernization describes how we do the assessment; how to judge the code itself is in our guide on taking over an unfinished software project.

The first question to ask of each option

Whichever row you lean toward, one question usually shows quickly whether it will hold.

  • The previous team. "What would you need, in writing, to finish, and what is different this time?" If the answer is only "more time", the cause of the stall is still in place. Ask for the access list as a condition of continuing, not as a favor.
  • A new software company. "Who writes the assessment, and what happens to it if I do not hire you for the work?" An assessment that is only useful to its author is a sales step; one that another team can use is a deliverable.
  • An independent developer. "Who covers the work if you are unavailable, and where do your notes live?" One person holding everything is workable for a bounded job and fragile for an ongoing one.
  • Your own hire. "Who will judge the code this person inherits?" A new engineer's first weeks are then spent defending or doubting code that nobody can vouch for; an outside reading gives them a starting point.
  • An assessor, then a builder. "What must the report contain so the builder can start without redoing it?" The report outline in the takeover guide is a reasonable starting list.

Two jobs to do before you choose anyone

Put the access in your own hands. Whoever you pick should not need to hold the only copy of anything. The first-48-hours list in our takeover guide covers the repository, hosting, domain, database, store and third-party accounts; do that first, and do not wait for a contract with the new party. Two details from GitHub's documentation help here. Organization owners have complete administrative access to the organization, and GitHub recommends keeping the number of owners small but never fewer than two (GitHub). And when a repository is transferred, its webhooks, secrets and deploy keys remain associated with it, and the original owner is added as a collaborator (GitHub); that is a reason to rotate every secret the former team knew and to review who is still a collaborator, once you have a backup.

Separate the assessment from the work. Judging code and doing the work on it are two jobs. Nothing about that is an accusation: it is a structural question that you can put to any party, including your own team. Ask for the assessment to be written, in a form that another team could act on, and ask for its scope and cost to be written separately from the build. A report that exists only in the head of the party who will do the work is hard to compare with anything.

Seven signs to look for in a team that takes over

A takeover partner, or software project rescue partner, can be judged in the first conversation, before any quote, by what it asks for and what it promises to write down. The table reads the signs as questions about evidence. It is our reading, not a standard.

Sign Why it matters What backs it
It asks for access and a clean install before it quotes A quote given before anyone has seen the system is an estimate Whether a project builds on a clean machine is observable. The Twelve-Factor App describes the same discipline: "One codebase tracked in revision control, many deploys" and "Explicitly declare and isolate dependencies" (12factor.net)
It reports a restore from backup, not only a build A backup that has never been restored is a hope The audit steps in our takeover guide
Findings come as a written report with reasons You can take a written report to someone else and compare Section "Report outline" of the same guide
It is willing to say "continue", and writes why A team that can only recommend a rebuild has not shown it can read code Spolsky argues that rewriting working code from scratch can be a strategic mistake (Spolsky); Fowler prefers "a gradual process of modernization" (Fowler). A good report weighs both; see rewrite or replace step by step
The assessment's scope and cost are written apart from the build You can stop after the report without having committed to the work The question of separating the two jobs, above
Accounts stay in your name Leaving must stay possible The ownership list in our outsourcing guide
Knowledge is written down: decisions, run notes, setup steps You are not replacing one point of failure with another The Joel Test asks twelve yes-or-no questions about how a team works, among them whether it uses source control, can make a build in one step, has a bug database and has a spec (Spolsky)

NIST's Secure Software Development Framework says its common vocabulary lets "software purchasers and consumers" use it "to foster communications with suppliers" (NIST SP 800-218). You do not need to adopt the framework; it is a reminder that asking a supplier how it develops, tests and releases software is a normal buyer's question, not a rude one.

Twelve questions to ask a software project rescue partner

These are specific to a takeover. For the general questions to put to any software supplier, see the twelve in our guide on dedicated team vs project-based outsourcing. Ask in writing and keep the answers in writing.

  1. What will you ask for first, before you quote? A good answer starts with access, documents and the contract, not with a price.
  2. Into whose accounts will you work? The repository and hosting should sit in an organization you control, with an administrator role for you.
  3. Will you do a clean-machine install and a restore from backup, and tell me the result in writing?
  4. What does the written report contain, and who writes it? Ideally the engineer who would do the work.
  5. What would make you recommend continuing with the existing code, and what would make you recommend starting over? Listen for reasons on both sides.
  6. Is the assessment scoped and priced apart from the rebuild, and can I take the report to another team?
  7. What do you do with code that has no tests? One answer is to write tests that record today's behavior before changing anything (Feathers).
  8. How do you handle secrets and keys the previous team knew? Backup first, then revoke and rotate; the OWASP Secrets Management Cheat Sheet says secrets that may have been compromised must be revoked securely.
  9. Who deals with the store accounts and the transfer, if the apps are in the previous team's name?
  10. How do you work if the old system must stay running while you work? A new system built beside the old one, with functions moved over gradually, is one pattern, which Martin Fowler calls the strangler fig (Fowler); ask which they would use and why.
  11. How will you write down what you learn? Decisions with their reasons, setup steps, run notes.
  12. If we part ways after the assessment, what do I keep? The report, the access, the documents.

Reading the answers: green, amber, red

The table is a reading aid, not a verdict. A single amber answer is a reason to ask a follow-up; the pattern across the twelve is what counts.

Topic Green Amber Red
Access Asks to be added to your accounts with a named role Asks for shared logins Wants the only copy in its own account
Quote timing Quotes the assessment first and the work after Quotes both at once, with the assessment inside the build Quotes the rebuild before seeing anything
Verdict Names what would change its recommendation either way Gives a recommendation with few reasons Recommends a rebuild or continuation without looking, or never recommends the other
Report A document another team could use A summary meeting only Nothing written until after you sign for the work
Exit States what you keep if you stop Says "we will sort that out" Treats the question as unwelcome

A comparison sheet: score your shortlist

Copy the table, set the weight of each criterion yourself, and score each candidate from 0 to 2 on what they put in writing, not on what they said. The weights and scores are yours; the sheet carries no figures of ours.

Criterion Weight (1–3) Candidate A Candidate B Candidate C
Asked for access and a clean install before quoting [ ] [ ] [ ] [ ]
Will report a restore from backup [ ] [ ] [ ] [ ]
Written report with reasons [ ] [ ] [ ] [ ]
Can say "continue" and "start over" with reasons [ ] [ ] [ ] [ ]
Assessment scoped and priced apart from the build [ ] [ ] [ ] [ ]
Accounts stay in your name [ ] [ ] [ ] [ ]
Knowledge written down [ ] [ ] [ ] [ ]
Says what you keep if you leave [ ] [ ] [ ] [ ]
Reachable, answers the questions in writing [ ] [ ] [ ] [ ]

Multiply each score by its weight and add up the column. Do not let the total decide: use it to find the two rows where candidates differ most, and talk about those. If two candidates tie, the one that wrote more down leaves you more to fall back on if you part ways.

In what order to do all this

  1. Secure the access and take a full copy, as the takeover guide lists it.
  2. Write down, in a few lines, why you think the project stopped: scope, a team that disappeared, a technical obstacle, work called "done" that is not, or a company that closed. The reason changes which option fits.
  3. Shortlist two or three parties and send each the twelve questions in writing.
  4. Score the written answers on the sheet; leave out what was only said.
  5. Commission the assessment first, with its scope and cost written apart from the work.
  6. Decide on the report: continue, rebuild a layer or start over. Only then scope the work, with whoever you choose.

If you do step 5 and stop, you still hold a document and your access, and nothing is lost but the cost of the report.

Two cases where you may not need a new team yet

The previous team is reachable and the reason was scope or budget. Then the question is not "who else" but "what is the smaller, written scope under which they would finish?" Put the access and a full copy in your accounts first, then write the new scope. If it is not written, the same pattern is likely to return.

Nobody really wrote it. If the project is a prototype generated with an AI tool, the problem is not a team that left but code that nobody has reviewed. Start with the audit in is your vibe-coded app production ready; it needs a reviewer more than a rescuer.

Questions to settle in writing about ownership and the contract

This section is general information, not legal advice. The rights to code, the state of accounts and the position of personal data are covered in the "Ownership and legal notes" section of our takeover guide; read it before you sign with anyone new. For the new party, settle in the written terms two things that people forget: who holds the access once the assessment ends, and who may share the report with another team. The structure of a proposal, and what to read first in it, is in how to read a software proposal. OWASP says the ASVS can "provide a basis for specifying application security verification requirements in contracts" (OWASP ASVS), which is useful when the new work has to meet a security bar. Have a lawyer read any binding contract.

How we do it

Here we only repeat what we say on our site. Our consulting work produces written outputs grounded in the code, the system and the access, not strategy decks. If a ready-made solution, or leaving things alone, suits you better, we say so. The assessment is work like any other: its scope and cost are in a written proposal before you approve anything, and if you want to continue, the scope of the next piece of work is settled the same way. You talk directly to the engineer writing your code, and we work only with senior engineers. As we say on our home page, you can come with an idea, a need or a half-finished project; the method and the duration depend on the state of what you have and are set out in the written proposal. Every engagement is a paid project that starts with a written quote you approve. The approach is on our software consulting and modernization page, and the steps are on the Process page. If you have a half-finished project and want to talk it through, tell us about your project. If you plan to continue as a new build, our custom software development page describes that work.

Frequently asked questions

Can a different company take over a project another company started?

Yes, and it is common. What decides whether it goes well is not the company but the order of work: secure the access and a full copy first, then assess, then decide, with the assessment written down. The audit plan is in our takeover guide.

Should the party that assesses the code also rebuild it?

It can, but ask how the two jobs are kept apart. The assessment should have its own written scope and cost, and the report should be usable by any other team. If you can stop after the report and take it elsewhere, you keep the choice.

Is a freelancer or a company better for a rescue?

It depends on the shape of the job. A bounded fix, or a second opinion on code, suits one person. A job that needs assessment, work and continuity at once puts more weight on written process and on what happens if one person is unavailable. The table in the first section sets out both risks; the outsourcing guide compares the models on eight criteria.

What if the previous developer is still reachable but unreliable?

Ask in writing for the items in the "What to ask the previous team for" table of the takeover guide and keep the answers. Take your own copy of what you can reach, and rotate the secrets they know. Whether to continue with them is a decision for the written scope, not for goodwill.

Do I need an assessment before I ask for a rebuild quote?

A quote for a rebuild given before anyone has seen the system is an estimate. An assessment first turns the question into a written decision: continue, rebuild a layer or start over. The alternative is to accept that the quote will change once the system has been seen, and to ask how the change would be written.

Sources

The pages below were opened and read on November 9, 2026. Pages change over time; reopen the official ones before you act.

This article is general information; it is not legal advice.

— Related serviceSoftware Consulting and Modernization

All articles