What ‘running in production’ actually means

A product is not in production merely because a public URL loads or an application passed store review. Deployment proves that software reached an environment. Production means the complete system can deliver its intended outcome under real operating conditions.

The difference becomes visible as soon as the first real user arrives with incomplete information, repeats an action, loses connectivity, needs support, or encounters a condition the demo never covered.

The customer surface is the visible edge

The web page, mobile application, or desktop interface matters, but it is only the visible boundary of the product.

Behind a reliable interaction are decisions about:

• identity and access;
• persistent data;
• authorization;
• external services;
• background work;
• notifications;
• administration;
• deployment and recovery.

If those parts are undefined, the interface can still look complete while the product remains impossible to operate responsibly.

Identity is not the same as authorization

Authentication answers who the person is. Authorization answers what that person may see and do under the current conditions.

Production authorization often depends on organization membership, ownership, subscription state, geography, approval status, or the history of a record. It also needs behavior for revoked access, changed roles, abandoned accounts, and support intervention.

These rules should be explicit, tested at system boundaries, and visible to the people responsible for operating the product.

Data needs a lifecycle

Prototype data is often treated as content that appears on a screen. Production data has a lifecycle:

1. It enters through a user, integration, import, or generated process.
2. It is validated and associated with an owner.
3. It changes while retaining the history that matters.
4. It may be exported, synchronized, corrected, or deleted.
5. It is recovered when software or people fail.

A product is not ready to operate when nobody can explain the source of truth, retention behavior, or consequence of a duplicate request.

External systems fail differently

Payments, email, maps, identity providers, AI models, and customer APIs create dependencies outside the product’s control.

Production implementation needs to decide:

• how long to wait;
• when to retry;
• how to prevent duplicate effects;
• which failures are visible to the user;
• which failures need operator intervention;
• how to reconcile conflicting records later.

“Call the API” is a prototype requirement. “Recover safely when the API times out after creating the record” is a production requirement.

Administration is part of the product

Someone must be able to answer questions and repair routine problems without editing the database directly.

The required operating surface varies, but it often includes:

• account and organization lookup;
• status and history inspection;
• safe corrections;
• refunds or entitlement changes;
• integration and background-job state;
• audit history;
• support notes and escalation context.

Administration is not automatically a large dashboard. It is the minimum safe interface through which the product can be operated.

Deployment includes a return path

A reliable release process does more than move code forward. It preserves the ability to understand and recover from what changed.

That normally requires:

• reproducible environments;
• controlled configuration and secrets;
• database migration discipline;
• health checks;
• staged or reversible releases where appropriate;
• logs and signals tied to the release;
• a clear person responsible for the decision to continue or roll back.

At Lane Technologies, mobile release infrastructure became part of the company’s durable technical evidence during acquisition due diligence. Release work had business value because it made product delivery more reliable and inspectable.

Production has an owner

Every live product needs an answer to these questions:

• Who notices when it stops delivering the outcome?
• Who can determine what changed?
• Who communicates with affected users?
• Who has the authority to repair or reverse it?
• Who decides what the product should do next?

Monitoring without responsibility only creates unattended alerts. Documentation without an owner becomes a historical artifact.

A practical production test

Before calling a product live, walk through one complete customer outcome and ask:

1. Can the right person enter and complete it?
2. Can the wrong person be prevented from doing so?
3. Does the data remain correct if the request repeats or fails halfway?
4. Can an operator understand the state without privileged engineering access?
5. Can the team detect and recover from a bad release?
6. Is responsibility clear when the system behaves unexpectedly?

A production product does not need every future capability. It needs a complete enough operating loop that real use creates evidence instead of preventable confusion.