Building Inside a Live Company

I want to start with something I find a little embarrassing, because it took me much longer to understand than it should have.

Almost everything written about building software assumes a set of conditions I have never actually had. A clean slate. A team to catch the things you miss. A staging environment nobody depends on, where you can break whatever you want at two in the morning and the only casualty is your own sleep. The freedom, when you get down to it, to be wrong in private until you have figured out how to be right. I read that kind of advice for years and quietly assumed it applied to me, the way you assume a recipe applies to your kitchen. It mostly doesn’t. What I have instead is a running company, and the gap between those two situations has turned out to be most of the story of how I actually build.

The software I make is in use every day by people who are not engineers and did not sign up to be test subjects. They have quotes to send, orders to push into production, customers waiting on the other end of an email. So when something I changed at midnight is wrong, they do not find out in a code review. They find out at nine the next morning, in the middle of a task, with someone on the phone. It is not a ticket sitting politely in a backlog. It is somebody’s morning. And I have come to think that this one fact, more than any tool or framework or clever decision, is the thing that has really shaped the work.

For a long time I thought of all this as the hard version of the job. The version with the safety rails taken off. And I will be honest, some days it still feels like exactly that.

But I have been turning it over lately, and I am no longer sure “hard mode” is the right way to describe it. Or it is true, but it is not the interesting part of the truth. And if you build anything for people who depend on it, the interesting part is yours too, so let me try to get at it.

There is no Monday where the new system appears

Let me try to describe what building on a live system actually feels like, because I do not think the phrase carries its own weight.

In a tutorial, there is always an implied Monday. The day the rewrite ships. The before, and then the clean after. You work in the dark for a while, and then you flip a switch and the new thing exists. I used to picture my work that way too, and it took me an embarrassingly long time to notice that the Monday never comes. There is no version of this where the new system arrives all at once. There is only the current system, the one people are using right now, and the small careful change I am about to make to it while it keeps running. Every change is closer to open-heart surgery on a machine that cannot be switched off than it is to building something new on an empty lot.

Which means I cannot do most of the things the tutorials take for granted. No big-bang rewrite. No “we will fix the data later,” because later never has a quiet moment to arrive in. Everything goes out in small, boring, reversible pieces, not because I am especially disciplined but because the cost of being wrong is paid by somebody other than me, and that changes the math on every single decision. A bold move that might save me a week is not worth it if the failure case is a person standing at a screen, stuck, while a customer waits.

Here is the honest texture of it. I have caught myself, more than once, with my hand resting over the keyboard, not because I did not know what to type but because I knew exactly who would feel it if I typed the wrong thing. For a while that hesitation annoyed me. I read it as slowness, as a lack of nerve. I am starting to think it might be the single most useful instinct I have developed, and that the version of me who could type without that hesitation was not braver, just further from the consequences. If you have felt that pause in your own work, do not be in a hurry to train it out of yourself. It is not timidity. It is information about who pays for your mistakes.

The constraint started doing my thinking for me

This is the part where I changed my mind, and I want to actually walk through it instead of just asserting it, because the assertion is cheap and the walking-through is the thing that convinced me.

If you had asked me a year ago, I would have told you the live constraint was a tax. Something I paid in exchange for the work being real. Pure cost, grudgingly accepted. What I did not see is that the constraint was quietly making decisions I would otherwise have made badly.

It will not let me build the clever abstraction that nobody needs. There is no time for it and no cover for it, and a running company has a wonderful way of ignoring anything that does not earn its place that week. It tells me almost immediately when a feature does not fit the way the work actually happens, because the people doing the work will say so by lunch, in plain language, without a single thought for my feelings about the architecture. A feature that survives contact with a real Tuesday is worth ten that demo well in a meeting. I knew that sentence was true before I believed it. The live system is what made me believe it.

And the strange thing is how much of the methodology I have written about elsewhere is really just this instinct, formalized. The whole framework I work from rests on the idea that you build up from what is actually true: decompose the product, get the real data, and let pricing and quoting and the rest become functions of that instead of guesses. I used to think I arrived at that by being principled. Looking back, I think the live constraint arrived at it for me and let me take the credit. You cannot get away with a guess for very long when the guess is going to be wrong in front of someone by Thursday. I wrote a whole separate note about how that played out with our cost data, how the boring foundation has to come before the clever layer, and only now do I see that both of those lessons have the same parent. The constraint was the teacher. I was just the one taking notes.

