MVP Builder

Two weeks ago I did something I'd never done in two years of building: I read my own terms of service as a specification instead of as legalese.

Every sentence in there that describes behaviour is functionally an assertion about the software. "Daily check-ins are recommended but not mandatory" is a test case — it says the system must not punish someone for skipping one. Nothing in a normal build ever evaluates that.

So I went through it clause by clause and looked for the place in the product that actually executes each one. Fifteen didn't match.

The one that still bothers me: on day 7 the dashboard demanded proof of work, and my own contract calls that day's check-in voluntary. Someone who read the contract and believed it would have uploaded nothing and walked into the consequence meant for people doing nothing at all. The product would have punished someone for trusting a commitment I made.

Nobody was affected — no paying customer has ever started a sprint in this thing and there's no testimonial. That's not an excuse, it's the only reason I can post this at all. Fifteen instances of one class, in a product with no paying sprint behind it, all fixed the same day.

Three things I'd hand to anyone doing the same:

Record the direction, not just the deviation. Half my findings were the code being stricter than the contract — including one where I advertised a faster response time than I'd contractually committed to. Nobody complains about a promise that's too generous, so those errors are silent by construction and survive until someone audits. The mirror image, contract promising more than the software delivers, is the one that's actually a liability. Same measurement, completely different consequence.

The worst class is the one that looks fine. Two code paths in there could never fire. Not broken — unreachable. No test went red, because no test asserts "this line is ever reached". No error surfaced, because a path that never runs never fails. I only found them by running the whole chain end to end once, which is manual work.

A comment has no assertion. A README has no CI. Your terms of service are a test suite nobody runs. Two specifications exist in every product like this and only one gets tested — and the untestable one is the one that legally binds. The code has linters, types, a pipeline, a reviewer. The text that governs in a dispute has an author and a date.

Here's the part I didn't expect. I built a small string check that fails the build when a retired sentence reappears, and ran it that same evening. It immediately found a fifteenth instance — same class, same wording, in a file I hadn't looked at and neither had the review pass that had just declared my list complete at fourteen.

So the tool caught something a careful human read had missed hours earlier. But it's also nearly useless for the expensive cases: it knows strings, not meaning, it can't tell a claim from its negation, and absence is completely invisible to it — a promise that quietly disappears produces no match at all. Roughly a third of my findings, all from the cheap end.

Which leaves me with a question I genuinely don't have an answer to.

The obvious fix is more supervision: more rules, more checks, a ritual before every release. But every rule I add is another thing to maintain, and the root cause wasn't sloppiness — it was the same statement living in four, six, eleven places, with none of them saying how many there are. Maybe the right move isn't to watch more carriers. Maybe it's to have fewer.

So: for those of you a few years in — did you ever deliberately delete a surface rather than maintain it? Docs, a README section, a marketing page, a status file. Did the drift actually stop, or did it just move somewhere you weren't looking?

I'm asking because deleting feels like giving up on the documentation, and I can't tell yet whether that instinct is right or just tidy.

I went looking for the exact wording of Paul Graham's "launch fast" last week and found something that changed how I read it.

The instruction is in Startups in 13 Sentences. The reason most people quote for it — you learn what you should have been building — is also there.

But the sharper argument is in a different essay entirely, The Hardest Lessons for Startups to Learn, from April 2006:

> "Perhaps the most important reason to release early, though, is that it makes you work harder. When you're working on something that isn't released, problems are intriguing. In something that's out there, problems are alarming. There is a lot more urgency once you release. And I think that's precisely why people put it off. They know they'll have to work a lot harder once they do."

That last line is the part I keep coming back to. He isn't saying people are perfectionists. He's saying they postpone because they know what comes after.

Which reframes the whole thing. Not shipping isn't a skill problem or a motivation problem. It's a rational response to the fact that launching creates an obligation, and not launching doesn't.

Here's what I think has changed since 2006 and what hasn't:

Building got cheap. A working skeleton takes an afternoon now. That was the half Graham wasn't even talking about, and it's solved.

