Build it, prove it, scale it

There is a line on this site: build it, prove it, scale it. It reads like a slogan. It is actually a discipline - three acts, in order, each one guarding against a specific way that work goes wrong. I did not arrive at it as a theory. I arrived at it by watching each failure mode up close, and by committing a few of them myself.

Building without proving gives you a demo. A demo works when its author drives it, on the author's data, along the path the author rehearsed. Step off the path and it folds. The tell is that nobody can say what the thing changed for the person it was built for, or how you would check. I have shipped these. Early in my career I thought the gap between a demo and a product was polish - more features, fewer bugs. It is not. The gap is evidence. A product is a demo that has been made to answer for itself. The habit that closes the gap is simple and uncomfortable: write down what the work is supposed to change and the check that would prove or break the claim, before you claim anything. I eventually published that habit as a standard called Keep a Value, because I kept needing it and kept watching teams skip it.

Proving without scaling gives you an experiment. A true result that never survives contact with volume, or never reaches the people it was true for. Experiments are not worthless - they are how you learn - but an experiment mistaken for delivery is a quiet failure. The result lives in a deck, gets presented twice, and changes nothing. The tell here is the past tense: "we showed that it works." Showed it to whom, and what happened next? If the answer is nothing, you built knowledge and called it impact.

Scaling without proving gives you a liability. This is the worst of the three, because it compounds. Growth multiplies whatever you feed it, and if what you feed it is an unverified claim, you are enlarging the blast radius of something you never checked. Every correction now costs more than it would have at small scale, and the incentive to look closely shrinks exactly as the stakes grow, because nobody wants to audit the thing the numbers depend on.

My own career is the worked example, one act at a time.

The building act was JPMorgan. I spent three years as a software engineer on Story, a commercial-real-estate platform - deal management, document workflows, portfolio analytics for institutional clients. That is where I learned what building actually is when the user is an institution: commercial real estate runs on documents, a deal moves only as fast as they do, and the work was making deals, documents, and analytics behave as one system. A bank also teaches you early that "it works on my machine" is not a sentence anyone wants to hear.

The proving act was Moody's, where I led engineering on Climate on Demand - physical-climate risk analytics for real-estate portfolios. The product's entire value was that an institutional investor or lender could act on its numbers. Here is the concrete version of what proving means: a lender looks at a risk score on a building and asks why it scores that way. "The model says so" is not an answer. Every number had to carry a chain you could walk - what data, what assumptions, what would change it. That is a different engineering discipline than making the number appear on screen, and it is slower, and it is the whole job. Climate on Demand is where I learned that proving is not a phase after building. It is a property the build either has or lacks.

The scaling act is Metaintro, where I am CPO of an AI job-search product that went from 1,000 to 1,000,000 users in four months. Scaling is its own teacher, and the main lesson is that scale finds everything you did not prove. Every shortcut, every assumption that held at small numbers, every "good enough for now" - the growth curve runs through all of them and tells you, loudly, which ones were not good enough. And here is the honest limitation of the whole framework: the acts are not clean in real life. When a million users arrive in four months, you do not get to sequence neatly - parts of the system scaled ahead of being proven, and we paid that debt with interest, under load, in the least comfortable order. The discipline is not "never scale before proving." Nobody who has shipped under real growth gets to say that with a straight face. The discipline is knowing, at all times, which act each part of your system is actually in, and what you still owe it.

There is also a counterexample I keep on purpose. Milo is an AI assistant I built for my family - one assistant, reaching each person on the channel they already use. It is built, and it is proven the only way that matters for it: my family uses it every day. It will never be scaled, and that is not an unfinished third act. Not everything owes act three. The discipline includes knowing when the answer to "should this scale?" is no, and being at peace with a small thing that works.

Why insist on the order at all, if reality bends it? Because the order is what each act protects. Proving protects building from becoming performance. Scaling protects proving from becoming trivia. And proving, again, protects scaling from becoming reckless - which is why it sits in the middle, touching both. Skip the middle act and the other two turn on you: building becomes demos, scaling becomes liability, and the resume still looks great, which is exactly the problem. All three failure modes photograph well. Demos are impressive. Experiments are interesting. Hockey-stick growth is intoxicating. The discipline exists because the failure modes are attractive.

So the slogan compresses to this: make the thing real, make the claim checkable, then - and only then, and only if it should - make it big. I hold my own work to that order, I bend it under pressure like everyone else, and the difference between bending it knowingly and bending it blindly turns out to be most of what people mean by judgment.