DEV Community: MVPBuilder_io

Buildspace shut down. AI got better. Developers are still not shipping.

MVPBuilder_io — Mon, 13 Apr 2026 04:37:33 +0000

In August 2024, Buildspace shut down.

Buildspace wasn't a course. It wasn't an accelerator. It was a structure — a deadline, a cohort, someone watching. Farza called it "a place to build things." What he actually built was external accountability at scale.

When it closed, tens of thousands of developers lost the one thing that had been making them ship.

Then, six months later, every major AI coding tool got dramatically better.

And somehow, developers are still not finishing their side projects.

The explanation nobody wants to hear

In July 2025, METR published a study that should have been a bigger deal.

They measured the productivity of experienced, professional developers on real software tasks — with and without AI tools. The result: developers using AI tools were 19% slower on average. Not junior developers. Not people learning to code. Experienced engineers, on real work.

The immediate reaction was what you'd expect. Denial. "That's not my experience." "The study is flawed." "Wait for better models."

But a follow-up study in February 2026 didn't reverse the finding. It narrowed it — the effect is smaller than originally measured, but still directionally negative for complex tasks.

The uncomfortable explanation isn't that AI tools are bad.

It's that AI tools solved the wrong problem.

The planning problem vs. the execution problem

Every stuck developer I've talked to has the same story. They know what to build. They have a tech stack. They've probably sketched the architecture in a notebook, a Notion doc, or a Claude conversation.

The problem isn't planning. It was never planning.

The problem is the Tuesday at 7pm when you have 45 minutes, you open your IDE, and somehow you end up watching something else entirely. Or you do open the project — and you spend the time refactoring a file you've already refactored twice, because starting the thing you actually need to build is harder than it looks.

AI tools made the planning step faster, cheaper, and more detailed than ever. You can get a full architecture in 10 minutes. A database schema. A component tree. A deployment strategy.

None of that generates your discipline for the next 30 days.

Buildspace understood this. The product wasn't the curriculum. It was the cohort, the checkpoint, and the fact that someone would notice if you disappeared on Day 4.

When Buildspace closed, nobody replaced what it actually was.

What happens without external structure

The research on this goes deeper than the METR study.

Kahneman's Planning Fallacy (1979) shows that humans systematically underestimate how long tasks take — and overestimate their future motivation. This isn't a character flaw. It's how cognition works. You plan from a best-case scenario, then execute in reality.

Solo side projects are a perfect storm for this. No deadline anyone else cares about. No one watching. No consequence for slipping the timeline. The only accountability is self-generated — and self-generated accountability is the weakest kind.

AI tools made this worse, not better. The gap between "I have a plan" and "I shipped" is not a knowledge problem. AI closed the knowledge gap. The execution gap got wider.

What I'm testing

I'm running an experiment on this. It's called MVP Builder.

The idea is simple: a structured 30-day sprint for developers with a full-time job. You apply with your project. You get daily prompts tailored to your stack and where you are in the sprint. And there are milestone checkpoints where someone reviews your progress before you move forward.

Not an AI reviewing it. Me. Because right now, at Cohort #1, the human in the loop is the founder.

That doesn't scale. That's exactly why Cohort #1 is free.

I'm not selling a solution. I'm testing a hypothesis: that what developers with side projects actually need isn't a better plan — it's a system that holds them to the one they already have.

If that resonates: mvpbuilder.io/pipeline. Applications are open. 8 spots. No credit card.

If it doesn't: I'd still genuinely like to know what has worked for you. The comments are the interesting part.

The applicant who didn't reply taught me more than the ones who did.

MVPBuilder_io — Fri, 03 Apr 2026 07:13:21 +0000

Two weeks ago, a developer with a real project applied to MVP Builder's beta cohort.

The project was legitimate. The tech stack was specific. They'd clearly already built something — not just an idea in a Notion doc.

I sent a qualification email. One real question: "Is this ending up at a URL or a local download?"

Silence.

Seven days later I sent a follow-up. One sentence. No pressure, no countdown, just: "Still here if you want to jump in."

More silence.

I closed the spot this week.

The thing I kept almost missing

My first reaction was frustration. I'd spent time on the application, written a personal email, held a spot.

Then I realized: the silence is the answer. And it's probably the most useful data I collected this week.