The half he was talking about — the moment a problem stops being intriguing and starts being alarming — is untouched. An agent writes your code. It doesn't get nervous when something breaks. So cheap building doesn't give us more finished projects. It gives us more half-finished ones, faster.

The thing that made me post this: I found the identical test in an enterprise context, twenty years later. 8090.ai lists five criteria for what counts as a "software factory" rather than a tool, and the fifth is accountability — when the output is wrong, "someone specific answers for it, fixes it and eats the cost." They call the usual alternative, "the output is provided as-is and verification is your problem," disqualifying.

Enterprise version: who takes the call when it breaks in production.

Solo version: who notices if I skip day 4?

For most of us the honest answer is nobody. No colleague, no standup, no deadline that affects another human. And that's precisely why the postponing is rational.

I don't have a clean answer to this. Reminders don't do it — a reminder from a system that gives up nothing isn't an obligation, it's a notification. Public accountability threads work for some people and turn into performance for others.

So the question I actually want to ask here:

For those of you who did ship something on the side — what was the thing that made postponing cost you something? A person, a deadline, money already spent, a public promise? Or did you just find a week where you felt like it?

I'm asking because I suspect the honest answer for most is the last one, and I'd like to be wrong.

I run a product that holds developers to a 21-day sprint. Last month I ran it on myself, as a participant, on a separate product of my own.

Four goal criterIia, frozen before day one. I hit three. Here's the one I missed and why I think it's the useful part.

The setup: goals get written down at acceptance and can only be corrected downward afterwards, never upward. Every milestone is measured against that stored wording. The idea is that a goal you can edit mid-sprint isn't a commitment, it's a description of whatever happened.

The miss: criterion 3 required three completed reciprocal feedback exchanges between developers, 48 hours each. I got two.

The third contact went quiet after one follow-up. And I have a rule for myself: one follow-up per contact, then never again. A second nudge might have saved the criterion. It would have broken the rule.

So I kept the rule, missed the criterion, and filed it as a miss — not as "substantially met."

Why I'm posting this instead of the three I hit:

A frozen goal is worth precisely what it costs to miss it. If I'd rounded 2 of 3 up to a checkmark, I'd have proved that my own enforcement is decorative. The miss is the only evidence that it isn't.

The part I didn't expect: running my own product as a participant surfaced three defects that no test had found — including one data-protection bug that had been live for three and a half months, and a qualification filter that was only ever shown to people who had already disqualified themselves. A filter that only reaches the already-filtered isn't filtering. It just feels like one while you build it.

One more finding — and then the correction I had to make to it: both feedback exchanges that did happen came inbound, from a single public post, and both because I delivered first. Cold outreach to more than a dozen people stayed silent. I wrote that down as "going first converts existing interest, it doesn't create any," and filed it as a result.

Then I did the arithmetic. Sixteen contacts at a normal cold-reply rate is well under one expected reply. Silence was the single most likely outcome even in a world where cold outreach works fine. I had turned a null result into a law — which is the same move as rounding 2 of 3 up to a checkmark, just pointing the other way.

---

To be clear about what this is: a self-test, not a customer result. Nobody paid for it, there's no testimonial, and no paying customer has completed a full sprint yet. It proves the mechanism runs — nothing about whether it's worth paying for.

What I'm curious about: for those of you who set explicit goals for a build sprint or a launch window — do you log the misses anywhere, or do they quietly become "mostly done"? I've caught myself doing the second one for years, and the only thing that stopped it was writing the goal down somewhere I couldn't edit.

Anthropic published their own numbers recently. Not a vendor pitch — the company that builds the model, talking about its own engineers. Task-completion capability roughly doubling every four months. Over 80% of their own production code now written by their model. Engineers shipping 8x more per quarter than last year.

First reaction: if the people building the thing are moving 8x faster, what's even left for the rest of us?

Second reaction, after sitting with it: that's the wrong question, and the same piece answers why.

