The Sunk Cost Illusion

Founders often mistake early code for progress. But the real challenge isn’t shipping features — it’s avoiding the trap of sunk cost thinking. This post breaks down why pausing before you commit is the smartest move you can make.

The First 50k (of tech spend)

When I get pulled into a startup project after the first $50k has been burned on development, I already know what’s going on. There’s code, frustration, a fractured vision, and a sense that something’s off — but no one wants to say it.

What’s happening is sunk cost thinking. The founder isn’t just evaluating the next step — they’re defending the last one. Not always, but often.

And here's the hard part: I can't fix that mindset. It has to shift on its own.

Why Founders Build Too Early

I see the pattern all the time. I’ve stopped judging it. These are honest, very human reasons:

  1. "All real startups have dev teams."

  2. "Code is cool." It feels like a moat. Like proof of work.

  3. "This stack proves I’m serious." A unique build feels like validation.

But underneath those beliefs is something deeper — a fear of not knowing, a discomfort with the ambiguity of early product discovery.

And ironically, the faster a founder cements their first ideas, the harder it becomes to evolve them.

The Cement Pad Problem

I visualize this like building a new house on a Maine mountainside — 50 acres, tons of views, endless possibilities. You don’t know which view you’ll love most yet. But you’re excited, so you pour cement for a garage.

And suddenly… you’re locked in.

No one builds a house far from their garage. The second cement hits the ground, your imagination shrinks. You’ve chosen — whether you meant to or not.

The Unlock Moment

Here’s something I do often: I tell founders, go vibe code your vision.

Build it how you imagine it. Go wide. Push the dream. Because in doing that, you’ll unlock something you didn’t know was there.

Then you come back to me (or any number of other early product people) — and I’ll give you 5 to 10 microfeatures. Tightly scoped. Surgical. Ruthless. I’ve been listening the whole time. I’m tracking the shortest path between your idea and your first dollar.

And I don’t give a crap about how you think you’ll get there. I care about outcomes. Traction. Proof.

So when I hand over those prompts — and we kick off the next build — founders break wide open.

I’ve seen relief. I’ve seen the ego drop.

And for the first time, the customer becomes real. They stop building for investors or pitch decks or pride — They start building for people.

And that? That’s the magic. That’s the moment I’m worth every penny. (or a few dimes)

Also, I have experienced this several times myself, in past startups. Too often I thought I knew the pathway forward. It feels important to know. Again, it feels important to know. Nobody wants to tell their family that they do not have a plan.

What I Wish More Founders Did

  • Walk the land (back to the building a house metaphor).

  • Watch a few sunrises.

  • Don’t ask where to build — go visit other people’s homes.

  • Talk to customers until the assumptions fall apart.

  • De-risk your thinking, not just your build.

  • Ignore early signals! Don’t overvalue support.

Resist the urge to pour (a foundation) anything. Don't ship until you’ve felt the pull from real users or buyers.

Vaporware everything. The best ideas are the ones customers demand before they exist.

My Favorite Founders

My favorite founders aren't the ones with the slickest stack. They're the ones who laugh when an assumption dies. The ones who replace pride in code with joy in learning. The ones who see the market clearly — and know that building comes last.

Again, I wish I had been this type of founder. It’s not easy.

What’s Next?

This is where the Low-Code Cookbook comes in — not as a shortcut, but as a framework for making better tech decisions.

Once a founder reaches that inflection point — when the noise quiets, the ego drops, and the customer becomes real — it’s time to build with intention.

The Cookbook (hopefully) offers a path to assemble a modern SaaS stack that limits custom code, preserves flexibility, and accelerates learning. It’s not about skipping the hard parts — it’s about deferring permanence until the vision is sharp enough to commit.

Build just enough to explore the land. Then pick your view.

(Also, if you are reading this newsletter, you will have access)