The short version
The "I built it in a weekend" post is a vanity flex, and it should be retired. Speed to demo measures the cheapest, least durable thing you can produce, the first working screen, which is exactly what vibe coding is optimized for and exactly the side of the cost curve before maintenance bites. A weekend build proves nothing about whether the thing survives real users, real edge cases, or its own second month. Building fast is a real skill, and a prototype you throw away is healthy. The flex is the problem: it celebrates time to first output as if it were time to durable value, and it trains teams to optimize the half of the cost curve that does not matter for anything they intend to keep. The only question worth asking about a weekend build is whether it was still running the weekend after.
You have seen the post. Someone ships three screens and a demo video over a Saturday, captions it "I built this in a weekend," and the internet rewards it with reposts. I want to kill this flex, because it celebrates the one thing about building that has stopped being hard, and it stays silent on the only thing that was ever hard.
Speed to demo is the cheapest metric there is
Getting to a first working screen used to be a real signal. It meant you had the skill, the focus, and the hours to make something run. It is not that signal anymore. With agents, speed to first output is close to free, which is the whole point of vibe coding. The weekend build is vibe coding's highlight reel.
So the flex now measures the cheapest, least durable thing you can produce. It tells you the demo runs. It tells you nothing about whether the thing survives a real user, a real edge case, or its own second month. You are showing off the part of the cost curve that comes before maintenance starts to bite, and presenting it as if it were the whole graph.
Speed to demo is time to the cheapest, most brittle version of the thing. The metric that matters is time to durable value, and those two numbers have almost nothing to do with each other.
Building fast is fine. The flex is the problem.
I want to be precise, because this is easy to misread. Building something in a weekend is a great skill and a great way to learn. A prototype you build to answer a question and then throw away is healthy, and it is most of what instant prototyping is for.
The problem is not the speed. It is treating the speed as the achievement. The flex broadcasts time to first output as if it were proof of a durable product, and then, far too often, the weekend build does not get thrown away. It gets a demo, the demo gets a customer, and it quietly graduates into production without anyone ever adding structure. That is the exact failure I described in the prototype graveyard. The build that was cheap to make becomes the thing that is expensive to own.
A healthy prototype gets thrown away after it answers its question. A vanity build gets left running because tearing it down is awkward. Watch what happens after the demo.
The only question worth asking
So next time you see "I built this in a weekend," do not ask how. Ask whether it was still running the weekend after. Ask if it has an eval that defines done. Ask if it survives a regression, or if it would still run with no one maintaining it.
Those questions measure time to durable value, which is the number that decides whether you built past the crossover point or stopped on the brittle side of it. I built Falkster to a real revenue number as a company of one, and the reason was never weekend speed. It was that the thing keeps running when I am not touching it. That is the flex worth having, and it does not fit in a Saturday.
Pick one thing to try this week
Find the most impressive demo your team shipped this quarter, the one that got the reaction. Ask the weekend-after question about it honestly. If it would not survive a month unattended, you do not have a win, you have a vanity build accruing debt. Either throw it away on purpose or put structure under it on purpose, but stop letting it sit in the middle collecting applause and interest at the same time.
Also on Medium
Full archive →Is Mob Programming the Right Approach for Your Team?
When mob and pair programming work, when they don't, and how to read the trade-offs.
Why Users Don't Know What They Want Until You Show Them
Visionary product development, when prototypes beat interviews, and how to know the difference.
Frequently asked
Why is the 'I built it in a weekend' flex a vanity metric?+
Because speed to demo measures the cheapest and least durable part of building. A weekend build proves you can get to a first working screen, which is exactly what vibe coding is optimized for and exactly the point on the cost curve before maintenance starts to bite. It says nothing about whether the thing survives contact with real users, real edge cases, or its own second month. The metric that matters is not how fast it shipped, it is whether it was still running the weekend after.
Is building something in a weekend bad?+
No, building fast is a real skill and a great way to learn. The problem is the flex, treating speed to first output as the achievement and broadcasting it as if it were proof of a durable product. A weekend prototype you throw away is healthy. A weekend prototype you quietly push to production without ever adding structure is a maintenance bill disguised as a win.
What should replace speed to demo as a metric?+
Time to durable value, not time to first screenshot. Ask whether the thing has an eval that defines done, whether it survives a regression, and whether it would still run with no one maintaining it. Those questions measure whether you built past the vibe coding crossover point or stopped at the cheap, brittle side of it. Durable value is slower to demo and far cheaper to own.
How does the weekend flex relate to vibe coding?+
The weekend flex is vibe coding's highlight reel. Vibe coding is low CapEx and high OpEx, so it produces an impressive first output fast and an expensive maintenance burden later. The weekend build shows off the first half and hides the second. Celebrating it trains teams to optimize for the half of the curve that does not matter for anything you intend to keep.
How do you tell a healthy prototype from a vanity build?+
Intent. A healthy prototype is built to answer a question and then thrown away or rebuilt with structure. A vanity build is shipped to be admired and then left running because tearing it down is awkward. The test is what happens after the demo: if the answer is 'we kept it as-is and moved on,' you have a vanity build accruing debt, not a prototype that did its job.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn