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:
- “There are features we’ll need that this tool won’t support.”
- “The documentation is bad.”
- “The pricing is too high.”
- “We can’t track changes or monitor them well.”
Valid concerns? Sometimes. However, these were usually signals of discomfort, rather than real blockers.
Why I Lost These Battles
Looking back, I lost those arguments for three reasons:
- Risk: When I didn’t have deep experience with the stack, it was hard to push back. I couldn’t debug confidently. I couldn’t guarantee success.
- Experience Bias: If a developer had worked with a tool before, I was often at a disadvantage. Their familiarity carried weight — even if it came with blind spots.
- Political Capital: Developers have strong opinions about code. They want to build. They underestimate the cost and complexity of internal ownership. They rarely own support or operations. And pushing back too hard, too often? That risks morale, not just timelines.
The Hidden Psychology
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.
Why We Do It
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.
Final Thought
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.