How to take over an unfinished software project: a step-by-step audit plan
C.E.O. Bee Engineering17 min read
When you take over an unfinished software project, first secure what can disappear: access to the repository, hosting, domain, database and third-party accounts. Then follow a step-by-step audit plan: a clean-machine install, a restore from backup, security and data health, and a feature inventory. The decision (continue, partial rewrite or start over) comes from a seven-dimension matrix scored 0 to 2 and is written down with its reasons. How long it takes depends on the code, documents, access and platforms, and is stated in the written quote.
The first 48 hours: secure access and evidence
When you take over an unfinished software project, the first reflex is to look at the state of the code. Something more urgent is to secure what can disappear: access to an account, a domain name, a copy of the database. Judging the code can wait a week; a domain name sitting in the former developer's account will not wait. Whether the project was built as custom software or not, the order is the same. The list below is a template; the size of the project sets the time.
- Source code repository. In whose account is it? The repository should be added to your organization with an admin role, or a copy with all branches and tags should be taken:
git clone --mirror <address>. - Hosting and servers. The account owner, who the bills go to, admin access and server keys.
- Domain name and DNS. Whose account at the registrar holds the domain? Who manages DNS? If the domain is in the former developer's account, access to your website and email stays dependent on them; this is the most urgent item on the list.
- Store accounts. In whose name are the Apple and Google developer accounts? Both stores have a transfer route. At Apple, an app transfer is started by the Account Holder of the transferring account and must be accepted by the receiving Account Holder; before a transfer, TestFlight beta testing must be turned off and Xcode Cloud data removed, and if the app has auto-renewable subscriptions an app-specific shared secret has to be generated and shared with the recipient (Apple). On Google Play both developer accounts must be registered and active, you need the target account's registration transaction ID, and support replies to the request within two business days; users, ratings and the store listing move with the app, while bulk export, sales and earnings reports and test groups do not (Google). Transferring the whole account involves a seven-day security hold and cannot be done self-serve if the account owner has lost access (Google).
- Third-party accounts. Payment provider, email and SMS service, analytics, maps, notifications, AI APIs, error tracking.
- Database. Where is it, in whose account, who holds the access details? Take a full dump.
- Email. Email accounts tied to the domain and the sending service.
- Backup first, then rotate keys. Back everything up first, then change every key, password and token you can reach: every secret that the former developer or the former tools knew can no longer be considered safe. If a secret has leaked, or may have leaked, revoke and rotate it first: OWASP says secrets that may have been compromised must be revoked securely (OWASP). Deleting it from the history alone is no substitute.
- Documents. The contract, the proposal, invoices and payment records, delivery records, correspondence. Back any claim about scope and handover with these documents.
What to ask the previous team for
If the previous team can be reached, ask for the list below in writing and keep the answers. If they cannot be reached, each row is a risk line that shows what not having the item means.
| Item | Why it is needed | What happens without it |
|---|---|---|
| Source code (all branches and history) | The foundation of everything | You are left with the running version only; nothing can be changed |
| Database dump and schema | The data and the data model | You depend on live data and a rebuild is impossible |
| List of environment variables (names; values over a secure channel) | Which services does the app connect to, with which settings does it run? | Setup becomes guesswork |
| Deployment scripts and infrastructure definition | How is the system released and rebuilt? | Every release and every disaster recovery turns into discovery work |
| Design files | The source of the screens and the brand | The interface is redrawn |
| API documentation and integration details | How the system talks to outside systems | Integrations are worked out by reverse engineering |
| Account ownership and admin access | Who holds control | The accounts stay in the previous team's hands |
| List of open tasks and known bugs | Where things were left | The feature inventory has to be built from scratch |
| Setup and run notes | Continuity of knowledge | A clean-machine install turns into trial and error |
Make the request in writing and keep the reply; if none comes, show the contract to a lawyer to learn your legal options.
Why did it stall? How to look at the audit
Two unfinished projects that look the same may have stalled for different reasons, and the reason changes what you look for in the audit. No row in the table is a verdict; each is a starting question.
| Possible reason | Question the audit puts first | Effect on the decision |
|---|---|---|
| Scope grew and the budget or time ran out | What is the gap between the contractual scope and today's feature inventory? | The code may be sound; the real job is cutting the scope again |
| The developer or team disappeared | What knowledge lived only with them (access, environment, documents)? Does a clean install work? | The installability and continuity scores decide |
| A technical obstacle was hit (performance, integration) | Is the obstacle an architectural limit or a fixable bug? | If it is structural, a partial rewrite comes into play |
| It was called "done" but does not work or is poor quality | Were acceptance criteria written? What is the state of tests and security? | The test and security scores weigh more; the evidence may also be needed in a legal assessment |
| The company closed or the work changed hands | Who holds the accounts and the rights to the code? | Ownership and access are settled before the technical decision |
The audit: a step-by-step plan
The plan is a template, divided into steps, and we give no number of days or weeks for the audit. How long each step takes depends on the state of the code, the documents, the access and the platforms, and is stated in the written quote.
| Step | To do | Output |
|---|---|---|
| 1. Inventory and install | Inventory (repository, environments, accounts, third parties). Clean-machine install from scratch: clone, install dependencies, build, run, run the tests. Restore from a backup. Dependency and security scan: npm audit --omit=dev, secret scan of the repository history (git log --all -S"sk_live_"). |
Inventory table; an install-steps document (every manual step you needed is written down); the "does it install or not" verdict; list of vulnerabilities |
| 2. Code and data health | Code and data health: architecture, test coverage and meaning, complexity, data model, secrets, performance. Comparing the contract and scope with the current state: the feature inventory. | Code and data findings; feature inventory ("exists and works," "exists but half-done," "missing") |
| 3. Decision | Scoring the decision matrix and drafting options. | Scored matrix; a scope and risk note for each option |
| 4. Report | Written report and a proposal for the new scope; if you continue, the first work packages. | Report (outline below); scope draft |
Code and data health: what to look for and which command to start with
The second step is where most measurable evidence is collected. The starting points below are examples for Git and Node.js projects; other technologies have equivalents.
| What to look at | Why | Starting point |
|---|---|---|
| Who wrote it and when | Does the code depend on one person, is there a long silence? | git shortlog -sn --all and git log -1 --format=%cd |
| Most-changed files | Files that keep changing are trouble spots or carry too much responsibility | The first command below |
| Largest files | Is the logic concentrated in a few giant files? | The second command below |
| Age of dependencies | How far behind are they? | npm outdated |
| Known vulnerabilities | Any high or critical issue in production packages? | npm audit --omit=dev |
| Leaked secrets | Is there a live key in the repository history? | git log --all --oneline -S"sk_live_" |
| Data model | Are constraints, relations, indexes and migrations in place? | Export the schema and read it: pg_dump --schema-only |
| Tests | Do they run, and do they fail when a rule is broken? | Run them; break a rule on purpose and see the result |
# most-changed files
git log --name-only --pretty=format: | sed '/^$/d' | sort | uniq -c | sort -rn | head
# largest source files
find . -name "*.js" -not -path "./node_modules/*" -not -path "./.git/*" -print0 | xargs -0 wc -l | sort -rn | head
These numbers do not give a verdict on their own; they tell you where to look more carefully.
Three details decide the value of the plan.
A clean-machine install. That a project runs on one person's computer does not prove it "works." Every undocumented manual step you need during setup is a knowledge-continuity debt and goes into the report. You can use this step together with the commands in the 15-point production-readiness audit.
A feature inventory is not "percent complete." Saying what percentage of an unfinished piece of software is done is easy and misleading: the work that remains after the seemingly finished part can cost more than the part before it. Instead, write each feature's state with a measurable label: working, half-done, missing.
Before touching code without tests. Before you change code that has no tests, you write "characterization tests" that record its current behavior as it is; the aim is to pin down what the code does, not what it should do (Feathers).
The decision matrix
The decision matrix guides; it does not pass judgment. Each of seven dimensions gets 0, 1 or 2 points (total 0–14).
| Dimension | 0 points | 1 point | 2 points |
|---|---|---|---|
| Installability | Does not install on a clean machine, or needs knowledge from the former developer | Installs, but with undocumented manual steps | Installs in one pass by following the documentation |
| Tests and structure | No tests, tangled code | Partial tests, inconsistent structure | Meaningful tests on critical flows, readable layers |
| Security | Leaked secret, an access-control hole or a known critical vulnerability | Small fixable weaknesses | The basic checks (authentication, authorization, secrets, input validation) pass |
| Data model | Inconsistent, no constraints, risky to migrate | Gaps, but convertible | Consistent and extensible |
| Architectural fit | The new scope does not fit the current structure | Fits with major adaptation | Fits |
| Documentation | None | Scattered | Setup and architecture documented |
| Knowledge continuity | Nobody knows the code, the previous team is unreachable | Partly reachable | The knowledge is in documents or with the team you still have |
Decision bands (a suggestion, not a standard): 11–14 points continue; 6–10 points partial rewrite (weak layers are rebuilt, sound ones kept); 0–5 points start from scratch (screens, flow and what you learned are kept, the code is not). If security or the data model scores zero, that layer has to be rebuilt whatever the total.
What the three decisions mean in practice can be summarized like this.
| Decision | Kept | Rebuilt | Typical signal | Watch for |
|---|---|---|---|---|
| Continue | The code, the data model and most of the structure | Missing features and small fixes | Installs; security and data model at 1 point or more | Add tests as you go |
| Partial rewrite | Sound layers (for example the data model or the interface) | Weak layers (for example authorization or payments) | Some dimensions at 0, others at 2 | Set the layer boundaries; make the transition gradual |
| Start from scratch | Screens, flow, lessons learned; data by migration | The code | Most dimensions at 0; will not install, security or data model fundamentally unsound | If the old system is running, run both in parallel; write a data migration plan |
The matrix helps you find a path between two familiar extremes. Joel Spolsky argued that rewriting working code from scratch can be a strategic mistake, because old code carries years of tested bug fixes (Spolsky). Martin Fowler's "strangler fig" approach suggests building the new system alongside the old one and moving functionality over gradually, rather than replacing it in one move (Fowler). Sometimes starting from scratch is right, and the audit will say so. There is no rule, only a reasoned decision.
After the decision: cutting the new scope
If the decision is "continue" or "partial rewrite," the feature inventory is the raw material of the new scope. Put every feature into one of three boxes: now, later, never. If the "never" box is empty, the scope has not been cut yet. Trying to finish the whole of the old scope in one go sets up the same risk of stalling again. The scope-cutting method we describe on our MVP development page helps here as well: one main flow, one hypothesis to test, and how you will measure success. When you write the new scope down, the scope of work (SOW) template in how to read a software proposal can serve as a starting skeleton.
Report outline
The output of the audit is a written report. The ten headings below give an outline that both you and the next team can read.
- Summary and recommended decision (one page)
- Scope and method: what was examined, what was not
- Access and ownership inventory
- Install result (clean machine)
- Feature inventory: contract versus current state
- Security and data findings, in order of severity
- Code and architecture assessment
- Decision matrix and the reasoning behind each score
- Options: continue, partial rewrite, start from scratch; scope, risk and dependencies for each
- Proposed new scope and next steps
In the report, write measurable states and reasons instead of percentages and duration estimates.
Ownership and legal notes
This section is not legal advice; it only shows which questions to ask. Have a lawyer read the contract.
- Rights to the code. Getting hold of the code may not be the same as owning the rights to it. Rules differ by country; under Turkish law, Article 52 of Law No. 5846 on Intellectual and Artistic Works requires contracts and dispositions concerning economic rights to be in writing, with the rights concerned listed separately (mevzuat.gov.tr, in Turkish). Is the transfer in writing in the contract you had with the previous team?
- Accounts. In whose name are the developer, repository and hosting accounts? There are official routes for store transfers (above); if the account is in the previous team's hands, the process may take longer.
- Licenses. The licenses and contracts of third-party libraries and services should be reviewed separately from the transfer of the code.
- Personal data. User data may have stayed on the previous team's systems. Under Article 12 of Turkey's Law No. 6698 (KVKK), the data controller must take the necessary measures and, when data is processed on its behalf by someone else, shares responsibility with them (mevzuat.gov.tr, in Turkish). Put the transfer of data to the new team under a written arrangement.
How to model the cost
The cost of taking over an unfinished software project is not a single item. A sensible structure is a fixed-scope audit first, then a scope-based project built on the audit's output, because a project price given before you know what will be rescued is an estimate. What drives the cost of the audit itself is the size of the code, the state of documents and access, the number of integrations and platforms (web, iOS, Android) and the volume of data. We give no figures in this article. For the general breakdown of what sets a price, see the "What drives the price" table on our custom software development page. If the unfinished thing is a mobile app, the line items to look for in a proposal are in mobile app development cost.
Next step
As we say on our home page, you can come to us with "an idea, a need, or a half-finished project"; we start where it makes sense for you. We talk through what you have and put the way forward into a written quote; the method and the duration depend on your situation and are stated in the quote. Describe your project, or first read our custom software development page.
Frequently asked questions
What if the previous developer will not hand over the code?
Start with your contract and payment records: what was supposed to be delivered? Make the request in writing and keep the reply; for legal options, show the contract to a lawyer. If the hosting account is yours, it may be possible to take a copy of the running version and the database from the server; that is the most current truth you have, but it is not a substitute for the source code. Before you use such a copy, check the rights and licensing clauses in your contract.
What does the cost of a takeover depend on?
The size of the code, the state of documents and access, the number of integrations and platforms, the data volume and the size of the new scope. We give no figures here; a fixed-scope audit first and a scope-based quote afterwards takes the price out of the realm of estimates.
How long does the audit take?
The audit plan in this article is a template divided into steps, and it contains no durations. The real duration depends on the size of the code, the state of documents and access, the number of platforms and integrations. With us, the method and the duration depend on your situation and are stated in the written quote.
Do you work on code written by another company?
On our home page we say you can come to us with "an idea, a need, or a half-finished project." We talk through what you have and decide, with the reasoning in writing, whether to build on it or start again. The method and the duration depend on your situation.
Do we need to start from scratch?
Sometimes, yes. The decision matrix helps: if security or the data model scores zero, that layer is rebuilt; the screens, the flow and what you learned can often be kept. The decision should be written down with its reasoning.
Sources
The pages below were opened and read on October 24, 2026. Store rules may change over time; reopen the official pages before you act.
- Apple: App Transfer overview · Google Play: transfer apps to a different developer account · Google Play: transfer ownership of a developer account
- OWASP Secrets Management Cheat Sheet · npm audit
- Michael Feathers, Characterization Testing · Joel Spolsky, Things You Should Never Do, Part I · Martin Fowler, Strangler Fig Application
- Law No. 5846 on Intellectual and Artistic Works, mevzuat.gov.tr, in Turkish · Law No. 6698 on the Protection of Personal Data, mevzuat.gov.tr, in Turkish
This article is general information; it is not legal advice.
— Related serviceCustom Software Development