What Production-Grade Actually Means

A demo works once, on a laptop, with three rows of clean data, while the person who built it is watching. Production is the opposite of every part of that sentence. It runs unattended, on data you did not choose, at hours nobody is awake, for users who will do things the builder never imagined.

Production-grade is not a compliment about code quality. It is a specific claim: the software runs without supervision, and when it fails, the failure is visible, bounded, and recoverable. Most of what follows is just what that claim requires.

Errors are handled, not merely caught

Catching an error and showing a generic failure message is not error handling. It is error hiding. Handling means deciding, for each way an operation can fail, what the system does next and what the user is told.

The questions are concrete. If the payment provider times out, does the order exist or not? If the upload fails halfway, is there a partial file sitting somewhere? If an email send fails, does the user see success? If a background job dies at step four of six, does re-running it duplicate the first three steps or skip them? A system that cannot answer these will eventually produce a state that no one can explain, and inexplicable states are what destroy trust in software.

Two properties matter most. Operations that touch money or records should be safe to retry without doubling anything. And when something does go wrong, the user should get a message that tells them whether to try again, wait, or call someone.

Real data volumes and real data shapes

Almost everything works with ten records. The behavior that matters shows up at the volume the business will actually reach, and it usually shows up as a query with no index behind it, a page that loads every row to count them, or an export that holds an entire table in memory.

Shape is the other half, and it causes more incidents than volume. Real data has names with apostrophes, addresses without a state, phone numbers with extensions, a customer with two thousand invoices and another with none, timestamps from another time zone, and a record created before a field existed. Before we call anything production-grade, it gets tested against data that looks like the business, not data invented to make the screen look good.

Permissions are part of the feature, not a layer on top

The most common serious defect we see in inherited systems is not a crash. It is a page that shows one user another user's information, usually because access was enforced in the interface and not at the point where data is fetched.

Hiding a button is not permission. If a user can change a number in a URL, or call the API directly, and get back a record they should not see, the system has no access control regardless of what the screens look like. Permission belongs in the query. The rule to hold is simple: every request should be answerable on its own, with no assumption that the user got there through the approved screen.

This applies to internal tools too. Staff accounts get compromised, people leave, and roles change. An admin tool where every user can do everything is a single mistake away from a bad afternoon.

You can tell what it is doing

Unattended software needs to be observable, which means three separate things.

• Errors are recorded somewhere a human looks. Exceptions should land in a tool that groups them, counts them, and keeps the context needed to reproduce the problem. A log file nobody reads is not error tracking.
• Alerts route to a person with a way to act. An alert that goes to a shared inbox is decoration. It needs to reach someone who can respond, and it needs a threshold, because an alarm that fires constantly is one everybody learns to ignore.
• There is a record of what happened. For anything touching money, permissions, or customer records, you want to be able to answer who changed what and when. This is not only for security. It is how you reconstruct a bad Tuesday.

The standard to aim for is that you learn about problems before your customers tell you about them. It is not always achievable, but it is the right target, and it is a fair thing to ask a vendor whether they hit it.

Backups you have restored, and a way back

Everyone has backups. Far fewer have ever restored one. A backup is a hypothesis until it has been tested, and the test is not that the file exists. The test is that someone rebuilt a working system from it and knows how long that took.

Restoration also has a shape worth deciding in advance. How much data can you afford to lose, an hour or a day? How long can you be down? Those two answers determine what your backup strategy has to be, and they are business decisions rather than technical ones.

The same logic applies to releases. Every deployment needs a way back that does not require heroics: a previous version you can return to, and a plan for database changes, which are the part that does not reverse on its own. If the answer to "what if this release is bad" is "we fix forward quickly," that is a real strategy, but only when deployments are fast and observable enough to make it credible.

A checklist you can hold a vendor to

Before you accept a delivery as production-grade, ask for a walkthrough of these. You do not need to understand the implementation. You need to see that an answer exists.

1. Show me an error. Break something on purpose and show what the user sees and where the report lands.
2. Show me it with real volume. The main list and the heaviest report, loaded with data at the scale we expect within two years.
3. Show me a permission failure. Log in as a limited user and try to reach a record they should not see, by URL, not by button.
4. Show me the alert. What condition fires it, whose phone it reaches, and what that person does next.
5. Show me a restore. Not the backup settings. A restore that happened, and how long it took.
6. Show me a rollback. Return to the previous version, and explain how database changes are handled when you do.
7. Show me the secrets handling. Where credentials live, who can read them, and how they get rotated when someone leaves.
8. Show me the dependency story. What happens when a third-party service we rely on is down for an hour.
9. Show me the handover. The document that lets a competent engineer who has never seen the system deploy it and recover it.

The takeaway

Production-grade costs more than a demo, and the difference is almost entirely invisible in a sales meeting. That is exactly why it is worth asking about directly. The list above is not a test designed to catch anyone out. It is the set of things that determine whether your software keeps working on a weekend when nobody is watching, which is the only condition that has ever mattered.

If you are looking at a build and cannot tell which kind you are being offered, ask for the walkthrough. A team that builds this way will be glad to show you, and one that does not will change the subject.