DEV Community: MVPBuilder_io

I diffed my product against its own terms of service and found fifteen contradictions

MVPBuilder_io — Fri, 28 Aug 2026 03:39:07 +0000

One day in August I stopped reading my code and started reading my terms of service. Not as a contract, but as a specification: every sentence in it that describes behaviour is a claim about the software. Fifteen of them did not hold.

Day 7

On day 7 the dashboard required proof of work. My own terms describe the check-in on that day as voluntary.

So anyone who had read the contract and believed it would have uploaded nothing — and walked straight into the consequence designed for people who do nothing at all. The product would have punished someone for trusting a commitment I made.

Nobody was affected. As of August 2026 no paying customer has ever started a sprint in this product, and there is no testimonial. That is not an excuse — it is the reason any of this can be written down. All fifteen findings hit nobody, because nobody is in there yet. There is no better moment coming.

Why I looked

This was not a code review. I suspected my external communication and my product had drifted apart, and I wanted to know by how much. So I took the only text that is legally binding and treated it as a requirements list.

Four steps, short enough to copy:

Read the terms and the privacy policy as a specification, not as legalese. Mark every sentence that makes a statement about behaviour — "X is recommended but not mandatory", "a suspension occurs when …", "we typically reply within …".
For each marked sentence, find the place in the product that executes it. Not the place that mentions it — the place that enforces it.
Search for those same sentences across everything customer-facing: landing page, FAQ, checkout, emails, the machine-readable surfaces. A sentence rarely exists once.
For every finding, record the direction: does the code deviate in the user's favour or against them?

Step 4 is the one I almost skipped, and it is the most important. It separates a legal problem from a fairness problem — and it explains why half of the findings survived as long as they did.

Three classes, not a bug list

Class 1 — the contract says A, the code does B

Day 7 belongs here. So does a second case: the product suspended a participant after two skipped days, and my contract did not provide for that — it enumerates the grounds for suspension exhaustively, and this one was not among them.

That is explicitly not a liability finding, and the entire difference is the direction: the code was stricter than the contract. The dangerous case is the mirror image — a contract promising something the software does not deliver. Same size of deviation, two completely different consequences.

Class 2 — the marketing says A, the contract says B

The leading example: in four places I advertised a response time that was shorter than the one I had contractually committed to. Nobody complains about a promise that is too generous. The error is silent by construction — there is no complainant for an oversized promise, right up until the one day you fail to keep it.

I cannot quote that sentence here. It now sits on a blocklist that runs across the repository on every build. I tried while writing, and the check went red. That is not a mishap, it is the intended behaviour, and it is the most honest evidence I can offer for the rest of this post.

The same class holds the sentence I liked least. In six places it said the participant receives a personal email. What went out was a template. The sentence was not a lie when it was written — it became one the moment I automated the sending. There were exactly two honest resolutions: write the email by hand, or stop promising it. Today the sentence appears in none of those six places.

Class 3 — statements nothing can structurally contradict

Two code paths could never fire. Not broken — unreachable. No test went red, because no test exists that asserts "this line is ever reached". No error was raised, because a path that never runs never fails.

This is the expensive class. It is indistinguishable from working software using every tool I have. I found neither by reading; I found them by running the whole chain end to end, once.

Fifteen

I found eleven instances by hand that working day. Three more turned up while proofreading the list — that is, inside the document I had created in order to close the matter. At fourteen I considered it complete.

That same evening I built a check that fails the build when a retired sentence reappears, and ran it for the first time. It immediately reported a fifteenth occurrence — same class, same wording, in a file neither I nor the proofreading pass had looked at.

Fifteen is not a decay rate. It is what a first measurement looks like. Fifteen instances of one class, in a product with no paying sprint behind it, all corrected the same day and verifiable. And the last of them was found not by me but by the first tool capable of looking for it. If you run this yourself and come out at zero, you probably did not measure — you confirmed.

The pattern

A comment has no assertion. A README has no CI. Your terms of service are a test suite nobody runs.

That is the actual discovery, and it is not that fifteen statements were wrong. It is that in a product like this two specifications exist and only one of them is tested — and the untestable one is the one that binds. The code has tests, linters, types, a pipeline and a reviewer. The text that governs in a dispute has none of it. It has an author and a date.

So the class does not come from carelessness. It comes from the same rule existing in four, six, eleven places, and none of them stating how many there are. Every change is an n-place operation with an unknown n. Someone changing a number from 24 to 48 is not asking a positioning question — so they do not ask anyone.

Two findings, then onward

