Article 06
From an AI-assisted build to production that can be operated
AI accelerates building, while real data, users, change and failures require infrastructure, security, deployment, monitoring, recovery and clear ownership.
Application
Production Readiness
Example situation
Start with the people using the system
The demo passed, but nobody owned launch-day support
The team built quickly with AI and every screen worked in the demo. At launch, multiple departments caused slowness, some records were incomplete and there was no dashboard or runbook. The missing part was not AI capability, but the operational layers that let software live safely in the real world.
Summary for business and everyday users
From an AI-assisted build to production that can be operated
Runnable proves the happy path; production must handle failure paths and change.
Readiness covers people, process, data, system and support.
Preparation should match system criticality; not every workload needs enterprise complexity.
Interactive explanation
See how the stages connect before reading the detail
Select a stage to understand what happens, what evidence to inspect and how one decision affects the next stage.
Step 01 / 04
01 / Choose the level
Experiments, business systems and critical systems need different controls
Ask who is affected by one hour of downtime, what data cannot be lost and whether a manual fallback exists. A small internal tool may use simple deployment and backup, while payment or customer systems need stronger monitoring, rollback, recovery objectives and support ownership.
Evidence to inspect
- Experiment: sample data and limited users
- Business MVP: real data and clear owner
- Business-critical: SLA, recovery and incident process
In-depth explanation
Work through each issue in real operating context
Each section connects business impact with what a Tech Lead needs to inspect, including examples, evidence and constraints.
01 / Choose the level
01Experiments, business systems and critical systems need different controls
Ask who is affected by one hour of downtime, what data cannot be lost and whether a manual fallback exists. A small internal tool may use simple deployment and backup, while payment or customer systems need stronger monitoring, rollback, recovery objectives and support ownership.
- Experiment: sample data and limited users
- Business MVP: real data and clear owner
- Business-critical: SLA, recovery and incident process
02 / Eight layers
02Production readiness is not infrastructure alone
A system is ready when requirements and ownership are clear, permissions protect data, environments are separated, deployment is repeatable, performance has a baseline, monitoring reveals symptoms, backups restore and support knows how to respond. Missing layers surface under real use.
- Product and ownership
- Security and data
- Infrastructure and environments
- Deployment and rollback
- Performance and capacity
- Monitoring and alerting
- Backup and recovery
- Support and incident management
03 / Go-live
03Launch day needs a plan, not only a deploy command
Define deployment window, go/no-go owner, post-deploy checks, user communication, rollback triggers and incident channels. During early use, watch metrics and feedback together because some issues do not appear in test data.
Go-live control
Define stop conditions before starting
For example, sustained threshold breaches, incomplete critical transactions or missing telemetry should stop rollout and trigger rollback rather than uncontrolled live fixing.
04 / After launch
04Users need to know what happened, who owns it and when the next update comes
Good support needs intake, severity, reproduction evidence, workaround communication and closure with root cause and prevention. It is more than acknowledging a ticket and should be designed with the system, not after an incident.
Runbooks should name dashboards, log queries, owners, escalation, safe actions and prohibited actions for each incident type.
Checklist before action
Classify criticality
Review roles and data
Separate environments
Prepare deploy and rollback
Define baseline and alerts
Test backup restore
Name support owner
Rehearse critical incidents
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Engineering & Operations
- Last reviewed
- 2026-07-17
Not sure where to start the review?
Use a preliminary tool or share the system context with SIS so the highest-priority work can be identified.