So I want to be careful not to romanticize it, because that is the easy move and I do not fully trust it. The constraint is not magic. It does not make me a better engineer in some general, transferable way. What it does is narrower and more honest than that: it removes my ability to fool myself for very long. That is all. It just turns out that the ability to fool yourself, undisturbed, for months at a time, is most of what goes wrong in software.

So if you want the practical version of all this, it is almost insultingly simple. Put yourself somewhere you cannot get away with fooling yourself for long. Ship to real people, in pieces small enough to take back, and let them tell you by lunch when you are wrong. You will not have to muster the discipline to build only what is real, because the situation will keep supplying it for you.

The part that humbles me

There is a sentence I used to lean on without noticing how much weight I was putting on it. “Technically, it works.”

It is a comforting sentence. It means the code does what the spec said. It means I can close the laptop. And it is almost always beside the point, because “technically it works” can still cost a real person an hour of their actual day. The form that saved most of the way and then lost the rest. The error message that nobody reads until it is the only thing on the screen and they have no idea what to do next. The thing that happens when the network blips in the middle of a quote and the state ends up somewhere I never imagined, because I was thinking about the happy path and they were just trying to get their work done.

Building for people you can picture does something to you. I am not sure I would call it pressure, exactly, though it is related. It is closer to a kind of attention. When the user is an abstraction, the unglamorous edges feel optional, like polish you will get to if there is time. When the user is a specific person who is going to be standing at a screen at four in the afternoon with a customer waiting, the edges stop being edges. They become the whole thing. I have spent more care on a half-saved form than on features I was much prouder of, and I have stopped feeling like that is a misallocation. The proud features were for me. The half-saved form was for them. You probably already know, in your own work, which of your features were which. Building for someone you can picture just makes the difference impossible to keep ignoring.

Reality reviews in public

I build most of this alone, though not really alone, and for a while I worried about the absence of a second set of eyes. No senior engineer to catch my mistakes before they ship. No review gate. It felt like a real gap, and on the narrow technical points it sometimes is.

But I have come to think I do have a reviewer, and it is a more honest one than most. It is reality. The live system reviews every decision I make, continuously, and it gives its feedback in public. If I have understood the work, the feature gets used and disappears into the background the way good tools do. If I have not, I hear about it, and not as an abstract critique but as a concrete person who could not do the thing they needed to do. There is no arguing with that reviewer. It does not care how elegant the solution is. It only cares whether the work held up when a real person leaned on it, which is, in the end, the only question that was ever going to matter.

This is also what I mean when I say I am building the platform in the open, and why I have started writing about it while it is still being built rather than reconstructing it later from a safe distance. Reconstruction is flattering. You get to skip the parts where you were wrong. Writing about it now, while the system still has to keep working tomorrow, keeps me closer to the truth of it, because I cannot quietly edit out the mistakes when the mistakes are still load-bearing. If you want your own account of your work to stay honest, write it while it is still load-bearing too. Hindsight is generous in a way that does not teach anyone much.

And it has changed what “done” even means to me. There is no done. There is only working, today, for the people who depend on it, and a quiet obligation to keep it that way tomorrow. I used to find that exhausting to think about. Lately I find it almost clarifying. A thing that is never finished is a thing you never get to stop caring about, and I am not sure I would want the version of this work where I was allowed to stop.

Would I trade it?

So let me ask myself the honest question, the one I have been circling the whole time. If someone offered me the clean slate tomorrow, the team and the staging environment and the freedom to be wrong in private, would I take it?

I want to say no, cleanly, and make a tidy ending out of it. But that is not quite true either, and I promised myself I would not do that. Some days I would take the clean slate in a heartbeat. Some days I am tired, and the weight of building on live wires is just weight.

What I think is actually true is smaller and steadier than a clean yes or no. The greenfield teaches you to build what is elegant. The live system teaches you to build what is true, and it does it by refusing to let you confuse the two for very long. I did not choose that lesson. It was handed to me by circumstance, and I resented it for longer than I would like to admit. But it has made me a more careful builder than any amount of empty land ever could have, and at this point I am not sure I would know how to unlearn it.

Maybe that is the real answer. Not that the constraint is a gift, which sounds too neat. Just that it became part of how I think, so quietly that I cannot find the seam anymore between the discipline and me. And if you are building something inside a running operation of your own, on live wires, for people who will feel it when you are wrong, I suspect you already know the feeling I am describing. The only thing I would tell you is the thing it took me too long to learn myself: the constraint you keep resenting is probably the one teaching you the most.