You can tell a software project is going wrong without technical knowledge. The signs, from mild to serious: demos are postponed or replaced by slides, the same feature is reported as nearly done for several weeks, the team changes without explanation, questions get vague answers, the bug list is missing or never shrinks, you cannot access the code or accounts, and the vendor asks for more money without a change you requested. Each has a specific conversation to have, and the earlier it happens the cheaper the fix.
Founders often sense that something is off months before they can name it, and by then the fix is expensive. The signs below are visible from the outside, in the meetings and messages a founder already has. They are ordered from mild to serious. One mild sign is a question to ask. Several, or any of the serious ones, is a problem to act on this week.
The seven signs
1. Demos are postponed, or replaced by slides
What it looks like: the fortnightly demo slips, then slips again. When it happens, you see a presentation about progress rather than the product.
What it means: there is nothing working to show, or the team is behind and hiding it.
What to do: ask to see working software next week, whatever state it is in. A good team will show you rough work gladly. Resistance to that is the real signal.
2. The same feature is "nearly done" for weeks
What it looks like: status reports say 90 percent for three consecutive updates.
What it means: the hard part was underestimated, or a dependency is blocked, or the feature was never properly defined.
What to do: ask what specifically remains, in a list, and what is blocking each item. Vague answers to that question upgrade this to a serious sign.
3. The team changes without explanation
What it looks like: the lead developer you met is no longer in meetings. New names appear. Nobody mentioned it.
What it means: your project has been de-prioritised, or the vendor is having staffing problems, or someone left. Any of these costs you continuity.
What to do: ask directly who is on the project now, what their roles are, and how knowledge was handed over. Ask to meet the new lead.
4. Questions get vague answers
What it looks like: "It is complicated." "We are handling it." "Let us get back to you." Repeatedly.
What it means: either the team does not know, or they know and do not want to say.
What to do: ask the same question in writing and request a written answer. If you have a technical advisor, bring them to the next call. Clarity usually returns quickly when the questions are specific and recorded.
5. There is no bug list, or it never shrinks
What it looks like: you ask how many open issues there are and nobody can say, or the number only grows.
What it means: quality is not being managed. Problems are being found and not tracked, or tracked and not fixed.
What to do: ask for the list, weekly, with what was closed and what was opened. A team that has one will share it in minutes. A team that does not have one has a process problem that will surface at launch.
6. You cannot access the code or the accounts
What it looks like: you ask for access to the repository or the cloud account and it is delayed, deflected or refused.
What it means: this is serious regardless of intent. If the relationship ends tomorrow, you may have nothing.
What to do: require access this week, in writing, referring to the contract. If the contract does not give you ownership, get legal advice now, not at the end. Our post on who owns the code explains what you should have.
7. A request for more money without a change you asked for
What it looks like: the fixed price is no longer enough, for reasons that are not changes you requested.
What it means: the vendor underestimated and is trying to move the cost to you, or the scope was never fixed properly and is now being renegotiated.
What to do: ask for a written account of what changed against the agreed scope. If nothing you requested changed, the contract decides, and a professional vendor will honour it. If the scope was too vague to decide, that is a lesson for the next contract, and this one needs a negotiated settlement with a firm scope going forward. See why projects go over budget for the mechanisms.
How to tell a rough patch from a failing project
| Rough patch | Failing project |
|---|---|
| One sign, explained openly, with a plan | Several signs, or explanations that change |
| You heard about the problem from them first | You found it |
| Working software still appears, if late | Only presentations and promises appear |
| You have access to everything | Access is delayed or denied |
| The team is stable and named | The team is changing and anonymous |
What to do if it is failing
- Secure what you own. Code, accounts, design files, documentation. Get copies now.
- Get an independent assessment. A technical advisor or another agency reviewing the code and progress for a day. It costs little and tells you whether to recover or restart.
- Decide with the assessment, not with sunk cost. The money spent is gone whether you continue or not. The question is which path reaches a working product for the least additional cost.
- If you change vendors, do it at a milestone, with a written handover of code, documentation and open issues.
A note from the other side of the table
We are sometimes the second agency, brought in to assess or rescue a project that showed these signs. The most common finding is not incompetence but a scope that was never defined and a contract that never gave the founder ownership. Both are preventable at the start, which is why our process front-loads them. If your project is showing some of these signs, talk to us. An honest assessment is the first step whether or not we are the ones who continue it.
Frequently asked questions
How long should I wait before acting on a warning sign?
One mild sign deserves a question at the next meeting. If the answer is clear and the sign disappears, fine. If it recurs, or if a second sign appears, act within the week. The cost of a problem grows with every cycle it continues.
Is it normal for a project to be a few weeks late?
Some slippage is common and not alarming if you heard about it from the team with a reason and a new plan. Slippage you discovered yourself, or that keeps repeating, is a sign.
What if I do not understand the technical explanation for a delay?
Ask for it in plain terms and in writing. A competent team can explain any delay to a non-technical founder. If they cannot or will not, that is itself a sign.
Can I get a second opinion without offending my vendor?
Yes. Tell them you are bringing in a technical advisor, which is normal practice. A good vendor welcomes it. A defensive reaction tells you something.
Should I stop paying if I see these signs?
Not unilaterally, because it can put you in breach. Pay for milestones that were demonstrated. Withhold, in writing and with reasons, for milestones that were not. Get legal advice if the amounts are significant.