{"slug": "the-first-deliverable-of-a-software-rescue-is-not-more-code", "title": "The first deliverable of a software rescue is not more code", "summary": "Ivan Li, a technical lead and frontend engineer specializing in AI-powered video products, advocates for a stabilization phase before writing more code in software rescues. He emphasizes defining a concrete release path, gathering minimal evidence, and creating a reproducible baseline to turn ambiguous projects into testable work. Li provides a structured brief for triaging delayed releases, focusing on observable steps and objective acceptance criteria.", "body_md": "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.\n\nBefore writing more code, I use a short stabilization phase to turn an ambiguous rescue into a testable piece of work.\n\n“The app needs to work” is not a release path.\n\nA release path is a concrete journey such as:\n\nAn invited user signs in, uploads one supported video, runs one AI action, previews the result, and exports a playable file.\n\nWrite the path as observable steps. If the team cannot agree on the path, the current blocker is product scope, not implementation speed.\n\nEverything outside this path goes into one of three buckets:\n\nThat last bucket matters. A rescue without exclusions quietly becomes a rewrite.\n\nThe minimum useful evidence pack contains:\n\nAvoid 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.\n\nDo 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.\n\nBefore changing the product, answer four questions:\n\nIf 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.\n\nFor 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.\n\nThe visible failure may not be the actual constraint.\n\nAn export button that “does nothing” could be caused by:\n\nCreate hypotheses that can be disproved. “The queue is broken” is weak. “Jobs created after version X stay in `pending`\n\nfor more than 60 seconds and no worker claims them” gives you something to test.\n\nA rescue should have an objective end. For the example release path, acceptance might be:\n\nNotice what is missing: “feels stable,” “looks better,” and “should be production ready.” Those phrases invite disagreement at the end of the project.\n\nWhen the system is unfamiliar or the problem is intermittent, promising a full fix before diagnosis is guesswork.\n\nA useful first milestone can be small:\n\nThis 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.\n\nIf you need to bring someone into a delayed project, send this before the first call:\n\n```\nCritical user journey:\nCurrent blocker:\nExact reproduction steps:\nExpected / actual result:\nEvidence and logs (secrets removed):\nLast known working version:\nBuild / test / deploy status:\nDeadline and reason:\nWhat may be cut:\nDecision owner:\n```\n\nThe 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.\n\nI’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](https://ivan-product-rescue.yingong0014.chatgpt.site) or email [ivan@zstun.com](mailto:ivan@zstun.com?subject=Product%20rescue%20diagnostic).", "url": "https://wpnews.pro/news/the-first-deliverable-of-a-software-rescue-is-not-more-code", "canonical_source": "https://dev.to/stevenleep/the-first-deliverable-of-a-software-rescue-is-not-more-code-556o", "published_at": "2026-08-26 16:36:55+00:00", "updated_at": "2026-08-26 17:16:02.903688+00:00", "lang": "en", "topics": ["developer-tools", "ai-products"], "entities": ["Ivan Li"], "alternates": {"html": "https://wpnews.pro/news/the-first-deliverable-of-a-software-rescue-is-not-more-code", "markdown": "https://wpnews.pro/news/the-first-deliverable-of-a-software-rescue-is-not-more-code.md", "text": "https://wpnews.pro/news/the-first-deliverable-of-a-software-rescue-is-not-more-code.txt", "jsonld": "https://wpnews.pro/news/the-first-deliverable-of-a-software-rescue-is-not-more-code.jsonld"}}