Posts connected by the reliability tag.
3 posts
Building a product and running it are two different kinds of work. Development ends when the thing exists; production never ends, and what it teaches has to flow back into the product as its own stream of work. Treating the two as one job hides the second one, and the accounting split between cost of goods sold and operating expenses turns out to describe the same line.
The first 80% of a feature gets the demo, the congratulations, and the promotion packet. The last 20% (the part that makes the thing actually usable) costs a magnitude more and is rewarded far less. The reason is structural: every additional nine of reliability is a different engineering problem than the one before it, and you cannot reach it by extending a design that was never built for it. In the age of AI, when the token cost of writing the scalable version is roughly the token cost of writing the disposable one, the V1-then-rewrite habit deserves a second look.
I used to say bad version, bad rollout, bad payload. I stopped, because a version isn't good or bad in the abstract. It's a distribution of outcomes across a population of users, configs, and use cases. The same payload can be flawless for 99% and broken for 0.5%, and calling it bad collapses that spectrum onto one label that quietly dictates how you triage, communicate, and remember the incident.