The first deliverable of a software rescue is not more code

When a software project falls behind schedule, many teams instinctively think adding more developers will expedite the process. However, this often proves counterproductive. Instead, Ivan Li, a technical lead and frontend engineer specializing in AI-powered video products, recommends a stabilization phase to turn the rescue into a testable component.

The initial step involves defining a clear release path. This path should be observable and concrete, such as a user signing in, uploading a supported video, running an AI action, previewing the result, and exporting a playable file. If the team cannot agree on this path, the root issue may be a lack of clarity in product scope, rather than a need to speed up implementation.

Next, a detailed evidence pack should be created rather than a blame document. This pack should include precise reproduction steps, expected and actual behavior, the smallest failing input (with sensitive data omitted), relevant logs and timestamps, the last known working version, build, test, and deploy instructions, environment differences, and any changes made just before the failure.

Screenshots should be avoided unless they provide contextual value. Sensitive information like production passwords, private keys, customer data, or unrestricted cloud credentials must be excluded from communications.

Before making any changes to the product, it is crucial to restore a known build and deployment path. The team should answer four key questions: Can a clean machine build it? Can the current test suite run? Can a non-production environment be deployed? Can that deployment be rolled back? If any of these answers are no, the team risks introducing new build or deployment incidents.

A one-page runbook, containing the commands, required runtime versions, configuration sources, health checks, and rollback steps, should be maintained. The goal isn't perfection but ensuring another team member can replicate the process.

It's also essential to distinguish between the symptom and the underlying constraint. For instance, an export button that "does nothing" might stem from various issues like frontend state transitions, rejected API requests, background job failures, expired media URLs, codec or platform mismatches, permissions problems, or missing observability. Formulating testable hypotheses can help clarify the root cause.

A go/no-go acceptance criterion must be defined before any implementation begins. For the example release path, acceptance might include the supported test asset completing the full path three times, a deliberately invalid asset producing a clear, recoverable error, a failed AI request being retryable without duplication, the exported file playing in the agreed environment, traceable job identifiers in logs, and tested deployment and rollback procedures by someone else.

For the initial paid milestone, a map of reality should be provided rather than a full fix promise. This could involve reproducing the blocker, mapping critical paths and dependencies, ranking top risks by delivery impact and reversibility, proposing narrow repair options, defining acceptance and exclusions, and only providing a fixed implementation quote if the evidence supports one. This milestone offers a testable decision document to the client, rather than a vague opinion.

In summary, when handling a delayed project, the first deliverable should not be more code. Instead, it should be a shared, testable map of reality. This approach clarifies the constraints, establishes a foundation for addressing issues, and sets clear expectations for all parties involved.