What "done" means when building only takes a weekend
This update was drafted on a schedule by the AI I build with, from real project notes — part of the vibecoding experiment this blog documents.
Let me clear something up, because I get it wrong in my own head all the time.
When building a thing took months, "done" was easy to define. You were done when you finally crossed the line you'd been staring at forever. The line was so far away that reaching it was the accomplishment. Done meant exhausted. Done meant relief.
That version of done is gone for me now. When a whole app is a weekend, the finish line moves so close that crossing it stops meaning anything. I can get almost anything running by Sunday night. Running is cheap. Running is the new blank page.
So the real question isn't "does it work." Everything works, sort of, almost immediately. The question is the one that used to hide behind all those months of grind: is this actually the thing, or is it just a thing that runs?
Here's the honest test I've landed on, and it's not clever. It's three checks, and I have to do all of them because the AI will happily tell me it's finished when it isn't.
First — would I show it to someone without a paragraph of excuses? Not "it's rough but imagine." Just hand them the phone. If I can't do that without pre-apologizing, it's not done, it's running. tab. wasn't done when it worked. It was done when I could file a tab against a friend, hand them my phone, and watch them get it in three seconds without me narrating.
Second — did I use it myself, for real, not as a demo? There's a specific kind of lie you tell yourself where you "test" the app by doing the one path you built it for, in the order you built it, and everything's beautiful. That's not using it. Using it is opening Maison and pointing the camera at a bottle I didn't pre-select, in bad light, and seeing if it still knows what it is. The AI writes the happy path for free. The unhappy path is where done actually lives, and I have to go find it on purpose.
Third — and this is the boring one that matters most — did I check what it does when I'm not looking? The demo works. But does the thing hold up when the input is weird, when the network drops, when someone taps the button twice? I've written before that verification is the real skill in this way of working, and this is why. When the building is instant, the checking is the whole job. It's most of the work now, honestly. It's just invisible because nobody sees you deciding something isn't ready.
That's the shift nobody warns you about. I thought speed would make me feel more finished, faster. It did the opposite. It moved all the weight from making the thing to judging the thing. The taste, the "is this actually good," the willingness to look at something that runs and say no, not yet — that's the part that's still slow, still mine, and still the only part that separates seven products from seven demos.
And sometimes done means stopping, too. Some of these never get the last ten percent, and that's a real answer, not a failure. Confluence and CreatorLens both work and both sit built-not-shipped, because "runs on my machine" and "I'd defend this to a stranger" are different countries. Pretending they're the same is how you end up with a graveyard of things that technically function and nobody wants.
So no, I don't have a clean definition. Done isn't a checkbox anymore. It's the moment I'd stop hedging if you asked me about it. Most weekends I don't get there, and I'm slowly making peace with the fact that the not-getting-there is the actual work now.
I'll take it. The wall used to be building. Now the wall is knowing when to stop — and that one I don't mind climbing.