Stuck products
Five tells your software project is dead, and what to do at each stage
Non-technical founders rarely get a clean signal that their build has gone off the rails. By the time it is obvious, the runway is mostly gone. Here is how to read the warning signs earlier.
A non-technical founder rarely gets a clean signal that the build has gone off the rails. By the time things look obviously bad, the runway is mostly gone, the team is checked out, and the original product vision is buried under months of patches. The signals were there earlier. They just looked like ordinary friction.
Below are five tells, ranked by how late in the decay curve they tend to show up. The earlier you catch them, the cheaper the recovery.
1. The status updates stop containing verbs
Healthy projects produce status updates with actions in them. We shipped X. We fixed Y. We started Z. Compromised projects produce updates that look busy without being specific. "Working on the dashboard." "Investigating the bug." "Looking into the integration." When the verbs get vague, momentum has already stalled.
What to do at this stage: ask for a one-week deliverable in writing. Not a goal, an artifact. A working endpoint, a deployed staging build, a passing test. If the answer is "we will know more next week," you are now at stage 2.
2. The deadline keeps moving by one week
Every Friday it is the same one-week extension. There is always a real reason. The cumulative effect, over six weeks, is six weeks of slip but only one week of accountability per cycle. Non-technical founders accept this because each individual extension sounds reasonable.
What to do at this stage: ask the project lead to publish their best estimate at three confidence levels (50%, 80%, 95%). Get it in writing. The exercise alone reveals whether the team has a plan or is improvising. If they cannot produce the estimate, the project is already late by more than you think.
3. The team is rewriting code they wrote last quarter
If your developers are spending more time rewriting their own prior work than building new features, the architecture has rotted. This is rarely talked about because it does not feel like failure to the people doing it. They are solving real problems. The problem is the problems are self-inflicted.
What to do at this stage: ask for a feature-vs-rework breakdown of the last two sprints. New work, debugging existing work, rewriting prior work. Healthy ratio is 60/30/10. A team at 30/40/30 is in trouble.
4. The codebase has one person who can deploy it
When only one person knows how to ship a release, the project belongs to that person. You will not feel this until they take a vacation, get sick, or quit. Then you find out the deploy script is undocumented, the env vars are in a personal notebook, and the production database has a manual cron job nobody else can find.
What to do at this stage: ask anyone besides the lead to do a deploy. Watch them try. The friction you see is a leading indicator of every future incident. The fix is a documented runbook and a deployment that any team member can execute. If the lead resists writing one, the project belongs to them in a way that no longer serves you.
5. The lead developer goes silent on Slack
The clearest signal, and usually the last one. The developer who used to post daily updates is suddenly offline for two days, then four, then a week. They reply with one-line "got it" messages. They miss standups. Eventually they stop responding entirely.
What to do at this stage: this is the takeover moment. The project will not recover without a change in operator. The longer you wait, the more expensive the recovery, because each week of silence is a week of code rot, missing knowledge, and stalled customer commitments. Your priorities now are: get the credentials and source code in your name, get a written project status from whoever is still responsive, and call someone who runs takeovers for a living.
The pattern across all five tells is the same. Software projects do not die in a fire. They die in slow motion, with plausible excuses at every stage. The founders who survive are the ones who notice the gap between language and action one cycle sooner than their peers do.
If you are reading this with a knot in your stomach because two or three of these match what you are seeing right now, that is not a coincidence. You are likely at the start of a recoverable situation that gets harder to recover from every week. The next move is reading what your team produces this week with fresh eyes, holding it up against what you were told four weeks ago, and being honest about the trend line.
If this helped
You can put this thinking to work directly. Run the diagnostic on a stuck product, or book a 30-minute call to talk through your situation.