Five Questions to Ask Before Going Live

The technical evidence worth examining before a working application becomes something people and businesses depend on.

A working application can create a convincing sense of progress.

The main workflows behave as expected. Users can log in, enter information, complete transactions, and see the results. Perhaps the application has already been deployed and a few people are using it.

At that point, the natural question is whether it is ready for production.

But I think there is a more useful place to start.

What is this application about to become responsible for?

Consider two applications built from essentially the same codebase.

One is about to be tested by ten early adopters using limited data. If something fails, the team can intervene, correct the problem, and continue learning.

The other is about to become part of a company's daily operations, process payments, or exchange information with a financial institution.

The technical implementation might be nearly identical.

The consequences of failure are not.

That distinction should determine how much evidence we need before proceeding.

At Soluntech, we've been developing this thinking into our Production Readiness Assessment. Rather than assigning software a universal readiness score, the assessment considers the responsibility an application is about to assume and the evidence available to support it.

Five technical questions are particularly useful for understanding the difference.

1. If something breaks, will you know before your users tell you?

Most developers can find an error in a log.

That doesn't necessarily mean they will know when something goes wrong.

Imagine an application that processes customer orders. A third-party service stops responding, and some orders fail to complete.

The application remains online. Customers can still log in. The dashboard loads normally.

But orders are being lost.

If the company discovers the problem only when a customer complains, the issue is no longer simply whether the software works. It is whether the business can recognize when an important part of its operation has stopped working.

There are several levels of evidence worth distinguishing.

• Basic logging: Someone can investigate after discovering a problem.
• Monitoring and alerting: The system can identify important failures without waiting for a user report.
• Diagnostic visibility: The team can trace what happened, identify the affected transactions, and understand the cause.

These capabilities are related, but they are not interchangeable.

Google's Site Reliability Engineering guidance includes monitoring, alerting, dependency failures, and operational visibility among its launch considerations. The underlying principle is practical: operating software requires knowing what is happening when nobody is watching the screen.

For a small experiment, discovering an issue through user feedback may be acceptable.

For software handling transactions or critical workflows, discovering failures late can multiply their consequences.

The question isn't whether every error produces an alert.

It is whether the failures that matter to the business can be detected and investigated in time.

2. If important data disappears, can you demonstrate that it can be recovered?

Teams sometimes treat the existence of backups as evidence that their data is protected.

But a backup is not the same thing as a demonstrated recovery capability.

Imagine a company that has been storing operational records for six months. Its database is backed up automatically every night.

Then a deployment introduces a problem that corrupts part of the data.

The team knows backups exist.

What it doesn't know is whether those backups can be restored successfully, how long restoration will take, or how much recent information might be lost.

Those questions suddenly become business questions.

How long can operations remain interrupted?

How much data can the organization afford to reconstruct?

Who is responsible for executing the recovery?

And has anyone actually tried?

A useful distinction is between three forms of evidence:

• Backups exist: Data is being copied somewhere.
• A restoration has succeeded: The team has demonstrated that backup data can be recovered.
• A recovery process has been tested: The organization understands the procedure, responsibilities, and practical recovery limits.

NIST's contingency planning guidance emphasizes recovery strategies, procedures, and testing rather than relying exclusively on preventive measures.

This doesn't mean every application needs elaborate disaster recovery infrastructure.

A prototype with disposable test data may not need any of it.

But when real business records become difficult or expensive to reconstruct, recovery can no longer remain an assumption.

The important question is not whether the system creates backups. It is whether the business can recover what it depends on.

3. What happens when a payment or integration fails halfway through?

Successful integrations can be deceptive.

During development, a payment request succeeds, an external API returns the expected response, and the application updates its database.

Everything appears correct.

But distributed systems rarely fail in convenient ways.

Consider a customer making a payment.

The payment provider processes the transaction, but the connection fails before the application receives confirmation.

The customer sees an error.

They try again.

Did the first payment succeed? Could the second attempt create a duplicate charge? Does the application know which transaction belongs to which order?

