The Quiet Moment Your Build Site Becomes Production

On a Wednesday afternoon, a founder opened the app he had been working in all week and got a blank screen where one of his daily screens used to be. He did not file a bug report. He sent a message that read, more or less, everything is gone.

Nothing was gone. The link he had been using was the same link our team was actively pushing changes into, and one of those changes landed mid-afternoon and broke that screen. Triage took a few minutes, the fix deployed, and he confirmed it was working before the end of the day. Good recovery, wrong system.

The bug is not the interesting part. The interesting part is that a break in our working copy reached a person who was doing his actual job inside it. Somewhere in the weeks before that afternoon, with no meeting and no decision and no line item on any invoice, that URL stopped being a preview and became production.

Nobody schedules this day

Everyone plans for launch. Launch is a date. It goes in the contract, it gets a Slack emoji, both sides treat it as the moment the software becomes real.

The software becomes real earlier than that, and much more quietly. It becomes real the first time somebody who is not on the build team depends on it to get through an afternoon.

That person is almost always the founder, and it starts innocently. They ask for a link so they can click around. Then they open it on a call to show an investor what is coming. Then they type a real customer's real numbers into it, because it is already faster than the spreadsheet they have been living in for six years. By the time anyone says the word launch, there is real data in the system and a human being whose Wednesday is affected by what your developers push at two in the afternoon.

One link, two contracts

A build link and a production app can be byte-for-byte identical software and still be two completely different promises.

The build link promise is: this might be broken at any moment, and if it is, tell us and we will look. The production promise is: this works, and when it does not, someone finds out fast and treats it as an incident.

You cannot make both promises with one copy of the app. That is all an environment is. A production environment is a separate copy with its own database, its own accounts and keys, and its own deploy, one that accepts changes on purpose after a person has checked them. Once it exists, the build environment gets its old freedom back. It is allowed to be broken at two on a Wednesday, because nobody's job is inside it.

Why it gets deferred, and why that is often correct

Standing up a second environment is real work, not a checkbox. A second database. A second set of secrets. A decision about which data lives where. Migrations that now have to run in two places in the right order. A written rule for how a change gets promoted from one side to the other. On a small build that is a day or two of engineering, plus a monthly bill for a copy of an app that, early on, nobody is using.

So it gets deferred. We defer it too. Spinning up production hosting on day one of a build means paying for an empty app and slowing down every change for an audience of zero. Matching the setup to the stage of the project is a real practice, and we would defend it.

The mistake is not deferring it. The mistake is deferring it against the wrong trigger. If your trigger is the launch date, you will always be late, because the app becomes production before it launches. Every time.

The tell

There are three signals, and by the time you notice any of them you are already standing past the line.

The first is that somebody outside the build team has put data into the app that they would be upset to lose. Not test data. Their actual work.

The second is that someone has shown the app to a third party without a developer in the room. An investor, a customer, their own boss. The moment software has an audience nobody warned, it has a reputation.

The third is the loudest, and it is a change in how people report problems. When someone stops saying "here is a bug" and starts saying "is it down," they have stopped reviewing your software and started using it. That is the same sentence people say about their email.

Four questions, if you are the founder

You do not need to know anything about infrastructure to run this check.

How many environments will this app have, and which one am I looking at right now? A shop that works this way answers immediately and can name them.

What happens to the data I enter in the environment you are showing me today? The honest answer early in a build is that it may get wiped, so do not put anything in there you need back. The answer you do not want is a pause.

When does the production environment get created, and is it inside the quote or is it a change order? Either answer is workable. Not having thought about it is not.

Once production exists, how does a change get into it, and who decides that it should? Some shops answer with a process. Some answer with a person's name. Both are good answers. "It just deploys" is not one, because that sentence describes the exact afternoon at the top of this post.

The version of this that costs almost nothing

If you are a few weeks into a build and you have already typed a real customer's name into the app, ask which environment you are in. Ask this week. It is an uncomfortable ten minutes, and a day or two of work if the answer turns out to be the wrong one.

The alternative is finding out the way that founder did, which is that a screen you were about to show somebody went white, and you had no way to tell whether the problem was yours or ours. Nobody schedules that day either. It just shows up, and the setup you have when it arrives is the one you chose weeks earlier by not choosing anything.