Kleven et al. (2011) ran a randomised audit experiment with more than 40,000 Danish taxpayers. Evasion was close to zero on third-party-reported income and substantial on self-reported income. Same people, same incentives; the only difference is whether somebody else reports the figure. Scheel, Schijen and Lakens (2021) compared 152 standard psychology studies with 71 Registered Reports: 96 per cent positive results against 44. Once the hypothesis is fixed before the result — once it can fail — the success rate halves.

Both describe the same property, once in money and once in science: a statement that nothing can contradict stops behaving like a statement. Documentation is self-reported by default. That is not a question of character — it is a property of the reporting arrangement.

What I actually changed

The check is deliberately small — a gate that mostly reports noise gets ignored within two weeks. It checks wording, not correctness. It knows strings, not meaning, so it cannot tell a claim from its negation. And absence is invisible to it: a promise that quietly disappears produces no match. Of my fifteen cases it would have caught roughly a third — the cheap ones. One of them it actually did catch, on its very first run. It would have let the four most expensive ones through.

Which is the honest limit of the whole exercise. The expensive class needed a dry run of the entire chain, and a dry run is manual work you do once per chain, not once per day.

The twenty-minute version

Take the longest document that describes your product and is not code: terms, README, landing page, onboarding email. Mark every sentence that makes a statement about how your software behaves. Take three of them and find the place that executes them. Record the direction for each.

And the condition without which the rest is worthless: write down beforehand which claim you are checking and what result would refute your assumption. Otherwise you will end up confirming what you expected — that is the distance between 96 and 44 per cent, and it does not come from dishonesty.

Which fixes my next check, and it can go wrong: in a few weeks I will look at whether the fifteen corrected sentences still hold. If more than two of them have drifted again, then the build check was the wrong answer — the problem would be the number of places rather than the supervision of them, and the correct response would be to delete carriers instead of monitoring them.

Disclosure, so it isn't buried: I build a product in this space, so I'm not neutral on the conclusion. What I can evidence is a self-test — I ran my own 21-day sprint as a participant with the goal frozen before day one, and missed one of four criteria. What I can't evidence is that it works for anyone else: no paying customer has completed a sprint and there's no testimonial. The two studies above are neutral.

Longer version with the full source list on my own site: mvpbuilder.io/blog/terms-of-service-test-suite

Paul Graham's "launch fast" is half a sentence — the other half is in a different essay

MVPBuilder_io — Mon, 17 Aug 2026 09:47:33 +0000

Almost everyone knows the advice: launch fast. Far fewer know the reason Paul Graham actually gave for it — partly because it sits in a different essay than the famous instruction.

The half nobody quotes

"Launch fast" appears in Startups in 13 Sentences. The justification there is about learning: you haven't really started working on the thing until it's out.

Nearly three years earlier, in The Hardest Lessons for Startups to Learn (April 2006), Graham wrote something else:

"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."

Read the last sentence again. He isn't saying people postpone out of perfectionism. He's saying they postpone because they know what comes after.

That's not a question of ability. It's a question of obligation.

What changed in twenty years, and what didn't

When Graham wrote that, building was expensive. A first working version cost weeks. Today a functioning skeleton exists in an afternoon, with a model writing most of the code.

So one half of the problem is solved — the half Graham wasn't talking about. The other half got bigger.

When building gets cheap, the bottleneck moves backwards: to the moment an intriguing problem becomes an alarming one. No model takes that moment off your hands. An agent can write your code. It cannot get nervous on your behalf when something is broken.

Faster building doesn't produce more finished things. It produces more half-finished ones.

The same finding, three floors up

In 2026 the vendor 8090.ai published a piece on what separates a "software factory" from a tool. Under the heading The five tests it lists five criteria. The fifth is accountability:

"When the billing engine miscalculates a claim, when the trading system produces a wrong number, when the manufacturing validation approves a bad part, someone specific answers for it, fixes it and eats the cost."

The article explicitly names the standard contractual alternative — that "the output is provided as-is and verification is your problem" — and calls it disqualifying.

That's Graham's observation in enterprise language. Graham: responsibility creates pressure, and the pressure is why people postpone. 8090: a system with nobody answerable produces output but not outcomes.

Same dividing line. It doesn't run between well-built and badly built tools. It runs between something that outputs and someone who is answerable.

Where this lands if you're one person

You have no factory and no vendor who is answerable. You have a repo, an evening, and a project that's been at eighty percent for eight months.

The enterprise question is "who takes the call when it breaks in production." Yours is:

Who notices if I skip day 4?

Usually nobody. No colleague, no standup, no deadline that affects anyone else. Which makes postponing rational — it costs nothing.

A tool doesn't change that. It can suggest tasks, show progress, send reminders. What it cannot do is be part of an obligation. A reminder from a system that gives up nothing isn't an obligation. It's a notification.

