A backend can return the correct response in development and still be unsafe to operate. It may lose data during partial failure, become opaque during an incident, collapse under concurrency or require a deployment process nobody can reliably repeat.
Calling such a system “production-ready” because it has been deployed confuses location with quality. Production readiness is better treated as a diagnosis: a claim supported by evidence across several independent engineering concerns.
What PRODUCTION-7 measures
PRODUCTION-7 organises that diagnosis into seven dimensions: Architecture, Correctness, Testing, Security, Performance, Observability and Deployability. Each dimension asks a different question about trust. Together, they expose weaknesses that a single metric—coverage, latency, uptime or deployment frequency—cannot capture.
The framework scores every dimension from evidence found in code, tests, configuration and runtime behaviour. A score is not the objective; it is a compact record of what has been demonstrated, what remains uncertain and what work should happen next.
A system reaches the gate only when every dimension meets the minimum threshold. A strong average cannot compensate for a critical security, correctness or deployability weakness.
The seven dimensions
Architecture
Can the system change without unrelated parts changing with it?
Evidence to inspect. Look for explicit boundaries, controlled dependencies, isolated business rules and infrastructure kept behind replaceable interfaces.
Typical degraded state. Route handlers own business logic; modules import across every layer; changing storage forces changes throughout the application.
Correctness
Does the backend preserve its promises when operations fail, repeat or arrive concurrently?
Evidence to inspect. Inspect validation, transaction boundaries, invariants, error contracts, idempotency and the behaviour of partial operations.
Typical degraded state. A request commits before external work completes; retries duplicate records; invalid state can be stored because the database enforces no invariant.
Testing
Do tests provide evidence about production behaviour rather than reassurance about implementation details?
Evidence to inspect. Prioritise failure paths, integration boundaries, database behaviour, contract tests and deterministic test environments.
Typical degraded state. Tests mock every collaborator, exercise only successful paths and pass even when the real database or network contract has changed.
Security
Are trust boundaries explicit and enforced consistently?
Evidence to inspect. Review authentication, authorisation, secret handling, input limits, dependency risk, auditability and the least privilege granted to every component.
Typical degraded state. Authentication is mistaken for authorisation; secrets enter logs; a service account can access far more than its runtime responsibility requires.
Performance
Does the system remain responsive under realistic load and resource constraints?
Evidence to inspect. Measure query shape, connection usage, blocking work, timeouts, backpressure and the cost of external dependencies before optimising.
Typical degraded state. Async endpoints perform blocking I/O; unbounded queries grow with the dataset; downstream calls have no timeout and consume every worker.
Observability
Can engineers explain what happened without reproducing the incident locally?
Evidence to inspect. Require structured logs, meaningful metrics, traces across boundaries, correlation identifiers and alerts tied to user-visible failure.
Typical degraded state. Logs contain prose without context; errors disappear inside background work; dashboards report infrastructure health but not failed business operations.
Deployability
Can a release be configured, migrated, verified and reversed safely?
Evidence to inspect. Inspect reproducible builds, environment validation, migration strategy, health checks, rollout controls, rollback paths and operational ownership.
Typical degraded state. Deployment depends on manual steps; migrations cannot be reversed; the application reports healthy before its dependencies are ready.
How to use the framework
- Inspect before prescribing.Collect evidence from the running system, repository, delivery pipeline and operational practices.
- Record findings by dimension.Describe observable risks, not preferences. A finding should identify the condition, consequence and evidence.
- Prioritise by risk and dependency.Repair work that protects data, restores feedback or enables later improvements before cosmetic restructuring.
- Re-inspect the same evidence.A refactor is complete only when the original risk is demonstrably reduced and regression is controlled.
- Apply the production gate.Require the minimum in every dimension and record any accepted residual risk explicitly.
A checklist is the start, not the verdict
Checklists make hidden concerns visible and prevent routine controls from being forgotten. They do not replace engineering judgement. The same control can require very different evidence in a small internal service, a public API and a system that moves money or personal data.
The useful outcome is not a perfect score. It is a shared, reviewable explanation of why the system can be trusted, where it still cannot and which change will reduce the most meaningful risk next.
Assess your own Python backend.
Use the free 100-point production-readiness checklist across all seven dimensions.
Get the production checklist