A similar problem occurs when software sends information to an external system, receives no response, and cannot determine whether the receiving system processed the request.

These situations require more than catching an exception and displaying an error message.

Depending on the transaction, the system may need:

• Timeout handling: Recognizing when an external service has stopped responding.
• Safe retries: Repeating an operation without unintentionally performing it twice.
• Idempotency: Ensuring that repeated requests do not create duplicate business effects.
• Reconciliation: Identifying discrepancies between systems and resolving them.
• Failure testing: Deliberately reproducing interrupted or incomplete transactions to understand what actually happens.

Google SRE's launch guidance considers dependency failures, timeouts, retries, and error-handling behavior.

For a prototype that only demonstrates an integration, not every failure scenario needs to be solved immediately.

But before real money or important operational data begins moving between systems, the acceptable level of uncertainty changes.

An integration working once demonstrates connectivity.

It does not demonstrate that the business can handle an incomplete transaction.

4. Can you release a change without putting everything that already works at risk?

Getting the first version of an application working is one challenge.

Changing it safely while people depend on it is another.

Imagine an application that has been operating reliably for several weeks.

A developer makes a small modification to improve a customer workflow. The change works in their local environment, so they deploy it.

Unfortunately, it also changes behavior in another part of the application.

The original feature works.

A different business process is now broken.

The issue is not necessarily poor development. Changes introduce uncertainty, even when the people making them are experienced.

What matters is how that uncertainty is managed.

There are several useful questions to ask.

• Are important workflows tested after changes?
• Can tests be repeated consistently?
• Does someone review changes before they reach users?
• Can a release be introduced gradually?
• If a problem appears, can the team restore the previous working version without creating additional damage?

These practices provide different kinds of protection.

Automated tests can catch regressions. Code review can identify assumptions that the original developer missed. Controlled releases can limit how many users experience a problem. Rollback procedures can reduce the duration of an incident.

None of these guarantees that a release will be flawless.

Together, they provide evidence that change is being managed rather than merely executed.

For a small experiment, manual checks may be proportionate.

For software supporting an important business operation, the ability to release changes safely becomes part of the system's reliability.

Production readiness is not only about whether today's version works. It is also about whether tomorrow's version can be introduced responsibly.

5. Could someone else maintain the application if its original developer became unavailable?

This question is often overlooked because it has little to do with whether the application works today.

A founder builds an application. They understand its structure, its integrations, and the decisions behind it.

Or perhaps a single developer builds an internal system that gradually becomes essential to the company.

As long as that person remains available, the arrangement appears to work.

Then the person leaves, becomes unavailable, or simply needs help maintaining the system.

Suddenly, the company discovers that having the source code is not the same as being able to maintain the software.

A repository may exist, but nobody understands the deployment process.

Documentation may describe the architecture, but not the reasons behind important decisions.

Credentials, infrastructure configurations, and operational knowledge may be concentrated in one person.

And even when the code is readable, understanding how the system behaves under real conditions can take time.

The evidence worth looking for is practical.

• Can another developer set up the application?
• Can they understand its critical dependencies?
• Can they make a change and release it safely?
• Can they investigate a production problem without relying on the original author?

There is a meaningful difference between believing that someone else could take over and having demonstrated that someone else already can.

This is especially relevant as AI-assisted development makes it easier for individuals and small teams to build substantial applications.

But it is not a problem exclusive to AI-generated code. Traditional software projects have depended excessively on individual developers for decades.

For a short-lived experiment, that dependency may be perfectly reasonable.

For a system becoming essential to daily operations, it becomes a business continuity risk.

The objective is not to eliminate individual expertise.

It is to ensure that the organization can continue operating and evolving the software when responsibility extends beyond the person who built it.

What stronger evidence actually looks like

Across these five areas, there is an important distinction between having a technical capability and having demonstrated that the capability can be relied upon.

