Shipping the master, not the demo

There is a moment every musician knows.

The demo is finished. It sounds great in the room you made it in. You play it back and grin.

Then a mastering engineer gets hold of it, and you realise that wasn't the song. That was the sketch of the song.

The master is the version that holds up. In the car. On cheap earbuds. On a phone speaker on a train, and on the one expensive hi-fi owned by the one person who judges everything. The master is the song surviving contact with the real world.

I've started thinking about software the same way. Especially mobile. Especially now.

The afternoon app

Starting a mobile app used to be hard. Now it isn't.

You can describe an app to an AI and watch it assemble in front of you. Screens. Navigation. A login that works. It runs. It looks like the screenshot in the pitch deck. It is, genuinely, remarkable.

It is also a demo.

I've started calling this state demo-done. Demo-done is when the thing looks finished. It compiles, it clicks, it survives a ninety-second walkthrough in a meeting. It is a real and useful place to reach, and AI gets you there faster than anyone believed possible.

Demo-done is not done.

The part everyone gets backwards

The story we keep telling ourselves is that AI made the expensive part cheap. That the craft got commoditised, and the value moved somewhere else.

It's the other way around.

The part AI does well (the scaffold, the look, the demo) is the cheap part. It always was. The expensive part, the finishing, is still yours. And as the demo becomes effortless, the finishing becomes the only thing left worth paying for.

The value didn't leave. It concentrated.

And no, the AI itself isn't free, and it isn't getting cheaper. The bill goes up every quarter. Which only sharpens the question: if you're paying real money to have the easy part done for you, why would you hand the same tool the part that actually decides whether you get paid?

The two faces of finishing

In enterprise and government work, the gap between demo-done and done has two faces.

One face is what the customer touches. The transition that feels like breathing instead of jumping. The hierarchy that puts the right thing under the thumb. The accessibility that means it works for the person using a screen reader on the train, not just the person in the demo. The moment in someone's hand. AI doesn't miss this because it's stupid. It misses it because it has never held the phone.

The other face is what the customer trusts. The token that doesn't leak. The offline state that doesn't quietly lose someone's work. The code that survives a security audit, a million users, and a regulator who is not interested in how fast you shipped. AI will write you a test and tell you it passed. Open it. Sometimes the test asserts nothing at all.

Both faces are the same skill wearing different clothes. Call it taste. The engineer who reads a pull request and says "this will bite us" is using the same muscle as the designer who says "this animation is fighting the user." Both of them are finishing.

The one I worry about

I'm not anti-AI. I use it every day.

The app I worry about is the one that is only demo-done, and gets shipped anyway. It looks fine in a screenshot and falls apart in a hand. It demos in five minutes and dies in production. And the people it fails are almost never the people who shipped it. In government and enterprise they are citizens, patients, staff, the person who just needed the thing to work the first time.

Demo-done shipped as done is a quiet way of saying: this was good enough for the meeting, so it's good enough for you.

It isn't.

So

Whether you write the code or design the thing the code has to hold up, here's the question worth keeping on your desk:

Is what you're about to ship demo-done, or done?

Anyone can make the demo now.

Ship the master.