What follows

If Graham's diagnosis holds and 8090's test holds, the missing piece for an individual isn't better planning or a better model. It's an addressee: someone who reads what you delivered, notices when nothing arrives, and to whom it makes a difference.

That's inconvenient for both sides. The obligation exists precisely because someone on the other end spends time — and time doesn't duplicate the way software does. I'm not claiming that's a durable advantage. It's a scarcity, and scarcities sometimes disappear. How long this one lasts, I don't know.

"Launch fast," says Graham — and means: make sure postponing costs you something. That's the half of the sentence almost everyone leaves out.

Disclosure: I build a product that supplies exactly this addressee, so I have an interest in this argument. What I can evidence is a self-test — I ran my own 21-day sprint as a participant with the goal frozen before day one, and missed one of four criteria. What I can't evidence is that it works for anyone else: as of August 2026 no paying customer has completed a sprint and there's no testimonial.

Sources: Paul Graham, The Hardest Lessons for Startups to Learn (April 2006, section "Release Early") · 8090.ai, What Is a Software Factory? (section "The five tests"). Both retrieved 17 August 2026. Note: the Graham passage is frequently misattributed to "Startups in 13 Sentences", which contains the instruction but not this argument.

I ran my own 21-day sprint and missed one of four goals

MVPBuilder_io — Sat, 01 Aug 2026 16:36:13 +0000

I build a product that's supposed to get developers to finish their side projects. In July I went through it myself, as a participant, for 21 days.

I missed one of four goal criteria.

The obvious move is not to write about that. An accountability product whose founder falls short of their own goal is not a good sales story. But the miss is the part that demonstrates something — and the success report would have been the part that demonstrates nothing.

What has to be said first

This was a self-test, not a customer outcome. I was operator and participant at the same time. Nobody paid for it. There is no testimonial, and as of today no paying customer has completed a full sprint.

Reading this as proof that the product works overstates it. What it does establish is narrower: that the mechanism runs end to end under real use rather than merely passing in staging — and that running it surfaces things no test had found.

The goal was fixed before day one

The sprint goal gets written during the intro call and stored at acceptance. After that it can only be corrected downward, never upward. Every milestone review measures against that stored wording — not against a later summary of it, and not against whatever has since become convenient.

My goal had four checkable criteria. On day 21 I assessed each one separately against the stored text:

Public landing page with intake in both directions, two languages — met.
At least 15 candidates contacted with an internal scoring sheet — met, 16.
At least 3 completed reciprocal feedback exchanges, each within 48 hours — missed: 2 of 3.
Willingness-to-pay question asked for real — met, with a disclosed limitation.

Why the third exchange never happened

Two completed fully. In both cases I went first — delivered before receiving — and in both cases the return came back without me chasing it. Once the same day, once three days later.

The third contact didn't respond to the initial approach, and didn't respond to a follow-up either. That closed it under my own rule: one follow-up per contact, then never again. A second nudge might have saved the criterion and would have broken the rule.

I kept the rule and missed the criterion. That's a description, not an excuse: the miss follows from a rule deliberately honoured, and it's still a miss. That's exactly how it appears in the proof I submitted — not as "substantially met."

Which is the only reason this piece exists:

A frozen goal is worth precisely what it costs to miss it.

Had I rounded two of three up to a checkmark, I'd have proved that the enforcement is decoration.

The fourth criterion was the more uncomfortable one

Criterion 4 required the willingness-to-pay question to be asked for real — explicitly accepting "a paying yes or a documented honest no."

What came out was a no by null signal: the question was never put to a person, because nobody appeared to whom my own rules allowed it to be put. The option sat passively in the intake form from day 16. Response: zero.

By the wording of the goal, that's a pass. Honestly assessed, it's weaker evidence than an offer made and declined. Willingness to pay is therefore neither established nor refuted — it wasn't tested. That's what the proof says, instead of recording a clean checkmark.

What using it found that testing did not

The unexpected return wasn't in the sprint result but in the product itself. As a participant inside your own system you see things an operator never sees:

Three faults in the system that generates and sends the daily prompts. They surfaced at the end of a sprint — a place nobody had simply ever reached before.
A data-protection defect that had been live for about three and a half months. Found on the first real form run by an outsider, not by an audit.
A qualification requirement only the wrong people got to see. It appeared at exactly one point in the funnel — visible only to those who had already disqualified themselves. Anyone who needed to read it never passed it.

That last one is the one I keep coming back to. A filter that only reaches people who have already identified themselves isn't filtering. While you're building it, though, it feels exactly like one that does.

None of the three would have been caught by a test. All three came from use, and from someone else's eyes.

