Built to work, or built to be operated

Almost every system we are asked to rescue worked on the day it was handed over. It stopped being viable later, when the team changed, the volume rose, or somebody needed to answer a question the system was never designed to answer.

There is a distinction that rarely survives a procurement process. A system can be built to work, or it can be built to be operated. The first is a demonstration that happens to be in production. The second is something a business can own. They look identical at handover, they cost noticeably different amounts, and only one of them is still serving the business in three years.

The reason the distinction disappears is that nothing in a normal buying process tests for it. A demonstration shows the happy path. A specification lists features. Neither asks what happens at two in the morning when a queue backs up, or what a new engineer has to read before they can safely change the pricing logic. Those questions have answers that cost money at build time and save considerably more later, which makes them easy to defer and expensive to have deferred.

The three decisions that separate them

In practice the difference comes down to three design decisions taken in the first release. None of them are exotic, and all of them are structural, which is why retrofitting them means rewriting rather than adding.

Observability

Built to work: errors surface when a user reports them. Built to be operated: the system emits structured logs, traces a request across services, and alerts on the symptom a user would notice before the user notices it. The test is simple. When something breaks, can you tell what broke without reproducing it?

Deployment

Built to work: releases are an event, performed by the person who knows how. Built to be operated: releases are routine, automated, and reversible, and the same pipeline runs for a one line change and a quarterly release. The test is whether anyone on the team can ship on a Friday without a discussion about whether they should.

Access design

Built to work: everyone who needs to get in can get in. Built to be operated: roles and permissions are modelled, access is granted against them, and revoking somebody takes one action with a record of it. The test is how long it takes to answer who can see customer data, and whether the answer is a list or an opinion.

Why the invoice arrives late

The economics are what make this worth writing down. A system built to work is cheaper to commission and roughly the same to run, right up until the first thing that was never designed for happens. Then the cost arrives all at once, and it arrives as an emergency, which is the most expensive way to buy anything.

Consider a business that needs to add a second warehouse. In a system built to be operated, that is configuration. In a system built to work, the location was implicit in the schema, so it is a data migration, a permissions rework, and a fortnight of reconciliation. The requirement was reasonable. The system simply had no seam where the requirement needed one.

The same pattern applies to staff. A system built by one engineer who understood all of it is fine while that engineer is there. What makes it operable is not documentation for its own sake, it is that the structure of the code, the naming of the data, and the shape of the deployment tell a new engineer what is going on. Documentation that has to compensate for an unclear system is documentation nobody trusts within six months.

What this looks like in the first release

• Structured logging and tracing shipped with version one, not added after the first incident
• A deployment pipeline that runs from commit to production without a person in the middle
• A role and permission model written down before the first user is created
• An audit trail on anything a customer or a regulator might later ask about
• A schema that names the things the business actually has, including the ones it does not have yet
• A runbook covering the three failures most likely to happen, written by whoever would be called

None of that is a large proportion of a build. On most engagements it is a low double digit percentage of the initial cost, and it is the part that stops the system needing replacement rather than extension. The reason it gets cut is that it is invisible in a demonstration, and demonstrations are what most buying decisions are made on.

The realistic version of the trade

There are cases where building to work is correct. A genuine prototype, something with a known end date, a test of a commercial hypothesis that will be thrown away either way. The failure is not building the cheaper thing, it is building the cheaper thing while believing you bought the other one, and then discovering the difference when a customer asks for an audit trail that was never designed in.

So the question to put to anyone proposing to build for you is not whether the system will work. It will. The question is what happens on the day something changes: a new site, a new regulation, a new engineer, a bad afternoon. If the answer involves rewriting rather than configuring, you are being quoted for the first kind of system at the price of the second.