MVP Builder

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 solo dev 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 that names where you stop: mvpbuilder.io/ship-readiness?utm_source=indiehackers&utm_medium=social&utm_campaign=ship-readiness&utm_content=ship26&lang=en

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 that names where you stop: mvpbuilder.io/ship-readiness?utm_source=indiehackers&utm_medium=social&utm_campaign=ship-readiness&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.

You have a million free consultants on call. They write code, draft the schema, scaffold the auth, explain the error. The single most capable building tool humans have ever made is open in another tab right now.

And the side project is still 80% done. Like it was last month.

This isn't a motivation problem. It's a usage problem — and a former Google executive named it better than I can.

The biggest waste of compute

Mo Gawdat — the former Chief Business Officer of Google X, author of Solve for Happy — put it bluntly in a recent interview: the biggest waste of compute today is that we hand people the ultimate form of intelligence and they use it to write a text message to their girlfriend.

For developers the version is more specific. You have a tool that can take a half-built project to the finish line. You use it to generate one more plan. To refactor a file you'll abandon. To ask a question whose answer you already half-knew.

The capability is enormous. The use is shallow. And shallow use of an enormous tool feels productive — that's the trap. You closed the tab feeling like you worked. Nothing shipped.

Don't use AI as a lazy person

Gawdat's actual prescription is the part worth tattooing on the monitor: "You have to learn to use AI not as a lazy person. Don't have them do things for you. Have them make you smarter. Instead of trying to get the same task done with one prompt, try to get a much more interesting and demanding and intelligent task done with more work."

Read that as two different developers.

Developer A prompts "build me the dashboard," pastes the output, hits an error, and quietly stops. One prompt. Lazy use. The tool did a thing for them and they were no further along.

Developer B uses the same model to interrogate the actual blocker — why does the deploy fail, what's the real data model, what's the smallest thing that gets a working flow in front of one user. More demanding task. More work. They're closer to shipping.

Same tool. Same tokens. Completely different outcome. The difference isn't the AI. It's whether a human is driving it hard or coasting on it.

The tool is just the tool

Alex Bouzari, CEO of the AI-infrastructure company DDN, said the quiet part: "AI tools will code for you. The value you bring is that you think of the problem, you formulate the problem. The tool does not know. It's like a car — the car doesn't tell you where to go. You tell the car."

A car is the most freeing tool imaginable and also completely inert without a destination and someone willing to drive the whole way. Most stalled side projects have a brilliant car idling in the driveway. Nobody decided where it's going, and nobody's committed to staying behind the wheel past Day 4.

More AI was never the missing half

Here's the uncomfortable empirical note. METR measured experienced developers on real tasks in 2025 and found they were 19% slower with AI tools. Not faster. Slower — because shallow, unstructured use adds context-switching and false confidence in "done."

So the fix can't be more AI. Gawdat's own frame is the right one: we're in the era of augmented intelligence — humans and machines together producing what neither produces alone. The machine half is solved. It's abundant, cheap, and getting better weekly.

The half that's missing is the human structure that makes you use the machine deeply and actually finish: a destination, a deadline, and someone who notices when you coast.

What this looks like when it's built in

I run a 30-day sprint for developers with full-time jobs. The daily prompt doesn't say "keep going." It demands one concrete action that day — and the check-in where you report it gets read by a person, not parsed by a bot.

That single constraint kills lazy use. You can't coast through "build me the thing" when tonight you have to write, to an actual human, what you actually moved. And when you go quiet, you get one sentence back: what happened yesterday?

The AI is still doing 90% of the work. The 10% that was missing was never more compute. It was a human in the loop making you spend the compute well.

The question worth asking

Open your repo. Count the AI-generated plans, scaffolds, and half-built features sitting in there. Now count how many became something a real person used.

That gap is the waste of compute. Not the tokens. The shipped project that's still imaginary because the most powerful tool in history got used to almost-finish.

The tool isn't the bottleneck. It hasn't been for a while. You are — and that's actually good news, because it's the part you can change this week.

If your project has been "almost done" for three months, more AI won't move it. A deadline and a human reading your daily check-in might.

Cohort #2 is open: mvpbuilder.io/pipeline?utm_source=indiehackers&utm_medium=post&utm_campaign=cohort2&utm_content=waste-of-compute

Day 120 building in public.

Find an accountability partner. Join a community. Post your build log in public. Tweet your progress.

It's the standard advice for shipping a side project. It's good advice. It mostly doesn't work.

Here's the part nobody mentions.

Community accountability is ambient

In a Discord server, someone might see your update. Someone might comment. If you go quiet for a week, the thread moves on without you.

Nobody is assigned to you. Nobody has read your sprint goal, your stack, your Day 3. So nobody can say anything meaningful about your Day 7.

The community isn't failing you. It's doing exactly what it's built to do: surface content from the people who are posting. It has no mechanism for noticing the people who stopped.

If you went quiet today, who would email you tomorrow? In most communities the honest answer is: no one. The thread just keeps scrolling.

One reader with full context is a different thing

Not different in degree. Different in kind.

When one specific person reads every check-in — not a summary, not a digest, the actual words you typed at 6:47am before standup — something shifts. That person has your full context. What you said you'd build. What you actually built. Where the gap is.

And when you go quiet, that person reaches out. Not an automated sequence. An email that says: "Nothing from you yesterday. What happened?"

You can ignore a notification. You don't want to waste a human's time.

That's the mechanism. Gouldner named it the reciprocity norm in 1960: when someone invests attention in you specifically, you feel an obligation that diffuse social pressure never creates.

Developers already know this distinction

A linter finds errors. A person decides if it's good enough.

The linter doesn't care that you cut corners because you were tired at 11pm. The person does. The linter runs the same check every time. The person remembers what you said last week.

Code review from a human changes how you write code — not because the feedback is different, but because the reader is real.

A thousand community members don't create that. Not because they don't care. Because none of them are assigned to you.

The research is specific about the word "human"

In 2015, Gail Matthews tracked 267 professionals. One group wrote down their goals. Another group wrote them down and sent weekly progress reports to a real person.

The second group completed 76% more of their goals.

Read the method carefully. Not a community. Not a public post. Not a follower count. A human who would actually read the report. The variable that moved the outcome was a single reader who was paying attention.

That's the part the "build in public" advice quietly drops.

What it looks like when someone is actually reading

I run a 30-day sprint for developers with full-time jobs. I read every check-in. Not a dashboard summary — the actual text.

When someone writes two sentences on Day 4, I notice. When someone writes two paragraphs about being stuck on a specific integration, the next day's prompt reflects that — not a generic "keep going." When someone goes quiet, I send one sentence. Not automated.

The check-in isn't logged for a metric. It's read by a person. That's the whole difference, and it's smaller and less glamorous than "community" — which is exactly why it works.

The question worth asking

When you post a build log in a Discord server, does anyone there know what your Day 1 looked like? Do they know why you chose that stack? Would anyone notice if you disappeared on Day 12?

That's not a knock on communities. They're genuinely useful — for feedback, for motivation, for not feeling alone.

But finishing a specific project in a fixed window isn't what they're built for. For that you need one person who is already reading — before you post, before you ask, before you decide whether today's progress is even worth sharing.

Not a bigger audience. One reader.

If you've been the only person watching your own progress, that might be why the project that's "almost done" has been almost done for three months.

Cohort #2 is open: mvpbuilder.io/pipeline?utm_source=indiehackers&utm_medium=post&utm_campaign=cohort2&utm_content=one-reader

Day 116 building in public.