What I take from it

The most useful finding has nothing to do with the goal: both exchanges that happened came inbound, from a single public post, and both through going first. Cold outreach to more than a dozen candidates stayed silent. I wrote it down as "going first converts existing interest, it doesn't create any."

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 — the same move as rounding 2 of 3 up to a checkmark, just pointing the other way.

Where this actually stands

One completed sprint, run by the founder. No paying customer who has completed one. No testimonial. Willingness to pay untested.

That's the honest position. The full write-up, including the day-by-day log with the finding of each day, is here — including the days where the finding was that waiting looks like work.

The lab shipping 8x more code just told you what's still on you

MVPBuilder_io — Thu, 09 Jul 2026 04:54:11 +0000

Anthropic put out a piece recently about how fast their own engineers are moving now. The numbers are the kind that used to sound like marketing: task-completion capability roughly doubling every four months. Over 80% of the code merged into their own production systems is now written by their own model — up from single digits a year ago. Engineers shipping 8x more per quarter than 2024.

Read that twice. That's not a vendor claiming their tool is fast. That's the company that builds the model, talking about its own team.

So naturally the next thought is: if the people building the thing are moving 8x faster, what's left for the rest of us to do?

Here's where it gets interesting, because there's a study that says almost the opposite. METR — an independent group that actually measured developers working with AI tools on real repos, not self-reported — found they were 19% slower, not faster. Same year, same technology, opposite result.

Both are true. They're just measuring different things. METR measured individual developers, mostly without a deliberate process wrapped around the AI's output. Anthropic's number comes from an organization that built code review, merge gates, and engineering ownership around the model before they ever let the 8x happen. The speedup didn't come from the model alone. It came from a human-governed process deciding what gets shipped and what gets sent back — the model just got faster inside that structure.

That's the part that doesn't make it into the "AI writes code now" headlines: the acceleration only shows up where a human is still the one closing the loop.

One line from the same piece, from someone inside Anthropic, on a day the automation was working almost too well: "On days where everything works well, I can't help but think nothing I do matters, everything is automated."

That's a real thing to feel, and it's worth sitting with for a second — because it's the wrong conclusion. The same piece answers it a few paragraphs later, more carefully: "The comparative advantage of humans as of right now is still in seeing the bigger picture."

Not writing the code. Not reviewing every line. Seeing the bigger picture — deciding what's worth building, when it's actually done, and whether to ship it.

That's the exact shape of the gap I keep running into with side projects. The build stopped being the hard part a while ago. Nobody's stuck because the code doesn't compile. People get stuck holding a working app at 80%, because the last 20% — deciding it's real, closing the loop, actually going live — was never a capability problem to begin with. It's a "who's accountable for finishing this" problem, and a faster model doesn't touch that.

Anthropic's own numbers are proof of the same pattern at a much bigger scale: the speed comes from the model, but the bigger picture — what ships, what doesn't — still needs a human holding it. AI tracks. A human reads.

If you've got something sitting at 80% right now: mvpbuilder.io.

"It works" is the most expensive lie in vibe-coding

MVPBuilder_io — Thu, 02 Jul 2026 03:40:56 +0000

Someone posted a teardown of 100+ AI-built SaaS repos this week — Next.js, Supabase, Stripe, all the fast-build stacks. The finding: the apps ran, the UIs looked fine, the builds passed, and almost none were actually safe to put in front of a stranger.

Everyone read it as a security post. I think it's a finishing post wearing a security costume.

Here's the thing the teardown accidentally proves: AI gets you to a running app in days. That's the 80%. It compiles, the demo works, the screenshot looks shippable — and that is precisely the moment your brain files the project under "done." The dopamine arrives before the product does.

The last 20% is a different kind of work. It isn't "make it exist." It's "make it hold up when someone who isn't you touches it." Whatever your version of that is — going live properly, closing the loops, the unglamorous grind — it has no happy path, no applause, and it happens after hours, alone, when the excitement that carried the first 80% is long gone.

That gap is not a tooling problem. This is the part people keep getting wrong. They reach for a better model, a new framework, another AI tool — as if the thing standing between them and a shipped product is capability. It isn't. The build already exists. What's missing is follow-through, and no tool has ever noticed that you stopped one commit short of the line.

"It works" tells you the happy path passed. "It's shipped" tells you that you did the 20% that had no happy path. Those are different claims, and the distance between them is where roughly nine out of ten of these projects quietly die.

I'm building in that gap on purpose — not another tool that watches your repo, but the human layer that notices when you're about to walk away at 80%. AI tracks. A human reads.

