What do you do when a software project stalls?

What do you do when a development project stalls?

Stop commissioning new work and get an independent assessment of what exists. A stalled project has two separate problems — the state of the code and the state of the relationship — and they get conflated, which is how a codebase that was 70% finished gets thrown away because the person who wrote it stopped answering email. Establish what you own and what works before deciding what to do about it.

The order matters. Secure access to everything first, assess second, decide third. Doing it in the other order is how people discover that the app store account and the signing keys belonged to someone who is no longer speaking to them.

Should you rebuild from scratch or continue the existing codebase?

Continue when the architecture is sound and the problems are incompleteness, untidiness or outdated dependencies — all of which are hours of work, not conceptual problems. Rebuild when the foundation is wrong for what the product now has to do: a data model that cannot represent the real domain, a platform choice that cannot deliver a core requirement, or security built in a way that cannot be retrofitted.

The bias worth correcting is that rebuilding feels much more attractive than it is. A rewrite starts with every solved problem unsolved again, including the unglamorous ones nobody documented — the edge cases, the platform quirks, the payment-provider behaviour someone spent a fortnight discovering. A messy codebase that works contains knowledge that a clean empty one does not.

What does a codebase assessment actually check?

Not code style. The questions that determine whether a project is recoverable are mostly mechanical, and most can be answered in the first day of reading:

1. Does it build from a clean checkout, on a machine that has never seen it, following only the written instructions? This single test is the most informative thing in the list.
2. Is there real version control history, or one commit called “initial commit”? History is documentation of intent, and its absence is a genuine loss.
3. How old are the dependencies, and do any have known vulnerabilities? Three years of neglect is usually days of upgrade work; it is rarely a reason to rebuild.
4. Are credentials committed into the repository? If so, treat every one as compromised and rotate it, regardless of what happens to the code.
5. Are there tests, and do they pass? Few tests is normal. Tests that have been failing for a year tell you something about how the project was actually run.
6. Can the application be deployed by someone other than the original author, in a way that is written down?
7. Does the data model support what the product needs next, or only what the first demo needed? This is the question most likely to justify a rebuild.
8. Which third-party services does it depend on, and whose accounts are they in? Every answer of “the developer’s” is a task.
9. For mobile: who holds the developer accounts, the signing keys and the provisioning profiles, and are the store listings in your name?

What do you need to collect from the previous developer?

Collect all of this while the relationship still functions, even if you have not decided anything yet. It becomes dramatically harder once a developer has moved on, and some of it cannot be recovered at all:

• The repository with its full history, not a zip of the current files.
• Every third-party account transferred into your name and billing: cloud, database, error tracking, analytics, email delivery, payments.
• App store and Play Console developer accounts, plus signing keys, certificates and provisioning profiles. Lost iOS signing material is the single most expensive thing on this list to replace.
• Environment variables, secrets and configuration for every environment — and confirmation of which ones are live.
• Domain registrar and DNS access. People forget the domain is the one thing that cannot be rebuilt from source.
• Design source files, not just exported images, and any brand assets.
• Whatever documentation exists, including rough notes. Notes are better than nothing and nothing is the usual alternative.
• A written list of known bugs and unfinished work. Most developers will give you an honest one if asked while on good terms.

If you take one thing from this page: get the accounts and the signing keys into your own name before you need them. It costs an email now and can cost a rebuild later.

What are the real signs a rebuild is the right call?

Rebuilding is occasionally correct. The honest indicators:

• The data model cannot represent the domain as the product now works, and migrating it touches everything.
• A platform decision blocks a core requirement — a technology that cannot deliver offline support or background processing the product needs.
• Security or privacy has to be structural, and the existing design put it nowhere.
• Nobody can get it running at all, including from a clean checkout with the original author’s help.
• The remaining work is genuinely larger than starting over, measured by someone who has read the code rather than estimated from the outside.

“It is messy”, “it uses a framework I would not have chosen” and “the previous developer was not very good” are not on that list. They are normal properties of working software.

Why is “the last developer was incompetent” usually the wrong conclusion?

Because it is usually not what happened, and believing it means repeating the cause. Stalled projects are far more often the result of process than of ability: scope that grew without ever being re-scoped, no written specification so that two people held different products in their heads, part-time attention on something needing sustained focus, or key decisions made by somebody who has since left and took the reasoning with them.

This matters practically, not diplomatically. If the real cause was undocumented scope creep and you conclude the developer was bad, you hire a better developer, give them the same undocumented growing scope, and stall again eighteen months later having spent the budget twice. The assessment is worth as much for diagnosing how the project was run as for reading the code.

How long does an assessment take, and what should it produce?

How long a codebase assessment takes depends on the size of the codebase and how much of the access — repository, accounts, signing keys, deployment credentials — is already in your hands, and anyone quoting a fixed duration before seeing the repository is guessing. For a single application of ordinary size an assessment is days of reading rather than weeks — the clean-checkout build test alone answers a surprising amount on the first day.

What an assessment should produce is a written document, not a verbal reassurance: what exists, what actually runs, what is missing, what is at risk, a rebuild-or-continue recommendation with the reasoning exposed so you can disagree with it, and a scope for whichever path you choose. If the reasoning is not shown, you cannot tell an assessment from a sales pitch for a rebuild.

How does Percuno take over a stalled codebase?

Taking over a stalled or inherited codebase is one of the four kinds of work Percuno does, and it starts the same way every time: reading the code, running the clean-checkout test, and writing the technical scope for the work that follows — including the case where that scope says the existing code is sound and what actually failed was how the project was run. Percuno is one engineer, so it takes one project at a time, and writing the scope is deliberately a smaller and separate commitment from the build it may lead to.

Scope, price and timeline are given in writing before work starts, and the client owns the delivered code outright on full payment. The services page describes how projects work; hello@percuno.com reaches the engineer directly. Percuno is a new company with no clients yet, so there are no case studies on this site — the about page sets out the engineering background behind it instead, which is the thing you can actually check.