There's an independent study (METR) that measured regular developers using AI on real repos and found the opposite — 19% slower, not faster. Both are real. The difference is that Anthropic's number comes from a team with code review, merge gates, and engineers deciding what actually ships wrapped around the model. Without that, the model alone doesn't get you the 8x — METR's devs didn't have it, and it showed.

Which is exactly the shape of the gap I keep seeing in side projects. The build stopped being the hard part a while ago. What's missing when a project dies at 80% was never "the code doesn't work." It's nobody playing the role Anthropic's engineers are playing for their own codebase — deciding it's actually done, and closing the loop.

One line from the piece, from someone inside Anthropic on a day the automation worked almost too well: "nothing I do matters, everything is automated." Followed a few paragraphs later by the correction: "the comparative advantage of humans as of right now is still in seeing the bigger picture."

Not the code. The bigger picture — what ships, what doesn't, and whether it's real yet.

AI tracks. A human reads. If you've got something sitting at 80% right now, that's not a tooling problem you're missing — it's the same gap Anthropic's own numbers just made visible at scale.

https://mvpbuilder.io/?utm_source=indiehackers&utm_medium=social&utm_campaign=bottleneck&utm_content=biggerpicture

Someone posted a teardown of 100+ AI-built SaaS repos this week. The apps ran. The UIs looked fine. The builds passed. Almost none were safe to go live — but that's not the part that stuck with me.

What stuck with me is what it says about finishing.

AI got these builders to a running app in days. That's the 80% — it compiles, the demo works, the screenshot looks shippable. And that's exactly where "done" feels true, right before the part that decides whether you actually have a product.

The last 20% is different work. Not "make it exist" — "make it hold up when a stranger touches it." No dopamine, no applause. It happens after hours, alone, when the excitement's gone. That's where most of these projects quietly die.

It's not a tooling gap. No better model closes it for you. It's a follow-through gap. The tool handed you a build — it won't notice you stopped one commit short of shipping.

"It works" means the happy path passed. "It's shipped" means you did the 20% that had no happy path.

I'm building around exactly this — the human layer that notices when you're about to abandon at 80%. AI tracks; a human reads. If you've got something stuck at 80% right now, that's the normal place to get stuck — and the only one worth pushing through.

https://mvpbuilder.io/?utm_source=indiehackers&utm_medium=social&utm_campaign=bottleneck&utm_content=itworkslie

I have a folder of repos that all got to about 80%. Auth works. Core loop works. There's a deploy with a real URL somewhere. And then nothing — no launch, no users, no Stripe key in prod. Four or five of them, sitting next to each other.

For years I blamed time, skill, or the stack. Then AI removed all three excuses at once. The folder kept growing. That's the part I can't stop thinking about.

The question going around is "is AI making me obsolete?" — and I think that's the wrong question. The one that actually stings is: why am I not finishing anything, now that building got easy?

Goldratt's Theory of Constraints has a useful answer. Every system has exactly one bottleneck. And when you lift it, it doesn't vanish — it relocates to the next station. "Writing the code" was the constraint for most of us for a long time. AI lifted that ceiling. So building throughput shot up, and the constraint quietly slid one station down the line.

It landed on follow-through.

Here's the part I want to put up for discussion, because it's counterintuitive: better build tools make the gap wider, not narrower. Agentic coding, one-shot generators, AI pair-programmers — they 10x a station that's no longer the bottleneck. Through the TOC lens, that doesn't raise throughput; it just stacks a bigger pile of half-built work in front of the real constraint. A faster builder pointed at an unmoved finishing problem generates a larger graveyard, faster.

Which means finishing isn't the chore you do after the differentiation. Finishing is the differentiation now — it's the one part of the pipeline this cycle didn't commoditize.

The way I frame it for myself: AI makes you a builder. The work makes you a finisher. That shift happens somewhere no tool reaches — in the boring, repeated act of returning to the same unfinished thing until it's actually out.

I'm a developer with a full-time job building toward exactly this problem in the open, so I'm not neutral. But I'm genuinely curious where the IH crowd lands:

- What's your repo-to-shipped ratio honestly?

- Has AI made you ship more, or just start more?