If you've got something sitting at 80% right now that you keep meaning to finish: that's not a personal failing. It's the single most predictable place to get stuck in 2026 — and the only place actually worth pushing through.

That last part is what I'm building: mvpbuilder.io.

AI Didn't Remove Your Bottleneck. It Moved It.

MVPBuilder_io — Tue, 30 Jun 2026 04:14:59 +0000

I have a folder. You probably have one too.

Mine is full of repos that got to about 80%. Auth works. The core loop works. There's a deploy somewhere with a real URL. And then — nothing. No launch, no users, no Stripe key in prod. Just a project that was almost a thing, sitting next to four others that were also almost things.

For years I told myself the reason was time, or skill, or that the stack was fighting me. Then AI showed up and quietly removed all three excuses at once. And the folder kept growing.

That's the part nobody talks about. So let me reframe the question most developers are circling right now.

The wrong question

The anxious version going around is "Is AI making me obsolete?" It's the wrong question, and it's wrong in a way that hides something more useful.

The real question — the one that actually stings if you sit with it — is:

Why am I not finishing anything, now that building got easy?

If building were still the hard part, an unfinished project would be a capacity problem. You'd just need more hours, more talent, a better framework. But building isn't the hard part anymore. You can scaffold a working app in an afternoon. And the unfinished folder is still there. So the bottleneck was never really the building. We just couldn't see past it.

Goldratt saw this in a factory in 1984

Eliyahu Goldratt's Theory of Constraints makes one stubborn claim: any system has exactly one bottleneck that limits its throughput. Not five. One. Everything upstream and downstream of it is, in a sense, noise. You can optimize the non-bottlenecks all day and your output won't move.

The non-obvious second half: when you finally lift that constraint, it doesn't vanish — it relocates. Throughput rises until something else becomes the new ceiling. There is always a constraint. The work is figuring out where it just moved to.

For most of us building software, "writing the code" was the constraint for a long time. It was slow, it was where we got stuck, it was the part that needed skill and patience. AI lifted that ceiling. Generously. And exactly as Goldratt would predict, throughput on building shot up — while the constraint quietly slid one station down the line.

It landed on follow-through.

The thing limiting whether you have a shipped product is no longer your ability to produce code. It's your ability to keep showing up to the same project on day 9, day 14, day 22 — past the dopamine of the first working demo, through the unglamorous middle where you wire up error states and write the boring copy and actually put it in front of someone.

That constraint is not technical. It's behavioral. And here's the uncomfortable consequence: no tool can lift it the way AI lifted the last one. A better model, a slicker agent, a sharper IDE — they all operate on the station that's no longer the bottleneck. They make you faster at the thing that was never the problem.

Better build tools make the gap wider

This is the part that catches people off guard.

The instinct is: agentic coding, AI pair-programmers, one-shot app generators — surely these help with finishing? They don't. They widen the distance between "built" and "done."

Think about it through the constraint lens. If you 10x the output of a non-bottleneck station, you don't increase the throughput of the system — you increase the pile of work-in-progress stacking up in front of the actual bottleneck. More half-built things. More 80%-done repos. A faster builder, pointed at an unmoved finishing constraint, just generates a larger graveyard, faster.

So every leap in build tooling doesn't shrink the finishing problem. It makes it more visible and more urgent. The gap between people who have something and people who have nothing isn't a building gap anymore. Building is table stakes. The gap is finishing.

Which means finishing isn't a chore you do after the differentiation. Finishing IS the differentiation. It's the one part of the pipeline that didn't get commoditized this cycle.

AI makes you a builder. The work makes you a finisher.

I've started thinking about it as two identities.

AI is extraordinary at turning you into a builder. It compresses the distance from idea to running code into almost nothing. That's real and I'm grateful for it.

But it has no opinion about whether you ever cross the line. It will happily help you start your sixth project while five sit unfinished. It tracks nothing, notices nothing, cares about nothing. AI tracks; a human reads. The shift from builder to finisher happens somewhere it can't reach — in the boring, repeated, slightly-uncomfortable act of returning to the same unfinished thing until it's actually out.

I saw this framed on a stage in Berlin recently — same idea, scaled up to a whole engineering org:

The org-scale version asks where the human checkpoints go. The solo-dev version is the same question, smaller: the checkpoint that decides whether you finish isn't a code review — it's whether anyone notices you stopped.

Naval has a line: work like a lion, not like a cow. Lions sprint, rest, and complete the hunt. Cows graze continuously and finish nothing in particular. Most of us, with AI, have become extremely productive cows. Always grazing on new builds. Rarely completing the hunt.

The honest ending

I don't have a clean fix to sell you here. I'm a solo dev with a full-time job, building in public, and I'm writing this partly to myself — because the folder is real and the pattern is mine before it's anyone else's.