Area	Basic evidence	Stronger evidence
Failure detection	Errors can be investigated through logs.	Important failures trigger alerts and can be traced to their cause.
Recovery	Backups exist.	Restoration has been successfully tested.
Payments and integrations	Successful transactions have been tested.	Failure scenarios, retries, and recovery have been deliberately tested.
Change safety	Changes are checked manually.	Repeatable tests, reviews, and controlled releases limit risk.
Continuity	The original developer can maintain the system.	Another person has successfully maintained or extended it.

Stronger evidence is not automatically necessary for every application. Its importance depends on the consequences of failure and the responsibility the system is expected to assume.

Technical evidence is only half of the decision

These five questions examine important operational capabilities.

But even strong answers do not automatically mean an application should be deployed.

Before deciding, we still need to understand the business context.

• Who will depend on the application?
• What real information will it handle?
• What would a realistic failure cost?
• Will customers, regulators, or contractual commitments impose additional requirements?

Consider a system preparing to serve a financial institution.

It might have automated testing, monitoring, demonstrated recovery procedures, controlled releases, and documented ownership.

Those are encouraging signs.

But the institution may also require security reviews, specific access controls, contractual assurances, or formal approval.

Internal technical confidence cannot substitute for those obligations.

Security also deserves a deeper assessment than a short operational questionnaire can provide. The OWASP Application Security Verification Standard, for example, provides detailed requirements for evaluating application security controls.

A production readiness discussion can reveal where further verification is needed. It cannot replace that verification.

This distinction matters because a self-assessment should not create confidence that the available evidence cannot justify.

Not every gap should delay every step

There is another mistake worth avoiding.

Once teams recognize these risks, they sometimes attempt to solve all of them before allowing anyone to use the application.

That can be just as damaging as launching without sufficient evidence.

Imagine a founder preparing a controlled experiment with ten early users.

The application uses limited data, has no payment processing, and can tolerate interruptions.

It may be reasonable to proceed with manual testing, simple operational procedures, and direct founder involvement.

Now imagine the same founder wants to introduce payments and make the application available to hundreds of customers.

The next step changes what needs to be demonstrated.

The following examples illustrate how the same technical condition can carry different implications.

The same weakness, different responsibility

Technical condition	Controlled experiment	Business-critical operation
Failures discovered through user reports	May be manageable.	Could allow costly failures to go unnoticed.
Backups never restored	May be acceptable with disposable data.	Can expose important business records to loss.
Manual release checks	May be proportionate.	May create unacceptable regression risk.
One-person dependency	May be practical initially.	Can threaten operational continuity.

These comparisons are illustrative. Actual decisions depend on the system's data, dependencies, failure consequences, and applicable obligations.

Some improvements can happen while the business continues learning.

Others should be completed before increasing exposure.

The goal is to distinguish among three situations:

• What is sufficiently supported today. The available evidence is proportionate to the next planned use.
• What needs further verification. There may be a capability in place, but it has not been demonstrated well enough to justify relying on it.
• What needs to be addressed before proceeding. A known weakness creates a material risk for the responsibility the system is about to assume.

There is also an important fourth situation: we don't know yet.

An unanswered technical question is not proof that the application is defective.

It is an uncertainty.

And sometimes resolving that uncertainty is the most valuable next investment.

The decision is what matters

A production review should not end with a long document that identifies everything an engineering team could improve.

It should help the people responsible for the software make a decision.

What can proceed now?

What needs to be verified?

What should be corrected before increasing responsibility?

And what would be unnecessary engineering at the current stage?

Those questions are relevant whether an application was built by an experienced development team, a founder using Claude Code, a no-code platform, or a combination of approaches.

The development method may influence what needs to be examined.

It should not determine the verdict.

At Soluntech, this is the principle behind how we think about production readiness: the evidence required should be proportionate to the responsibility the software is about to assume.

A system does not need to be engineered for every possible future.

It needs to be understood well enough to support the next responsibility the business is prepared to give it.

And as that responsibility grows, the evidence should grow with it.