Signs your software project is failing, and five tests you can run without reading code

“We’re paying for a software project and can’t tell if it’s going well.” If you lead an operations team, a plant or a contractor network and you’re paying for a portal, a scheduling tool or a replacement for an old internal system, you likely get status reports you can’t verify. This guide covers the red flags in a software development project a non-technical owner can spot, five tests to run this week and how to decide what to do next.

The short answer: judge outcomes, not status reports

Status reports describe effort: hours logged, percent complete, “almost done.” Outcomes are things you can check yourself: a feature you can click through, a release your team actually uses, a bug that stayed fixed. A project can report steady progress for months and produce almost none.

The classic version is a project stuck at “90% done.” The last stretch holds the work that’s hardest to estimate: connecting to other systems, moving real data, handling the odd cases and deploying. If every report is about effort, start asking for outcomes instead.

Schedule and communication warning signs

A late project isn’t automatically a failing one. Scope changes and surprises happen on healthy projects too. The warning sign is lateness nobody saw coming and nobody can explain.

• The date moves and the plan doesn’t. A new launch date arrives with no new list of what’s left. If nothing about the plan changed, the new date is a guess too.
• The reasons stay vague. “It’s more complicated than we thought” is fair once. The second time, ask which part, and what the team learned.
• Updates get shorter, then rarer. Weekly calls turn into occasional emails, and the emails stop naming specific features.
• You never hear from the people writing the code. Every question goes away to be checked and comes back days later as a summary, so you can’t ask a follow-up.
• Invoices keep arriving for work you can’t see. Month after month of “refactoring,” “infrastructure” or “setup,” with nothing you can try.
• The people keep changing. The developer who knew your project moved on, and the replacement is still getting up to speed weeks later.

What a healthy answer sounds like

Ask three questions: what’s done, what’s left and what could move the date? A healthy team answers with specifics: named features, a short list of open items and the one or two risks it’s watching. A fresh estimate with no list behind it is a warning sign.

Quality warning signs: bugs outpacing features, fear of releasing

These show up in the software itself, and your users will report them long before a status email does.

• Bugs come in faster than features go out. The open-bug list grows each month while the list of new features shrinks.
• Fixes don’t stay fixed. A bug that was closed last month is back this month.
• Every fix breaks something else. That often means there’s little or no automated testing (code that checks the software before each release) to catch side effects.
• Releases are rare, big and stressful. Changes pile up for a large release every few months, scheduled late at night with everyone on standby.
• Only one person can deploy. Releases depend on one laptop or one person’s memory.
• Your team works around the software. Spreadsheets on the side, double entry and notes that say “don’t click that button.”
• It slows down as real data arrives. Screens that were quick in the demo crawl once real records are loaded.

Access and ownership warning signs (the ones owners miss)

These signs don’t appear in status reports or in the software. They appear the day you need to change developers, which is when they’re hardest to fix. Check them while the relationship still works.

Being able to log in isn’t the same as owning. Collaborator access can be removed at any time, and an account in a developer’s name renews on their card. If any row lands in the right-hand column, fix it now. Our guide to what to do when your developer disappears covers the contract questions in more detail. Ownership is a legal question, so ask your attorney.

Five tests you can run this week without reading code

Each test is one request you can put in an email today. You’re not checking the code; you’re checking whether the project is visible, transferable and moving. A healthy team answers all five without much fuss. A team that resists all five is telling you something.

1. Ask for a working demo on a staging copy

A staging copy is a separate copy of the system for trying changes without touching the live one. Ask for your own login, then complete one real task from start to finish with realistic data. Pass: you log in and finish the task yourself. Warning sign: screenshots, a recorded video, or a demo that only runs on the developer’s screen.

2. Ask for repository and hosting access in your company’s name

Ask to be added as an administrator on the code repository and the hosting account, or better, ask for both to move into accounts your company owns. On GitHub, only someone with administrator access to a repository can transfer it, and the commit history comes with it, according to GitHub’s documentation on transferring a repository. In practice the current developer has to start the transfer, which is why you ask while they’re cooperating. Pass: you have administrator access by the end of the week. Warning sign: delays, conditions or “we don’t usually do that.”

3. Ask whether anyone else could deploy it

Ask for the written deployment steps: how a change gets from code to production, and how to roll it back. Then ask directly: “If you were unavailable tomorrow, could another developer release a fix from these notes?” Pass: a written runbook, or an automated release process, that someone other than its author has used. Warning sign: “It’s easier if I just do it.”

4. Ask for the bug-trend list

Ask for bug counts for each of the last three months: how many were opened, how many were closed and how many came back after being fixed. You’re not judging the total, since every system has bugs. You’re judging the direction. Pass: numbers from a bug tracker, flat or falling. Warning sign: no tracker, or bugs that live in email threads.

Here the team closes fewer bugs each month while more arrive and more come back. That’s “bugs outpacing features” on paper, and it won’t fix itself.

5. Ask what shipped in the last 30 days

Ask for a list of what reached production, meaning live for real users, in the last 30 days. Not what was worked on: what shipped. Then find each item yourself. Pass: specific changes you can find and use. Warning sign: an empty list, or one made of “progress on,” “refactoring” and “setup.” A quiet month can be legitimate, such as a large data move, but the team should be able to say what that work makes possible.

Course-correct, get a second opinion, or rescue: how to decide

Your answers point to one of three paths. Two questions decide which: do you control access, and can the current team still deliver working software?

A second opinion doesn’t have to mean firing anyone. A confident team has little reason to object to a review of its work. If you do decide to switch, our guide to switching software developers mid-project walks through the handover from your side.

What not to do

• Don’t pay a large final invoice before you have access. Once the last payment clears, you have less leverage to get the code, the accounts and the deployment steps. Where you can, tie remaining payments to the handover, and take legal advice on your contract before you withhold anything.
• Don’t start a rewrite out of frustration. Starting over throws away the parts that work, along with the business rules buried in them. Get a review first.
• Don’t add developers to a late project before you know why it’s late. New people need someone to bring them up to speed, and that someone is the team that’s already behind.
• Don’t announce a switch before the accounts are in your name. Account transfers go far more smoothly while the relationship is still cooperative.

What the start of a rescue looks like

A rescue starts with access and understanding, not new code. These are the steps we plan for when we take over a codebase someone else wrote, and they’re a fair standard to hold any new team to.

1. Secure access in your company’s name. Code repository, hosting, domain, database, app store accounts and the keys for outside services. The software handover checklist turns this into a request list for the outgoing developer.
2. Run it from a fresh copy. The new team pulls the code onto a clean machine and gets it running. Anything that only exists on the old developer’s laptop surfaces here.
3. Review what exists. Architecture, security and stored secrets, outdated dependencies, backups and deployability, with a recommendation for each part: keep it, harden it or rebuild that piece.
4. Set up a staging copy and write down how it works. Setup, deployment steps, integrations and business rules get documented, so the knowledge stays with your company.
5. Ship one small change all the way to production. A low-risk fix your users have been asking for goes through code, review, staging and release. It proves someone new can change and release the system.
6. Agree on priorities. Then pick up what the original project never delivered, in the order the business needs it.

How long each step takes depends on what the review finds, so ask for the review before you ask for a date.

When we take on a rescue, you talk directly to the U.S.-based engineers reading and changing your code, and the same engineers stay on to maintain the system once it’s stable. Our software project rescue page explains how we work, and our guides cover more of the software operations teams run on.