But the reframe changed how I work, and it might change how you read your own unfinished folder. Stop asking whether AI makes you obsolete. Ask where your bottleneck moved. For almost everyone reading this, it moved to the same place: the finish.

Optimize the right station. Everything else is just a faster way to not be done.

(If the "structured finishing" problem is one you're actively wrestling with, I'm building toward it in the open at mvpbuilder.io — but the idea above stands on its own whether or not you ever click it.)

Everyone at Ship 26 Was Shipping Agents. The Slide That Stuck With Me Was a Flat Line.

MVPBuilder_io — Fri, 26 Jun 2026 07:26:25 +0000

I Went to Ship 26. Everyone's Shipping Agents. Nobody's Shipping the One Thing That Matters.

I spent the afternoon/evening at Vercel's Ship 26 in Berlin — a dark auditorium, a couple hundred developers, and a row of slides everyone in the room was photographing at the same time. The whole event is one message, repeated from a dozen angles: software is agentic now. Agents deploy. Agents build agents. Agents watch production and roll themselves back.

And the numbers back it up. Vercel said over half of all deployments on their platform now come from coding agents — up from under 3% six months ago, a 17x jump. AI Gateway traffic went from 2 trillion to 20 trillion tokens a month. One talk put the same point a different way: ~60% of enterprise merged commits are now written by agents. This isn't a forecast. It's already the baseline.

I came away convinced of the trend. I also came away convinced almost everyone is reading it backwards.

The slide I can't stop thinking about

It wasn't on the keynote stage. It was in one of the engineering talks, and it was an honest one. A team put up their own internal data on rolling out AI coding tools. The capability line went straight up — exactly what you'd expect.

The results line didn't.

It rose a little, then flattened out and stalled around a 40% productivity gain. They'd labeled the curve themselves, on their own slide, in big letters: "THE PLATEAU." Next to it, a faint dotted line showed where they'd be if it scaled linearly — way up and to the right. The gap between those two lines — capability racing ahead, outcomes flattening — is, more or less, the entire business I'm building.

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

The most human thing said all day

Here's the line from the keynote that stuck with me. Vercel's CEO, talking about all these agents companies are rushing to build:

"Agents are free. Free as in free puppies. Everybody loves puppies. But they pee on your floor. They eat your furniture… agents are software, and we all know that software is never done. Someone has to maintain them."

Read that again at an event whose entire theme is autonomy. The headline is "agents do the work now." The fine print, said out loud on stage, is: someone still has to finish and own the thing.

And it wasn't a one-off. Their whole agent stack is built around a human gate. The Workflow SDK pauses when the job needs human input. Their production agent will investigate an incident on its own — and then "anything that changes production state waits for a human to approve it." Another talk reframed the entire job of an engineer: the question, the slide said, is no longer "how do we help engineers code faster?" — it's "what human-review artifacts do we still need, and how do agents prepare them, so humans operate at the right checkpoints?"

The most advanced agent tooling in the room is architected around the assumption that a human stays in the loop. That's not a footnote. That's the actual shape of the thing.

Here's the part that doesn't sell infrastructure.

When agents write half your code, building stops being the hard part. And a bottleneck doesn't disappear when you remove it — it moves up a layer. It moves to the part agents can't do for you: finishing. Owning it. Showing up on Day 4 when the novelty's gone, the deploy is boring, and nobody's watching.

The faster building gets, the more half-done projects pile up. The graveyard of "90% done, runs on my machine, never shipped" is bigger this year than last — not smaller. More capability, same completion gap. That plateau slide was about a funded engineering org with accountability built in. Now picture a solo dev, alone, on a side project, with none of it.

A conference full of developers who can now build anything in a weekend is, quietly, a room full of people who are about to have more unfinished projects than ever.

Why "the build is easy now" is the trap, not the win

The thing nobody's shipping

So here's the honest takeaway from an evening surrounded by autonomous everything:

Vercel keeps a human in the loop on production. Almost nobody keeps a human in the loop on themselves.

You'll wire up approval gates, scoped permissions, and rollback safety for your agents. Then you'll start a side project alone, with zero gates, no one expecting the next step, and act surprised when it dies at 85% like the last three did.

AI tracks. A human reads. A dashboard shows you activity; it doesn't notice your absence. The accountability layer — the human who reads and names the move you're avoiding — is the one part of this whole stack that nobody can deploy for you. And it's the part that decides whether anything you build with all this new power actually ships.

The honest next step

If your projects keep dying at the same point — usually your point — more agents won't fix it. Knowing where your loop breaks might.