Here's why.

The entire premise of MVP Builder is that the blocking problem isn't technical ability — it's consistency under no external pressure. Showing up on Day 4 when you don't feel like it. Responding to a daily prompt when work was exhausting. Moving forward when there's no one immediately watching.

A developer who doesn't respond to two emails over two weeks isn't a bad person. But they're showing you exactly what happens when the stakes are low and the friction is minimal. If you don't reply to one email — one, with no deadline — how do you respond to Day 11 when the sprint gets hard?

This is the actual sprint problem. Not the technical parts.

What the selection process is really for

I thought I was running a qualification process to find good projects. Turns out I'm also running a behavioral filter.

The developers who reply quickly, who ask clarifying questions, who tell me their stack without being asked — those are the ones who are already in motion. The sprint doesn't need to create that momentum from scratch. It channels it.

The ones who go quiet aren't necessarily unqualified on paper. But shipping a product requires dozens of decisions under low motivation and zero external accountability. The application process is the smallest version of that test.

A lot of early-stage products gate behind an application for marketing reasons — exclusivity, perceived value. I started doing it for that reason too. Now I think the filtering is actually the feature.

The 48-hour heuristic

Not scientifically validated. But: if someone doesn't reply to a one-sentence follow-up within 48 hours when there's a free cohort spot on the table — I move on.

Not because they're a bad candidate. Because I'm optimizing for sprint completion rate, not cohort size. A sprint that ends with 3 people who shipped is worth more to the next cohort than one with 8 people who dropped out at Day 10.

The beta's goal is proof: that this format produces finished products. One person shipping and able to say "I went from stuck to deployed in 21 days" is the asset. Eight half-finished sprints is noise.

So the silence was useful. It made the decision simple.

Where I am now

Two applications this week. Both closed — one too early in the process, one via the silence rule.

Still recruiting for Cohort #1. Five to eight spots. Free.

The pipeline is open. The application takes about four minutes. I respond personally to every one.

If you've got a project that's been "almost done" for more than a month, that's probably the tier you need.

Cohort #1 is free: https://mvpbuilder.io/pipeline?utm_source=devto&utm_medium=article&utm_campaign=cohort1&utm_content=post4

Building in public. Previous post: AI made experienced devs 19% slower. Here's the side project trap that created.

AI made experienced devs 19% slower. Here's the side project trap that created.

MVPBuilder_io — Fri, 27 Mar 2026 12:56:07 +0000

METR measured it in 2025 — senior devs with AI coding assistants worked 19% slower and thought they were 43% faster. For side projects, this gap is career-ending for your product.

In July 2025, METR ran a controlled trial with experienced software developers using AI coding assistants.

The result: they worked 19% slower than without AI tools. Not faster.

Worse: they thought they were working 43% faster.

A 62-percentage-point gap between perception and reality.

I kept thinking about what this means for side projects specifically — because I think it matters more there than anywhere else.

The planning fallacy didn't go away

Daniel Kahneman named it in 1979: we systematically underestimate how long our own tasks take, and overestimate how much we'll get done. External reference points help. Deadlines help. Someone watching helps.

The assumption was: AI will fix this. AI will plan better, build faster, reduce rework.

METR's data says otherwise. Not because AI tools are bad — they're genuinely capable. But because the planning fallacy is a cognitive pattern, not a speed problem. The issue isn't how fast you can execute a decision. It's whether the decision was right in the first place.

What actually changed

AI tools like Claude Code, Cursor, and Codex shifted something real. The problem isn't "I can't build this feature." You can build almost anything faster than two years ago.

The problem shifted:

"I'm building very fast in the wrong direction."

Without structure, every session starts with: what do I actually work on today? With AI, you can execute that decision faster — but if the decision is wrong, you've just done more damage more efficiently.

For a solo dev with a full-time job, this compounds. You have 90 minutes on a Tuesday evening. You fire up Claude Code. It helps you build. But toward what? The commitment is to the project in your head — not to the specific thing that makes a user pay.

The side project-specific problem

Side projects don't have a PM. No sprint planning. No "why are we building this?" meeting that forces articulation. No one asking "is this the right thing to ship this week?"

For a full-time team, structure is often annoying overhead. For a solo dev with 8 hours a week, it's the difference between shipping in three months or archiving in six.

