When a software project is late, “add another developer” sounds like the fastest answer. Sometimes it is. Often it makes the project later because the new person inherits the same uncertainty plus a communication cost.
Before writing more code, I use a short stabilization phase to turn an ambiguous rescue into a testable piece of work.
“The app needs to work” is not a release path.
A release path is a concrete journey such as:
An invited user signs in, uploads one supported video, runs one AI action, previews the result, and exports a playable file.
Write the path as observable steps. If the team cannot agree on the path, the current blocker is product scope, not implementation speed.
Everything outside this path goes into one of three buckets:
That last bucket matters. A rescue without exclusions quietly becomes a rewrite.
The minimum useful evidence pack contains:
Avoid screenshots without context and messages like “it randomly fails.” A screenshot can prove that a symptom happened. It usually cannot explain the state that produced it.
Do not send production passwords, private keys, customer data, or unrestricted cloud credentials in chat. Create temporary, least-privilege access and revoke it after the engagement.
Before changing the product, answer four questions:
If the answer is no, fixing a product bug may create a build or deployment incident instead. The team needs a reproducible baseline before it needs more changes.
For small teams, a one-page runbook is enough. Record the commands, required runtime versions, configuration source, health check, and rollback step. The goal is not perfect documentation. The goal is for a second person to repeat the path.
The visible failure may not be the actual constraint.
An export button that “does nothing” could be caused by:
Create hypotheses that can be disproved. “The queue is broken” is weak. “Jobs created after version X stay in pending
for more than 60 seconds and no worker claims them” gives you something to test.
A rescue should have an objective end. For the example release path, acceptance might be:
Notice what is missing: “feels stable,” “looks better,” and “should be production ready.” Those phrases invite disagreement at the end of the project.
When the system is unfamiliar or the problem is intermittent, promising a full fix before diagnosis is guesswork.
A useful first milestone can be small:
This milestone has value even if the original implementation estimate turns out to be wrong. The client receives a testable decision document instead of another vague opinion.
If you need to bring someone into a delayed project, send this before the first call:
Critical user journey:
Current blocker:
Exact reproduction steps:
Expected / actual result:
Evidence and logs (secrets removed):
Last known working version:
Build / test / deploy status:
Deadline and reason:
What may be cut:
Decision owner:
The first deliverable of a rescue is not more code. It is a shared, testable map of reality. Once that map exists, you can decide whether the constraint is code, infrastructure, product scope, ownership, or missing information.
I’m Ivan Li, a technical lead and frontend engineer working around AI-powered video products. I publish practical notes about product rescue, AI workflows, and small-team operations. If you are triaging a delayed release, you can use the brief above for free. For a fixed-scope diagnostic or 5–7 day rescue sprint, see https://ivan-product-rescue.yingong0014.chatgpt.site or email ivan@zstun.com.