I built a free diagnostic for exactly that. Seven questions, two minutes, no signup to see the result. It names where you stop and the one move that breaks it.

Everyone left Ship 26 ready to build faster. The harder, more valuable question is whether you'll finish. Find out where your loop breaks: mvpbuilder.io/ship-readiness
*Building in public. Day 131

I Built a Harness for My AI Agent. Then I Realized I Needed One for Myself.

MVPBuilder_io — Sat, 20 Jun 2026 15:14:38 +0000

My agent shipped 12 clean PRs in a weekend.

The product still isn't live three weeks later.

The harness around the model worked. The harness around me didn't exist. And I think that's the actual story of agentic coding in 2026 — not that the model can't build, but that nothing is holding you to finishing what it builds.

What a harness actually is

If you've done serious agentic coding, you already know the model alone is useless. A raw LLM is a horse with no harness — wild power, pointed nowhere. The harness is everything you wrap around it: scoped tasks, clean context, spec-driven loops, the discipline to not let it run wild. That's what turns a model into an agent that actually does work.

Andrej Karpathy put the failure mode precisely: your agent doesn't get dumb because the model is bad. It gets dumb because you feed it too much, too old, or the wrong thing to read. So you engineer the context. You curate what it sees. You stay in control instead of vibing.

This is real craft, and it works. I got good at it. I can keep an agent on rails for hours.

Here's what nobody told me: I built all of that discipline for the machine, and exactly none of it for myself.

The harness that doesn't exist

The model has a context window I carefully manage. I have a context window too, and on Day 4 of a side project it fills up with my day job, a flaky deploy, and a vague sense that "this idea wasn't that good anyway." Nobody scopes that down. Nobody notices when I go quiet.

The agent has a loop that checks its own output. I have no loop. When I stop, nothing fires. The PRs just sit there, 90% of a product, on a branch the world will never see.

This is the part of software that AI made worse, not better. METR measured experienced developers on real tasks in 2025 and found them 19% slower with AI tools (arxiv.org/abs/2507.09089) — because AI eats the easy, satisfying parts and leaves you alone at the hard, boring, project-killing part. The agent will give you the plan and the diff. It will not notice when you skip Day 4.

The build getting easier is the trap

Karpathy also called this the decade of agents, not the year — we're closer to the start of that curve than the end of it. And here's the uncomfortable second-order effect: as agentic tools get better, the build collapses to almost nothing. Ninety percent of a product in a weekend is now normal.

Which means the bottleneck didn't disappear. It moved one layer up.

When building was the hard part, "not finished" meant "not built." Now the thing is built — it runs on your machine — and it still isn't shipped. Faster building was supposed to mean more shipping. Instead it just produced a bigger graveyard of almost-done. More half-finished repos, not fewer. The completion gap is widening, and it's widening fastest for the people who got good at agentic coding.

What a harness for a human is — and isn't

So what do you wrap around yourself?

Not a dashboard. A dashboard shows you activity; it doesn't notice your absence. A streak counter is just a nicer way to watch yourself quit. A community isn't it either — an audience claps when you post and says nothing when you disappear for two weeks. A dashboard is not accountability. A community is not accountability.

The thing that actually works is embarrassingly old: someone who reads. Not software that tracks you — a human who notices when you go quiet and names the move you're avoiding. AI tracks. A human reads. The whole point of a harness is that it acts on the thing it's wrapped around the moment it drifts. For the model, that's context engineering. For you, that's another person with a reason to expect the next step.

You already accept this for your agent. You'd never ship an autonomous loop with no checks and just hope it stays on task. You do exactly that to yourself every time you start a side project alone.

The honest next step

If your projects keep dying at the same point — and it's usually the same point, your point — the useful thing isn't more motivation. It's figuring out where your loop actually breaks.

I built a free diagnostic for exactly that. Seven questions, about two minutes, no signup to see the result. It names where you stop and the one move that breaks it.

You can engineer a perfect harness for the model and still ship nothing. Find out where your own loop breaks: mvpbuilder.io/ship-readiness

Building in public. Day 125.

There Are Only 5 Ways a Dev Abandons a Side Project. You Reliably Repeat One.

MVPBuilder_io — Sun, 14 Jun 2026 12:34:49 +0000

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? 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 (arxiv.org/abs/2507.09089) — 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

Here's why this is genuinely hard to self-diagnose.

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 blog 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

Building in public. Day 121.

The Biggest Waste of Compute Is the Project You Didn't Ship

MVPBuilder_io — Sun, 07 Jun 2026 08:44:35 +0000

You're Using the Most Powerful Tool in History to Almost-Finish

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. So don't have them do things for you. Have them make you smarter. So 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 (arxiv.org/abs/2507.09089). 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 — no upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 120.

