From research prototype to reliable software

Define the user-visible outcome

Describe the task a user needs to complete and what successful completion looks like from outside the service. A process being alive is a useful signal, but it does not prove that a user can obtain the intended result.

Build an acceptance check that follows the actual application path. Include the integrations that make the feature useful. Record its inputs and limits so that someone other than the author can repeat it.

Observe both behaviour and resource pressure

The Google SRE monitoring chapter discusses latency, traffic, errors and saturation as four useful signals. For a research service, connect those signals to the user task: a successful HTTP response can still contain an unusable result.

Keep failures distinguishable. A missing source, an unavailable dependency and a rejected request should not collapse into a generic success indicator. An operator needs enough context to decide whether to retry, investigate or stop an operation.

Make the release reproducible

A runnable release needs a known source revision, declared dependencies and documented configuration keys. Secrets belong in the deployment secret mechanism. A clean rebuild should not depend on an unrecorded file in a developer directory.

Preserve the association between a release and its acceptance evidence. When behaviour changes, this makes it possible to determine which version was checked and whether a newer version has passed the same path.

• Record the source revision and dependency lockfile.
• Document configuration names without secret values.
• Verify readiness through a real user-facing operation.
• Retain the previous working release and its checks.

Test recovery as a separate capability

A backup file does not establish that the application can be recovered. Restore into an isolated environment and check the resulting service, its data consistency and the integrations needed for operation.

Agree on the acceptable loss of recent changes and the acceptable interruption with the responsible business owner. Measure the recovery attempt against those requirements. A successful test describes what was recovered and what was deliberately outside the test.

Keep the readiness decision explicit

The review should state which user paths passed, which conditions remain unsupported and who owns unresolved items. A visible limitation is more useful than an optimistic readiness label without supporting evidence.

Start expansion from observed behaviour. Investigate failures before adding more users or integrations. This is a general review framework, not a claim that a specific deployment or customer system has passed these checks.