Short answer: stop adding features, get administrative control of the repository, hosting, domains and store accounts, and commission an independent code audit before deciding anything else. Most troubled projects turn out to need stabilization and a partial rewrite of one weak area, not a fresh start. A full rewrite is justified only when the audit finds specific, structural reasons for it.
Signs a project is failing
One of these on its own is a bad month. Several together, persisting for more than a few weeks, mean the project will not recover without a change.
What you can see without reading code
- No working software to open. Progress is reported in percentages, screenshots or slides, and there is no staging link you can use yourself.
- "90% done" for weeks. The remaining 10% never shrinks, which usually means the hard parts were postponed.
- Deadlines move without a revised plan. Each slip is explained; none comes with a new date that is then met.
- Fixes break other things. Every release reintroduces old bugs, a sign that there are no automated tests and the code is tightly tangled.
- The team has changed and nobody said so. New names appear in messages, and answers about earlier decisions become vague.
- Replies slow down and get shorter. Questions about progress are answered with questions about payment.
- Invoices arrive on time; demos do not.
- You are asked to pay ahead of the schedule to "unblock" work.
What a technical look reveals
- You do not have access to the repository, or it was last updated weeks ago while work was supposedly continuing.
- The code lives in the vendor's accounts, and so do hosting, the domain or the app store listing.
- Nobody can explain how to deploy the product, or deployment means one person copying files by hand.
- There is a single environment: changes are tested on the live product.
- Secrets such as API keys and database passwords are written into the code.
- There are no database backups, or nobody has ever tried restoring one.
If you recognize the first list but cannot check the second, that gap is the first thing to fix.
Week one: secure access and stabilize
Do this before any confrontation with the current vendor and before choosing a new one. The aim is that whatever happens next, the product and its data remain under your control. Stay within what you own and what your contract allows; if there is any doubt about either, ask a lawyer first.
| Asset | What to obtain | Why it matters |
|---|---|---|
| Source code repository | Owner or admin rights in an organization your company controls; a full clone with history stored somewhere separate | Without the code there is nothing to rescue |
| Hosting and cloud accounts | Account ownership or admin access; billing in your name | Whoever pays the bill can switch the product off |
| Database | A recent backup that you hold, and confirmation that it restores | User data is usually the hardest thing to recreate |
| Domain registrar and DNS | The registrar account in your company's name; note the renewal date | Losing the domain takes email and the product with it |
| Apple Developer and Google Play accounts | Account holder role with your company; if the app is published under the vendor's account, request an app transfer | Store listings, reviews and subscribers are attached to the account |
| App signing keys and certificates | Android upload keystore and passwords, iOS certificates and provisioning profiles, push notification keys | Without them, shipping an update can range from awkward to impossible |
| Third-party services | Owner access to payments, email and SMS, analytics, maps, authentication, error monitoring, AI APIs | Each holds data and configuration the product depends on |
| Secrets and environment configuration | The production environment variables, stored in a password manager your company owns | The code does not run without them |
| Design files | Ownership of the design workspace, or exported source files | Rebuilding screens from screenshots is slow |
| Documentation and history | Exports of the task tracker, specifications and chat decisions | It is the only record of why things were built as they were |
Once you hold admin rights, add your own administrator before removing anyone, and do not revoke the old team's access until you have decided how the relationship will end. After the handover is complete, rotate every password, key and token they could see.
In the same week, freeze features. Only fixes for problems that harm live users should go out. New work on an unstable base makes the audit harder and the eventual bill larger.
Week two: the code audit
An audit is an independent engineer or team reading the code, building it, running it and reporting what they found. Independence matters: the current vendor has reasons to say everything is fine, and a prospective new vendor has reasons to say everything must be rebuilt. Ask for findings with evidence, such as file references and reproduction steps, so that a third party could check the conclusions.
What a good audit examines
| Area | Questions it answers |
|---|---|
| Build and run | Can a new developer get the product running from the repository and the documentation? How long does it take? |
| Completeness against scope | Which agreed features work, which partly work, which do not exist? This is often the first honest progress figure the founder has seen. |
| Architecture and structure | Is the code organized in a way that another team would recognize? Is business logic separated from interface code, or scattered through it? |
| Data model | Do the database tables reflect the business correctly? Are there constraints, migrations and indexes? Mistakes here are the most expensive to fix later. |
| Security | How are authentication, authorization, secrets, input validation and personal data handled? Can one user read another's data? |
| Dependencies | Are frameworks and libraries current, supported and appropriately licensed? Is anything abandoned? |
| Tests | Are there automated tests, do they run, and do they cover the workflows that matter? |
| Deployment and operations | Is there a repeatable deployment, separate staging and production, backups, logging and error monitoring? |
| Performance | Are there obvious problems at current usage, such as slow queries or screens that load everything at once? |
| Store and platform compliance | For mobile apps: will the next submission pass current store requirements, such as target API level, privacy declarations and billing rules? |
| Third-party and IP hygiene | Is there copied code, a purchased template or a vendor-owned framework that limits what you can do with the product? |
What you should receive
- A written report in plain language, with a technical appendix
- Findings ranked by severity: critical, important, minor
- A feature-by-feature status against the original scope
- A recommendation: fix, partial rewrite or full rewrite, with reasons
- An effort estimate for the recommended route and for at least one alternative
- A list of what could not be assessed and why
Pay for the audit as a separate, fixed-fee piece of work. It keeps the auditor's incentives clean, and the report is yours to take to any team. How a fixed-fee assessment fits with the pricing of the work that follows is explained in choosing between fixed price and time and materials.
Fix, partial rewrite or full rewrite
This is a decision about economics, not pride or blame. The question is which route reaches a stable, maintainable product for the least total cost and risk.
| Criterion | Fix what exists | Partial rewrite | Full rewrite |
|---|---|---|---|
| Technology stack | Common and current | Common; one layer outdated or badly chosen | Obsolete, obscure, or a platform that cannot do what the product needs |
| Data model | Sound | Mostly sound; one area wrong | Wrong at the core, with everything built on top of it |
| Structure | Recognizable, if untidy | Good in places; one module tangled | No separation of concerns anywhere; every change breaks something else |
| Builds and runs | Yes | Yes, with effort | Nobody can produce a working build |
| Security findings | Isolated and fixable | Concentrated in one area, such as authentication | Throughout |
| Share of scope that works | Most of it | About half, with the rest blocked by one weak area | Little, or it demonstrates well and fails in real use |
| Live users and data | Yes; continuity matters | Yes; replace parts behind a stable interface | None or few, or the data can be migrated cleanly |
| Estimated cost to stabilize | Well below the cost of rebuilding | Below rebuilding once the weak part is replaced | Close to or above the cost of rebuilding |
Decision rules
- Default to fixing. Working code that users rely on contains knowledge that a rewrite has to rediscover, one bug at a time.
- Rewrite the part, not the whole, when the problems cluster: a backend that is sound behind a mobile app that is not, or the reverse. Replace the weak part and keep the rest.
- Rewrite fully when the audit finds structural reasons in at least two of: stack, data model, structure, security. Reuse everything that is not code: designs, specifications, content, data and what you have learned about users.
- Be wary of a rewrite recommendation with no specifics. "The code is a mess" is an opinion. "User passwords are stored unhashed, there are no foreign keys, and the payment logic is duplicated in four places" is a finding.
- Be equally wary of sunk cost. What you have already spent is not a reason to keep code that will cost more to repair than to replace.
If you do rewrite, write the scope this time with priorities and testable criteria. The software project brief template is a starting point, and the audit's feature status list gives you most of the content.
Dealing with the previous vendor
How you handle this affects how much you recover. The practical aim is a complete handover, not a verdict on who was at fault.
- Read the contract first. Look for IP assignment, what happens on termination, notice periods and payment for work in progress. The guide to development contract clauses explains what each should say. If the wording is unclear or the sums are significant, involve a lawyer before you send anything.
- Keep communication written, factual and calm. Accusations produce defensiveness and delay. A specific list of what you need produces results more often.
- Separate the handover from the dispute. You can request the repository, credentials and documentation now and leave disagreements about quality or refunds for afterwards.
- Settle what is fairly owed. If delivered work is unpaid, paying it, possibly against simultaneous handover, is usually faster and cheaper than a standoff. Offering a few paid hours for a handover call is often money well spent.
- Send a handover checklist. Repository with full history, environment configuration, signing keys, third-party accounts, design sources, database backup, deployment notes and a list of known issues.
- Verify before you close. Have your new team confirm that the product builds and deploys from what was handed over. Then rotate credentials and remove access.
- If the vendor has disappeared or refuses, gather what is already in your name, recover what you can from installed apps, servers you control and backups, and take legal advice on the rest.
Sometimes the right outcome is that the original vendor stays. If the audit shows sound code and the real problem was scope or management, a reset with a revised plan, visible milestones and an independent reviewer can cost less than a transition.
How to avoid repeating it
Failed projects rarely fail for purely technical reasons. The audit report usually points back to a handful of structural gaps, and each has a simple countermeasure.
- Repository, hosting, domains and store accounts are in your company's name from the first day, with the vendor given access
- Code is pushed to your repository continuously, not delivered at the end
- The scope has priorities and acceptance criteria that can be tested
- Payments follow deliverables you can open on a staging environment
- There is a demo of working software every one to two weeks
- A written update each week covers what was done, what is next, what is blocked and the budget used
- An independent engineer reviews the code at a midpoint milestone, not only when trouble starts
- Deployment, environments and backups are documented as deliverables
- The contract covers IP assignment, termination and handover, and a lawyer has read it
- One person on your side can make product decisions within a day
When choosing the next team, ask how they approach code they did not write, and listen for a process instead of a verdict. The questions worth asking a development agency cover ownership, handover and what happens if you part ways. Budget for the period after the rescue too; the guide to ongoing app maintenance costs gives planning figures.
How BBR approaches a takeover
BBR can join or take over existing codebases. The engagement starts with a fixed-fee assessment that produces a written plan, as described on the how we work page, and you are free to take that plan elsewhere. The work that follows depends on the findings: a defined stabilization project under custom software development, or continuing development and maintenance as a monthly product engineering engagement. If the stack is outside what BBR works in, we will say so at the start instead of learning on your budget.