The Difference Between a Thousand Readers and One

MVPBuilder_io — Tue, 02 Jun 2026 04:29:11 +0000

You Don't Need a Bigger Community. You Need One Person Reading.

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 (doi: 10.2307/2092623): 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. The sprint I built puts a human in that loop — daily check-ins get read, milestones get reviewed by a person, not parsed by a bot.

Cohort #2 is open. No upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 116.

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

MVPBuilder_io — Sat, 30 May 2026 09:21:23 +0000

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

There's a concept in software engineering called Technical Debt. You skip the right abstraction, move fast, ship. Someday you pay it back in refactoring hours.

I've been thinking about a different kind of debt. One that doesn't show up in your codebase.

Human Debt: When you build with AI as your only collaborator, you remove the one thing that makes you feel obligated to show up. Not accountability in the corporate sense — the simpler thing. Someone is reading your work. You don't want to waste their time.

That's not a productivity hack. It's closer to a structural property of how humans behave when observed.

The Research Didn't Start With AI

In 2015, Gail Matthews ran a study on 267 professionals tracking goal completion. One group wrote their goals. Another group wrote their goals and sent weekly progress reports to a real person.

The second group completed 76% more of their goals.

Not 10% more. Not "statistically significant at p<0.05." Seventy-six percent.

The mechanism is what Gouldner called reciprocity norm in 1960 (doi: 10.2307/2092623): when someone gives you their attention, you owe them something back. Not contractually. Biologically. You don't want to disappoint someone who showed up for you. Harkin et al. confirmed this across 138 studies, 19,951 participants — the effect holds across cultures, domains, and formats.

None of this was discovered because of AI. It was hiding in plain sight for 65 years.

AI Has No Concept of Day 14

Here's what changed.

For most of the history of side projects, your "collaborator" was a rubber duck or Stack Overflow. Those tools don't simulate accountability. Nobody was surprised.

Then came AI pair programming. Which is genuinely useful. But it introduced a specific failure mode: you now have a collaborator that responds, scaffolds, and generates — but doesn't notice when you stopped.

AI has no concept of Day 14. It doesn't know that you opened VS Code for 12 minutes on Tuesday and then didn't come back. It doesn't notice the gap between what you said you'd build and what you actually built. It can't tell signal from fabrication in your commit history — METR's 2026 research documents 16% cheating rates on hard long-horizon tasks, where successful agent runs were disqualified after review. The agents reported progress. They hadn't actually made it.

We call this pattern Human Debt.

Every time you replace a human reader with an AI collaborator, you accumulate a small obligation nobody will collect on. The check-ins become optional. The milestones become suggestions. The sprint becomes a folder of half-finished files.

What I Saw With One Developer

I'm not going to dress this up as a validated product claim. It's an n=1 signal with one side of the experiment visible.

I built a 30-day sprint system. One developer went through it — Silver tier, 21 days. He hit Day 13. The milestone was real: a GitHub Pages deploy, KML export for drone mission planning, Litchi-compatible waypoints working. That's not a demo. That's a deployed thing.

Then the sprint went quiet. He stopped logging check-ins. Day 21 didn't happen.

What I noticed: the structure held while someone was reading his check-ins. When he stopped sending them, there was no one to disappoint. The Human Debt became invisible and he stopped collecting on it himself.

I'm not claiming my product fixed the problem or that I cracked accountability. What the data says is narrower: when a human was reading, the developer shipped to a milestone. When the loop closed, the sprint ended.

That's one data point. But it matches 138 studies.

Why "Human Debt" Is the Right Frame

Technical Debt is useful because it names something invisible. Nobody sees the debt accumulating. You only notice it when the system breaks and you spend three days untangling abstractions that should have been written differently in 2019.

Human Debt is the same shape. It accumulates invisibly, in the gap between check-ins you skipped and milestones you moved. You don't notice it until you look up and realize the sprint folder has 47 files and zero shipped features.

The frame matters because it shifts the question from "am I disciplined enough?" to "did I design a loop where someone is reading?" Discipline is a character judgment. Accountability architecture is an engineering question.

Most developers I've talked to treat the absence of accountability as a personal failing. They weren't consistent enough. Didn't wake up early enough. Got distracted. But the 267 people in Matthews' study weren't more disciplined than the control group. They just had someone to report to.

The debt isn't in your character. It's in the system design.

If you're building something right now and you've been the only person watching your own progress, this might be why it's slower than it should be. The sprint system I built puts a human in that loop — daily check-ins get read, milestones get reviewed by a person, not parsed by a bot.

Cohort #2 is open. No upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 113.