If you'd rather see what I'm building than take my word for it, it's here: https://mvpbuilder.io/?utm_source=indiehackers&utm_medium=post&utm_campaign=cohort2&utm_content=bottleneck — but the question stands on its own whether or not you click it.

I spent last afternoon/evening at Vercel's Ship 26 in Berlin. A dark room, a few hundred developers, and one message repeated from every angle: software is agentic now. Agents deploy, agents build agents, agents watch production.

And the numbers back it up. Over half of Vercel's deploys now come from coding agents — up 17x in six months. One talk put it differently: ~60% of enterprise commits are now written by agents. Building is, more or less, solved.

The slide that stuck with me wasn't about agents at all.

In one of the engineering talks, a team put up their own internal data on rolling out AI tools. The capability line went straight up — exactly what you'd expect. The results line didn't. It rose a little, then flattened and stalled around a 40% productivity gain. They'd labeled it themselves, in big letters: "THE PLATEAU." A dotted line showed where they'd be if it had scaled linearly — way up and to the right. The gap between those two lines is the entire thing I'm building.

It's the same shape as the METR study last year: experienced devs were given AI tools, expected to go faster, and measured themselves 19% slower. More capability did not become more shipped.

Here's the part nobody on stage said out loud, because it doesn't sell infrastructure. When agents write half your code, building stops being the hard part — and the bottleneck doesn't disappear, it moves up a layer. To the part agents can't do for you: finishing. Owning it. Showing up on Day 4 when the novelty's gone and nobody's watching.

The most advanced agent stack in the room is architected around a human gate — production changes wait for a human to approve them. Vercel keeps a human in the loop on production. Almost nobody keeps one on themselves.

A dashboard doesn't fix this. It shows you activity; it doesn't notice your absence. AI tracks. A human reads.

If your projects keep dying at the same point — and it's usually the same point, your point — more agents won't fix it. I built a free 7-question diagnostic for exactly that, then killed it two weeks later: zero completions. What replaced it asks a smaller question — is a structured sprint the right tool for this at all: https://mvpbuilder.io/go?utm_source=indiehackers&utm_medium=post&utm_campaign=cohort2&utm_content=ship26

Building in public. Day 139.

The agent does the work now. The "almost done" graveyard is getting bigger, not smaller.

Faster building was supposed to mean more shipping. For me it meant the opposite. My agent shipped 12 clean PRs in a weekend — and the product still isn't live three weeks later.

I got good at the part everyone talks about: the harness around the model. Scoped context, clean prompts, reviewing every diff, never letting it run wild. That works. The model isn't the problem.

The problem is I built all that discipline for the machine and none of it for myself.

The agent has a loop that checks its own output. I have no loop. When the code is 90% done in days, the only thing standing between me and live is whether someone notices when I go quiet. And on Day 4 of a side project, alone, nobody does.

A dashboard doesn't fix this — it shows you activity, it doesn't notice your absence. A streak counter is just a nicer way to watch yourself quit. The one thing that actually works is embarrassingly old: a human who reads, and names the move you're avoiding.

AI tracks. A human reads.

If your projects keep dying at the same point — and it's usually the same point, your point — more agents won't fix it. I built a free 7-question diagnostic for exactly that, then killed it two weeks later: zero completions. What replaced it asks a smaller question — is a structured sprint the right tool for this at all: https://mvpbuilder.io/go?utm_source=indiehackers&utm_medium=post&utm_campaign=cohort2&utm_content=harness

Building in public. Day 134.

You've had a project sitting at 70% for six months.

You started it. The hard part's done. It runs locally. And it's been "almost ready" since some point you can't quite pin down. You have a fulltime job — that's not changing. So every evening you don't ship, it slides a little further into the pile of things you'll get to.

Here's the part nobody says out loud: a fourth plan won't fix it. You don't have a planning problem. You have a project that's 70% done and one specific thing in the way — and you've stopped being able to see what it is, because you're too close to it.

