Build vs Ship: A Decision Framework for Solo Founders

Most failed indie SaaS founders polished features no user ever asked for. Here

Build vs Ship: A Decision Framework for Solo Founders

There's a specific kind of indie founder failure that doesn't look like failure. The founder works full days. The code base is well-structured. Test coverage is good. Documentation is thorough. The Figma file is gorgeous.

And the product never ships.

Or it ships, but the next feature never ships. Or the next-next feature spends nine weeks in "polish" and lands to crickets, and the founder spends another nine weeks fixing it, and meanwhile the runway burns and the competing-product graveyard grows.

I've watched this happen to ten different founders in 2025 — all of them smart, technically competent, well-intentioned. None of them were lazy. Every single one was building. None of them were shipping. And the gap between those two verbs is the entire game.

The four-question filter

Before adding anything — a feature, a polish pass, a refactor, a new integration — I run it through four questions in order. If it fails any one of them, I don't do it. If it passes all four, I do it now, not later.

Question 1: Has a real user (or buyer) asked for this in the last 30 days?

Not "would users like this?" Not "competitors have this." Not "this would be cool." Has someone — a paying customer, a trial user, or a high-intent prospect — specifically asked for the exact thing you're about to build, in the last 30 days?

If the answer is no, you're building from imagination, not from market signal. That's not always wrong — but it's a much riskier default than founders pretend.

Question 2: Is the smallest version of this on the critical path to a sale?

Critical path means: if this didn't exist, would the deal fall through? A feature can be wanted without being on the critical path. Users say "yeah I'd like dark mode" but they didn't decline to buy because of its absence. Dark mode is not on the critical path.

"I can't use your product without a CSV export" — that's on the critical path. Build the CSV export. Don't add CSV import, CSV scheduling, or CSV webhooks because while you're in there. Build the smallest version that closes the sale, then ship.

Question 3: Can I deliver the next feedback-worthy version in under 14 days?

Not the polished version. The version your most patient user would tolerate giving feedback on. If the answer is more than 14 days, either:

Question 4: What am I avoiding by working on this?

This is the hardest one. Solo founders, especially technical ones, gravitate toward problems they know they can solve and away from problems they don't. The 90% of indie SaaS failure modes I've seen all share this: the founder spent month four building features instead of doing the scary, undefined thing — usually sales, pricing, or talking to customers.

If your honest answer to "what am I avoiding by building this?" is "sales calls / customer interviews / pricing / outreach" — close the IDE and go do that instead.

Three signs you're avoidance-building

The fourth question is the most important and the one founders lie to themselves about most. Here are three behavioural signals that you're avoidance-building, even when you're sure you aren't:

1. You started a refactor instead of finishing a feature

Refactors feel productive because they involve typing. They are productivity-shaped. But they almost never move revenue. If you started a refactor while a customer-requested feature was still in progress, you're almost certainly avoiding shipping that feature — usually because it's harder than the refactor.

Honest test: would your last refactor have improved customer experience in any measurable way? In 95% of cases, no. It improved your experience of looking at your own codebase. That has zero customer value.

2. You're optimising tools instead of using them

If you spend a day reconfiguring Linear, picking a new analytics provider, or rewriting your CI pipeline — that's avoidance work disguised as infrastructure. The 30 minutes a week you'll save by switching from Tool A to Tool B never pays back the day spent switching, and meanwhile you didn't ship.

The exception: genuinely broken tooling that's blocking shipping. If your CI takes 40 minutes and is preventing 10 ships per week, fixing it is the right move. But that's using tooling to ship more, not polishing tooling to feel productive.

3. You added something to a roadmap doc instead of building it

Writing about features in a doc is a great way to look like you're working on them while never starting. Especially dangerous: the "considering" or "Q2 priorities" column. Anything that lives in a doc for more than two weeks without becoming code is almost certainly dead.

The rule: if you're not going to start a feature within seven days of adding it to a roadmap, delete it from the roadmap. Either it's the next thing or it's nothing — there is no useful middle.

How this framework applies in real time

Last week I almost built a feature for Site Autopilot called "team workspaces" — letting agencies share a workspace with their team. Sounds reasonable. I'd already mocked up the schema.

Then I ran the four-question filter:

I cancelled the feature, had the pricing conversation, closed the deal, and the agency didn't ask about team workspaces. The right call. The pricing conversation was the work. The feature was the avoidance.

The features you build during periods of avoidance are almost always the wrong features. The features you build right after a hard conversation are almost always the right ones.

When to break this framework

Three legitimate cases where you should override the framework and build anyway:

  1. You have specific high-conviction insight no user could articulate yet. Most founders think they have this. Almost none actually do. But occasionally — once or twice a year for most founders — you'll have a genuine product insight that's invisible to current users. Build it. But honestly assess whether the conviction is real or whether it's just enthusiasm.
  2. Compliance, security, or legal forcing functions. If GDPR is going to bite you in 4 weeks, building the cookie banner isn't customer-led but it's still right.
  3. You're paying down debt that's actively blocking shipping. Real debt only — flakey deploys, mystery bugs, a database schema that's stopping new features. Imagined debt ("we should really refactor this") doesn't count.

Notice that all three exceptions have an external forcing function. None of them are "I just felt like building this." If your override doesn't have a clear external force pushing it, it's probably just preference.

The mantra that fixes 80% of this

If you take only one thing from this essay: ship the smallest version, then talk to the user who said they wanted it. Not in that order — in only that order.

Talking to the user before shipping leads to scope creep. Shipping before talking leads to learning whether the scope was even right. The cheapest, fastest version that you can put in front of a real human is almost always the right version to start with, even when it feels too small.

The framework above exists because solo founders have one finite resource — weeks. Every week spent building the wrong thing is a week not spent learning what the right thing is. The four questions are just a way of reducing the rate at which you spend weeks on the wrong things.

You won't be perfect at it. Nobody is. But run the questions even half the time, and you'll outship the average indie founder by 3-5x over a year — which compounds into the kind of velocity advantage we talk about in The Shipping Moat. Which is, in the end, the only moat that matters.