Most software projects that feel "stuck" aren't stuck because the code is broken — they're stuck because nobody has clear authority to make the next decision, the scope quietly grew past what was ever agreed, or the team lost the context to move confidently. The code usually gets blamed anyway, because "the code is bad" is a simpler story than "we never nailed down who decides."
The four things that actually stall a project
None of these show up in a code review. All four show up in how long a project has been "almost done."
1. Ownership gaps
Nobody is actually empowered to say "this is done, ship it." Decisions get passed between a founder, a contractor, and a stakeholder, and each one assumes someone else is driving. Work continues, but nothing converges, because convergence requires someone willing to make a final call.
2. Scope that never stopped growing
The original plan was reasonable. Six months later, it's accumulated a dozen "while we're in there" additions that never got re-scoped against the timeline or budget. The project isn't behind — the finish line moved, quietly, without anyone updating the map.
3. Decision paralysis around technical debt
Someone notices a real architectural problem, raises it, and then nothing happens because fixing it competes with shipping new features and nobody wants to be the one who "stops progress" to deal with it. The debt doesn't get resolved or accepted — it just sits, unaddressed, quietly slowing everything built on top of it.
4. Team or vendor turnover that took the context with it
The person who understood why a decision was made leaves, and the decision becomes unquestionable folklore — nobody left can explain it, so nobody touches it. Every new person has to rebuild that understanding from scratch, which is slow, so progress quietly stalls while everyone gets oriented.
Why "the code is bad" is the easier story
Blaming the codebase is simpler than naming an ownership gap or admitting scope drifted, because it points at something other than a decision anyone made. It's also frequently wrong, or at least incomplete — a codebase can be entirely reasonable and a project can still stall for months on factors that have nothing to do with its architecture.
That distinction matters practically: fixing the code doesn't fix an ownership gap, and rebuilding from scratch doesn't fix a scope that was never controlled in the first place. Diagnosing the actual cause matters more than reaching for the familiar technical explanation.
What we've actually seen this look like
Fast Track USA is the clearest public example of a long stall followed by a fast resolution: roughly two years without a reliable launch, then three weeks to ship after a takeover. We're deliberately not claiming to know the specific cause of that two-year delay — the case study is honest about what's verified and what isn't, and the technical specifics of the previous engagement aren't part of the public record. What we can say plainly is the general pattern: a long stall doesn't automatically mean the underlying work was unsalvageable. Sometimes what changes between "stuck for two years" and "shipped in three weeks" is ownership and momentum, not a rewrite.
A short check before assuming it's a technical problem
- Is there one person who can say "this is done" and make it stick? If not, that's the first thing to fix — before touching any code.
- Does the current scope match what was actually agreed, or has it quietly grown? Write down what's actually left, not what feels left.
- Is there a known technical problem that's been raised but never resolved or explicitly deprioritized? Name it out loud and make an actual decision either way.
- Does anyone currently on the project understand why the important decisions were made? If not, that's a documentation and handoff gap, not necessarily a code quality one.
If the answers point to ownership, scope, or context rather than the architecture itself, the fix is process, not a rebuild. If a real technical audit turns up genuine structural problems on top of that, the rescue-or-rebuild framework is the next place to look — or run the four-question tool directly against your situation.