AI makes you more productive within a session. It doesn't know that you skipped Day 4. It doesn't know that you spent your last three sessions on a feature nobody asked for. It won't ask you "is this the thing that makes someone pay?"

That accountability — the external forcing function — has to come from somewhere else.

What I built

I ran into this loop three times across three different products. I started building a system to break it.

MVP Builder is a structured 30-day sprint with one daily AI prompt, delivered to your inbox each morning. The prompt isn't generic. It knows your project — your stack, what's built, what's left, what you said yesterday — and asks you to move one specific thing forward.

Three tiers, based on where you actually are:

Bronze (13 days): Idea only → working prototype
Silver (21 days): Started but stuck → shippable product
Gold (30 days): Almost done → actually shipped

The structure is the feature. The daily prompt is the external "what do I work on today?" so you don't spend your 90 minutes answering that question yourself.

Where I am now

Cohort #1 is free. Beta. 5–8 spots. I'm in Day 10 of recruiting.

The product works — the cron system, the prompt pipeline, the milestone tracking. The part I'm still figuring out is distribution. Which is its own kind of side project problem.

If you've shipped something after a long "almost done" phase — or if you're currently in one — I'd genuinely like to know what finally broke the loop.

Cohort #1 is free: mvpbuilder.io/pipeline

Building in public. Previous post: I built 3 MVPs that never shipped. Here's what I learned.

I built 3 MVPs that never shipped. Here's what I learned.

MVPBuilder_io — Thu, 19 Mar 2026 12:46:54 +0000

I want to tell you about three projects I spent hundreds of hours on that nobody ever used. Not because I ran out of time. Because I never shipped them.

The three projects

Project 1: Freelancer time tracker
Core timer working within two weeks. Then: reporting dashboard, CSV export, team features, client portal — for a product with zero users. Archived when I changed jobs.

Project 2: Notion template marketplace
60% done before the backend rewrites started. "The architecture wasn't clean enough." Month four: clean code, no product, no energy.

Project 3: AI habit tracker
Built it, used it myself for two weeks, stopped when I couldn't answer "why would anyone pay for this?"

Three codebases on GitHub. Zero shipped products.

The pattern I kept missing

I was optimizing for building, not for shipping.

Without a hard external forcing function, the project always slipped. Re-entry friction accumulated. Every session started with: what do I work on today? If that question took 20 minutes to answer — or worse, if I answered it wrong and spent 3 hours on something that didn't move the needle — I'd slowly start avoiding the project altogether.

Eventually it entered "almost done permanently." Touching it meant confronting how much was left. So I just didn't.

How I fixed it — the technical side

I built MVP Builder: a structured 30-day sprint with one focused daily prompt, delivered 07:00–09:00 local time.

The constraint: Vercel free tier allows max 2 cron jobs, minimum daily interval.

My solution — two cron jobs covering both hemispheres:

0 6 * * *   → EU: CET 07:00, CEST 08:00
0 14 * * *  → Americas: MST 07:00, CST 08:00, EST 09:00

Timezone filtering (app-side, not cron-side)

import { toZonedTime } from 'date-fns-tz';

function isInDeliveryWindow(timezone) {
  try {
    const zoned = toZonedTime(new Date(), timezone);
    const hour = zoned.getHours();
    return hour >= 7 && hour < 9;
  } catch {
    return true; // fail-open: send rather than skip
  }
}

Why app-side filtering instead of more cron jobs? Because cron runs at a fixed UTC time — it can't know each user's local hour. The filter runs per-user at send time.

Why fail-open? An invalid timezone (typo, legacy string) shouldn't mean the user never gets their prompt. Missing one day is worse than getting it slightly off-window.

Idempotency: 20h lookback, not 24h

const twentyHoursAgo = new Date(Date.now() - 20 * 60 * 60 * 1000);

const { data: alreadySent } = await supabase
  .from('users')
  .select('id')
  .eq('id', userId)
  .gt('last_prompt_sent_at', twentyHoursAgo.toISOString())
  .single();

if (alreadySent) return; // already sent today

Why 20h and not 24h? DST transitions. A 24h lookback on a DST-switch day can either skip a user or double-send. 20h is safely within any DST shift (max ±1h) while still preventing duplicates within the same day.