That's the thing I started doing. A 30-minute call where I look at your stuck project and tell you the one thing that's actually blocking it. No slides. No framework pitch. Not coaching, not consulting — just a clear diagnosis. You leave with a decision, not another plan.

It's CHF 29 / USD 29, one-off. It's a standalone thing — if it makes sense afterwards to talk about more, we can, but that's not what you're paying for. You're paying for the diagnosis.

Building this in public, no big track record to wave around — just an honest offer for an honest problem.

3 slots open this week. Links in the first comment.

You debug your code. You debug your build. You debug the flaky test that only fails in CI.

You have never once debugged the thing that actually kills your side projects: why you stop.

I've watched a lot of full-time developers try to ship something on the side. Different stacks, different ideas, different jobs. And the way they fail is not random. It collapses into a small number of repeating patterns — predictable enough that you can name yours in about seven questions.

Here's the part that surprised me: it's almost never a discipline problem. It's a pattern. And a pattern is debuggable.

Why "discipline" is the wrong diagnosis

The default story you tell yourself when a project dies is a character story. I'm not consistent enough. I lost motivation. I got distracted.

That framing is a trap, because you can't fix a character flaw on a Tuesday night. But a pattern has a specific shape, a specific failure point, and a specific thing you can do differently the next time you hit it.

And there's an environmental reason the patterns got worse recently. METR measured experienced developers on real tasks in 2025 and found they were 19% slower with AI tools — because AI eats the easy parts and leaves you alone at the hard, boring, project-killing part. AI gives you the plan. It won't notice when you skip Day 4.

So the question isn't "am I disciplined enough." It's "which failure mode is mine, and what's the one move that breaks it."

The 5 failure modes

See if one of these is uncomfortably familiar.

1. The Perpetual Planner. You never actually start building. The project dies as a Notion doc, not a repo. You have the architecture, the roadmap, the perfect name — and zero deployed code.

2. The Flash-in-the-Pan. You love Day 1. The energy is real and it's gone by Day 4. The graveyard of your projects all died in the same week.

3. The Feature Deep Diver. You disappear into one feature nobody asked for. "Let me just quickly add this" becomes three weeks, and the actual MVP never ships because you're polishing a thing no user will ever see.

4. The Almost-Shipper. You get to 80–90% and stop. The last 10% — deploy, polish, the launch button — is where the project goes to die. You have working software on your machine that the world will never use.

5. The Serial Starter. Your GitHub is a graveyard of Day-1 commits. You don't have an idea shortage. You have a finishing shortage, and a new idea always feels better than the unfinished one in front of you.

Read those again. Odds are one of them stung more than the others. That's not a coincidence — that's your mode.

The reason you can't see it yourself

You're inside the pattern while it's happening. On Day 4, the Flash-in-the-Pan doesn't think "ah, my energy is collapsing on schedule." He thinks "this idea wasn't that good anyway." The Almost-Shipper at 85% doesn't think "I'm about to abandon at the exact point I always do." He thinks "I'll come back to the deploy stuff next weekend."

The failure mode disguises itself as a reasonable decision every single time. That's what makes it a pattern and not a choice.

You can't read the label from inside the jar. Which is the whole reason a community or a dashboard doesn't fix it — a community is not accountability, and a dashboard is not accountability. They show you activity. They don't tell you which trap you're walking into.

I built a thing that names yours

So I built a free diagnostic. Seven questions, about two minutes, no signup wall to see your result.

It tells you which of the failure modes is yours, why it fires for you specifically, and the one move that breaks it — the thing to do differently at your exact failure point, not generic "stay motivated" advice.

I'm deliberately not writing the full breakdown of each mode here, because the useful part is personal. The Perpetual Planner and the Almost-Shipper need almost opposite advice. A post can't give you the right one. Seven questions about how you actually behave can.

It's free, it's fast, and you'll recognize yourself by question three.

If a side project of yours has died the same way more than once, that's the pattern talking. Find out which one is yours: mvpbuilder.io/ship-readiness?utm_source=indiehackers&utm_medium=social&utm_campaign=ship-readiness&utm_content=failure-modes

Day 128 building in public.