"Production-grade" appears in the marketing of almost every software agency and developer. It is used the way words like "artisan" and "premium" are used in consumer products — as a signal of quality without a specific, verifiable definition attached to it.
Since I use the term myself, I think it is worth being precise about what I mean by it.
It Starts With Error Handling
The first indicator of whether software is production-grade is how it handles things going wrong. Not just the obvious failure cases, but the subtle ones: the third-party API that returns an unexpected status code, the database query that times out under load, the webhook that fires twice, the user who submits a form with an emoji in the postcode field.
Code that handles only the happy path is not production-grade. Production systems fail gracefully. They log what went wrong in enough detail to diagnose it. They do not expose internal error messages to end users. They recover where recovery is possible and alert where it is not.
Security Is Not a Feature
I regularly see projects where security has been treated as a feature to be added after the core functionality is built. This is architecturally backwards. Security decisions made during the design phase — authentication model, session handling, input validation strategy, rate limiting, CSRF protection — are structural. They cannot be bolted on cleanly afterwards.
Production-grade software has:
- SQL queries parameterised at the level of the data access layer, not sanitised at the input level
- Session cookies with appropriate flags (HttpOnly, Secure, SameSite)
- Rate limiting on all public endpoints that can be abused
- Secrets stored in environment variables, not in code or configuration files committed to source control
- HTTPS enforced at the infrastructure level, not just linked from the application
- Dependency versions pinned and regularly updated
Documentation as a First-Class Deliverable
Software that cannot be understood, maintained, or extended by a competent developer other than its original author is a liability, not an asset. Documentation — schema diagrams, API references, deployment runbooks, environment setup guides — is part of what you are buying, not an optional extra.
Undocumented code is not production-grade. It is a dependency on the person who wrote it.
Performance Under Realistic Load
A system that works when ten people use it is not necessarily production-grade. Production-grade means the system has been considered under the load conditions it will actually face — and that its performance degrades gracefully (not catastrophically) if that load is exceeded.
This does not mean every system needs to handle a million concurrent users. It means the system's capacity is understood, documented, and appropriate to the context. A booking platform for a local business and a payment processing API for a fintech company have different load requirements — but both need to be engineered to meet theirs reliably.
Monitoring and Observability
A system you cannot observe is a system you cannot maintain. Production-grade software has structured logging, error tracking, and — where appropriate — uptime monitoring and alerting. When something goes wrong at 2am, you know about it before your users tell you.
The Summary
Production-grade software is software that:
- Handles failures gracefully and logs them usefully
- Was designed with security as a structural concern, not an afterthought
- Is documented well enough for a competent developer to understand and extend
- Has been considered under realistic load conditions
- Can be observed in production
When a supplier says their work is "production-grade," these are reasonable things to ask them to demonstrate.