Timezone capture at signup (silent, no UI change)

const detected = Intl.DateTimeFormat().resolvedOptions().timeZone;
// → include in form payload, no UI element needed

One line. No dropdown. No user decision fatigue. Works on every modern browser.

The schema (relevant columns)

ALTER TABLE users ADD COLUMN timezone TEXT DEFAULT 'Europe/Berlin';
ALTER TABLE users ADD COLUMN last_prompt_sent_at TIMESTAMPTZ;

The DEFAULT 'Europe/Berlin' matters: new users without a detected timezone still get a prompt at a reasonable hour rather than silently skipping.

What's different this time

I shipped it.

$0 MRR. Beta cohort is free. The product that helps developers ship has to ship first — otherwise the whole premise falls apart.

Three tiers based on where you actually are:

Bronze (13 days): Idea → working prototype
Silver (21 days): Started but stuck → shippable product
Gold (30 days): Almost done → actually shipped

Each morning: one focused prompt, 30–90 minutes max. No sprawling to-do lists. One milestone checkpoint with proof of work. That's it.

Cohort #1 is free. 5–8 spots: mvpbuilder.io/pipeline

If you've shipped something after a long struggle — or if you're currently stuck at "almost done" — drop it in the comments. I read every one.

Building in public. Will post updates on what the beta cohort looks like.

I have 8 unfinished side projects. Here's what I learned.

MVPBuilder_io — Wed, 18 Mar 2026 07:50:43 +0000

I counted them last month. Eight. Eight folders on my hard drive with names like invoice-tool-v2, habit-tracker-final, freelance-dashboard-REAL. All started with energy. All dead somewhere between week two and week four.

I have a full-time job. I'm a decent developer. I'm not lazy.

So what's actually going on?

The pattern I kept ignoring

Every project died the same way.

Week one: excited, building fast, everything feels possible. Week two: first real obstacle. I "take a break" to think. Week three: I open the folder, feel vaguely guilty, close it again.

Week four: it's over. I just haven't admitted it yet.

The problem wasn't skill. It wasn't the tech stack. It wasn't even time — I have 30-45 minutes most evenings.

The problem was structure. I had no system that forced me to make the next decision when motivation ran out. And motivation always runs out.

What I tried (and why it didn't work)

Notion boards. Great for the first three days. Then the board becomes the project.

YouTube tutorials. Learned a lot. Shipped nothing.

"I'll do it on the weekend." I have a full-time job. Weekends don't work the way I think they will on Tuesday.

Accountability partners. The other person always dropped off first. Or I did.

Deadlines I set for myself. Completely ignored, every time.

A deadline you set for yourself is just a suggestion.

The real bottleneck

At some point I stopped asking "what should I build?" and started asking "why do I never finish anything?"

The answer wasn't inspiring. I needed external structure. Not coaching, not a course — just something that tells me what to do next today, specific to my project, and holds me to a milestone I can't quietly move.

That's not a personality flaw. That's just how accountability works. Most people need some version of it.

What I'm testing now

I built MVP Builder — a structured 30-day sprint for solo developers with full-time jobs.

The idea is simple: every morning you get a single AI prompt tailored to your specific project and where you are in the sprint. Not generic advice. Not a framework to study. One concrete task for today.

At day 13, 21, or 30 (depending on your track — Bronze, Silver, Gold), you submit a milestone proof. Not a vague "I made progress" — a working link, a video, something real. It gets reviewed.

I'm not going to tell you it's the perfect solution. It's a beta. Cohort #1 is free. I'm testing whether structured external accountability actually moves the needle for developers like me.

What I've learned from the 8 dead projects

A few things that are obvious in hindsight:

Shipping something imperfect beats planning something perfect. Every time.

The gap between "almost done" and "done" is psychological, not technical. The last 20% is where motivation collapses and you need a different fuel.

Solo builders don't fail because they lack ideas or skill. They fail because nothing forces them to make the next decision when they don't feel like it.

A deadline you didn't set yourself is worth ten you did.

If any of this resonates — if you have your own graveyard of almost-finished projects — I'm looking for 5 to 10 developers for the first cohort.

Free. No credit card. You just need an idea and 30-45 minutes a day.

→ mvpbuilder.io/pipeline

What killed your last side project? Genuinely curious.