Article 09
AI can build a runnable system, but what must happen before production?
Understand the gap between a prototype, a demo and production across security, load, infrastructure, deployment, backup and operational support.
From a working screen
Start with the people using the system
Runnable does not yet mean dependable for the business
AI can quickly create screens, APIs and database connections, so a working developer demo may feel close to launch. Real users, hostile traffic, network failures and human mistakes change the problem. Production readiness is the combined ability of the system and its operators to protect data, absorb demand, recover and communicate.
Terms before you begin
Technical language, explained by what each part does
You do not need to memorize every term. Use this section as a map while reading the detailed explanation.
- Prototype / Demo
- An experimental system used to prove an idea or primary flow, often with sample data and limited failure handling.
- Production
- The live environment serving real users and data, where failures affect operations, revenue or trust.
- Scalability
- The ability to add resources or change system shape as demand grows while preserving service quality.
- Load Balancer
- A traffic entry point that distributes requests across application instances.
- Rate Limit
- A rule limiting requests per identity or time window to control abuse and overload.
- Observability
- Metrics, logs and traces designed to explain system behavior, user impact and bottlenecks.
- Rollback
- A controlled return to a safe release when a deployment fails, including database compatibility.
- Secret
- Sensitive machine credentials such as API keys, passwords and private keys that must not be embedded in source code.
Summary for business and everyday users
AI can build a runnable system, but what must happen before production?
A prototype proves an idea; production must prove security, resilience and operability.
Size infrastructure from concurrency, request rate, workload and peaks, not total users alone.
Design security, backup, monitoring, rollback and incident response before launch.
AI accelerates delivery, but accountable engineers still validate architecture, dependencies, secrets and access.
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 / 06
01 / Frame the problem
A demo tests the expected path; production must survive unexpected paths
A demo usually uses a few accounts, clean data and expected steps. Production receives malformed files, duplicate actions, interrupted networks, mixed permissions and automated traffic. Test normal, failure and hostile paths, and define how the system behaves when a dependency is unavailable.
Evidence to inspect
- Malformed input must not crash the service
- Retries must not create duplicate records
- Authorization is checked on every request
- External failures need timeouts and a fallback
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 / Frame the problem
01A demo tests the expected path; production must survive unexpected paths
A demo usually uses a few accounts, clean data and expected steps. Production receives malformed files, duplicate actions, interrupted networks, mixed permissions and automated traffic. Test normal, failure and hostile paths, and define how the system behaves when a dependency is unavailable.
- Malformed input must not crash the service
- Retries must not create duplicate records
- Authorization is checked on every request
- External failures need timeouts and a fallback
02 / Understand demand
02One hundred thousand users do not imply the same server size for every system
Infrastructure handles concurrent activity and work per user, not the registration count. A news reader and video upload service consume very different CPU, memory, network and storage. Build a load model from concurrency, request rate, payload, database work, background jobs and peaks, then test against response-time, error and saturation thresholds.
Start with baseline, then load, stress and soak tests. Inspect p95/p99 by endpoint rather than averages alone.
03 / Secure before launch
03Security is not a plugin added after the system is complete
Identify data, allowed actors, impact and internet entry points before selecting controls. Then design authentication, authorization, encryption, secret management, network boundaries, audit logs and patching. AI-assisted code needs explicit review for obsolete packages, embedded keys, debug settings and endpoints missing authorization.
- Require MFA for administrators
- Use a secret manager
- Apply least privilege
- Scan dependencies and images
- Keep audit logs without passwords or tokens
04 / Build the platform
04Good infrastructure makes scaling, deployment and recovery repeatable
Layer the platform: DNS and TLS at the edge, CDN/WAF for filtering and offload, a load balancer, scalable application instances, private and backed-up databases, object storage, and queues for slow work. Build environments with infrastructure as code and make deployments include health checks, migrations and rehearsed rollback.
05 / Operate and recover
05During failure, ownership, impact and the next update must be clear
Monitoring should reflect user experience instead of alerting on every resource fluctuation. Define service objectives, alert owners, runbooks, severity and communication. Test restores, and use incident reviews to fix both causes and delayed detection without turning the review into blame.
06 / Decide before go-live
06Launch when residual risks have owners and responses, not when a checklist merely looks green
No live system is perfect. Readiness records tested evidence, accepted residual risk, approvers and stop conditions. SIS can help review architecture, security, load, delivery, monitoring and support in proportion to business impact; planning before go-live preserves more options and costs less than repairing during an incident.
Checklist before action
Separate prototype, UAT and production
Classify data and model threats
Build a load model and thresholds
Review auth on every endpoint
Keep secrets out of source
Define backup, RPO and RTO
Test deployment and rollback
Assign monitoring and runbooks
Rehearse incident communication
Record accepted risk before go-live
References
Figures and examples create a discussion framework. Validate them against the real system and its constraints before deciding.
- Reviewed by
- SIS Infrastructure & Security
- 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.