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.
I think a lot about what works and what doesn’t. This week I am outlining an issue I ran into over and over, and which I hear a lot from other founders. How do we get technology teams to build less and deliver more? The solution is not more code, it’s less code—more focused and simple solutions.
Whenever I asked a senior dev to evaluate vendor solutions — form builders, auth providers, workflow tools — I noticed the same result: they defaulted to building in-house.
It didn’t matter how many options I presented. It didn’t matter how much product velocity we needed. The answer was almost always: “We should just build it.”
The Arguments Were Always the Same I started logging the objections. They fell into four categories — always:
Valid concerns? Sometimes. However, these were usually signals of discomfort, rather than real blockers.
Looking back, I lost those arguments for three reasons:
There’s another reason devs resist vendors: fear of blame.
If something breaks, the person who chose the vendor will be held responsible. And when you’re a developer, it’s often safer — politically and emotionally — to own the risk. Because then at least you can fix it.
This is the same logic behind fear of flying: flying is statistically safer, but people feel safer when they’re behind the wheel. Control often feels more valuable than actual safety.
Developers feel safer owning the problem, even if it takes longer and costs more. Because if they build it, they believe they can fix it.
But that instinct is expensive.
Because developers also struggle to assign a dollar value to a bug. I’ve seen devs obsess for days on UI edge cases, chasing down styling issues or exotic states, while major revenue blockers sit untouched.
Control feels good. But control without context kills momentum.
What I Learned (Too Late) When my last company folded, I spent two weeks going through our GitHub history. I mapped out every new dependency and third-party integration.
I identified 10 distinct instances where we opted to build rather than buy. Every one of those decisions looked small at the time. Everyone added drag. Added cost and took time and focus that could have been focused on revenue drivers.
And here’s the kicker: in retrospect (with the team), even the developers admitted we overbuilt. But the next time?
We repeated the pattern.
This is deeper than tech strategy. Its identity.
Developers are makers.
We solve problems with code — it’s how we feel useful. And in fast-moving startups, that instinct isn’t just dangerous — it’s expensive.
I’m Still Working on the Fix I don’t have a silver bullet yet. But I’ve found a few approaches that help:
Pre-bake the tech stack before the team arrives. Once there’s a team, every decision becomes a debate.
Frame vendor tools as unlocks, not compromises. Focus on speed-to-outcome.
Audit build vs. buy in retros. Make it a habit to ask: “Did we overbuild again?”
Use tools like the Low-Code Cookbook. Having vetted options upfront gives you a real way to push back.
This isn’t a developer vs management problem — it’s a culture problem.
Until we stop tying value to lines of code, we’ll continue to make the same costly choices. We don’t need more control. We need more results.