The code is the small part

This week I wrote a checklist. It was meant to describe everything that has to be in place when we set up a new product, from the name to the alert that fires when it stops responding. I wrote it while actually setting one up, so that every line would be something I had done rather than something I assumed.

It ended up at just over fifty items. The code was three of them.

The left-hand side

An app that AI built for you in an afternoon has one user. You. It runs on localhost. The key to the AI service sits in a file in the project folder. The database is a file next to it. The app is up for as long as the laptop lid is open. And if something breaks, you see it in the terminal that same second.

All of that is true and there is nothing wrong with it. It is still the fastest way to find out whether an idea holds. It just isn't a product.

The right-hand side

When the same app is going to be used by someone other than you, everything the computer did for you without your noticing shows up.

Someone has to own it. Not a person, a company. The domain, the store accounts, the payments and the mail all follow the owner. And a name that looks available needs checking against the trademark register and both app stores before anything is bought.

It has to have an address. The domain has to point correctly, the certificate has to be issued and renewed, and every variant of the address has to lead to one and the same place. One of our domains got no certificate because the public name servers still remembered the registrar's parking page. It answered the challenge instead of us.

It has to be able to send mail that does not land in the junk folder. That means SPF, DKIM, DMARC and a sender that looks like what it claims to be. And a domain's mail can only point one place, so somebody has to decide whether the app receives mail or only sends it.

It has to have a real pipeline. The code has to live somewhere other than the server it runs on. We went through our own services last week and found five codebases that existed only on their server. If the server goes, the code goes with it.

It has to have accounts in the app stores, under the right company, with privacy forms filled in according to what the code actually stores. It has to have a login that does not let anyone in through a test path. It has to have a privacy policy written from the database schema, not from a template.

Data handling

This is the cluster most people skip. It holds the most that does not show until something goes wrong.

Which personal data is stored, where and for how long. Which subprocessors touch it and whether there is an agreement with each one. Whether the data stays in the EU or whether an AI service in the US takes over when the Swedish one does not answer. How a user gets their account deleted, properly. Where the keys are and who can rotate them.

One detail from one of our own services: the proxy in front of it puts every visited path into a public sitemap, to help the search engines. Someone put a key in a link. It ended up in the sitemap. Nobody had made a mistake in their own part. The fault arose between the parts. That is where data handling lives.

One copy only

Locally there is one machine. If it is switched off, only you notice.

In production every request goes through a chain of machines and services. Each link has its own power, its own disk and its own certificate. Some of the links exist in a single copy. The proxy all our products pass through is one. The database host is one. An AI service that several products call sits on a computer at home.

That is not necessarily wrong. These are simply questions that need an answer that works while I am asleep. What happens when the server restarts. When the disk fills up. When the certificate expires. When a supplier closes the account. When the machine at home is switched off. Locally the answer is always that I restart it. In production the answer has to work without me.

My own product

Then I did the uncomfortable thing. I ran the checklist against one of my own products. One with real users, one I describe as production rather than hobby.

It did not pass. Monitoring, alerts, tests and documentation were good. But the backups were not documented, there was no automated pipeline, development happened directly on the production server, and several parts hung on a single machine.

Not because I did not know better. I had written several of the items myself. It happened because every item, taken one at a time, felt like something you do later. That is the logic of the left-hand side, and it follows you into production unless someone actively takes it out.

What you need to know

That raises a question I cannot leave alone. Does the person making the decisions need to be able to do all of these steps?

Not perform them. AI is superb at the doing. It sets up DKIM, writes the deploy script and fills in the stores' privacy forms faster and more often correctly than I do. On several of the steps it already knows more than I do today. I let it do them and I am not embarrassed about that.

But the doing is not what decides. Judgment about the steps requires knowing that they exist, why they exist and what happens when they are missing. Someone who only knows the left-hand side cannot see what is absent on the right. And AI does not ask for what nobody asked it for.

In The empty column I split judgment into three parts. All three apply here. Knowing what matters, because the ten clusters do not weigh the same for every product. Being able to say no to a reasonable conclusion, when AI says everything is deployed and working, and that is true of the code but not of the certificate, the key or the mail. And being able to be held to account, which is only possible for a chain you understand.

To those three I add a fourth, which the checklist makes plain. Being able to make new decisions. A checklist describes how things looked when it was written. Then a supplier changes terms, a store changes its rules, a new model makes a whole cluster of steps unnecessary, and a new law makes another cluster the most important one. At that point there is no earlier solution to repeat. AI will happily propose one. But weighing that proposal against what applies now, for this particular product, is still judgment. And then standing behind the choice. That is the part of the job that grows as the doing gets cheaper.

It is also why the calculation about replacing a team with two people who are sharp on agents gets it wrong. It calculates the left-hand side. Much of what sits in the empty column is the right-hand side: why the proxy sits where it sits, that the sender has to match the server's name, that nobody has ever tried restoring the backup. None of that is in the repo.

But my own product shows that knowing is not enough either. I knew the items and they still did not get done. That is why the checklist exists. It does not replace judgment. It holds judgment in place when every item feels like something you do later. Broad understanding of all the clusters and depth in a few goes a long way. The breadth is what lets you see what is missing.

Where accountability sits

It has become common to say that AI performs and the human takes responsibility. I say it myself. But it often turns into responsibility for the code, for the change that was approved.

The picture above shows why that is not enough. The code is one of ten clusters. A certificate expiring at three in the morning is not a code change. A mail domain landing in the junk folder is not a code change. A key in a sitemap is not a code change. None of them is caught by reviewing what the AI wrote.

Responsibility for a product is responsibility for the whole chain, from the owning company to the alert. That is what I mean when I say my name is on what I deliver. Not the line. The chain.

Building got cheap. Running it costs what it always did. Anyone who says "it works on my machine" is right about the machine and has said nothing at all about the product.

See also: Building got cheap. The bottleneck moved. (Delivery) on why building stopped being what decides, It works in your Claude (Delivery) on what the client does for you that does not travel, and The empty column (Mandate) on the judgment that does not show up in the calculation.