In partnership with
Quick reminder of what this email is about: I'm a CTO who writes about the process of rethinking my code-brain perspective. That’s my description of my habit of defaulting to solving all challenges with code and complexity. I take particular joy in finding and fitting together the simplest solutions for problems.
New Tech in the Queue!
This summer time, so thankfully, things have quieted down. Networking events have become fewer, and the pace of connections and idea sharing has slowed. I love this time of the summer because it gives me time to get excited by some new tech.
OpenRouter.ai - This little gem came from the founding team of Pompeii Labs. Matty mentioned that I should take a look. I have learned that thought leaders are present everywhere. He is one of them. And I think he knows how much I jam on a fresh meet for the low-code engine!
So why will I review it: Anything that reduces idea friction is worth looking at. This solution enables founders to utilize AI models, but not to become experts. The Ai models available for business is moving way too fast, and it causes stress when we can not keep up. So this solution allows a founder or builder to abstract away. Make it not an issue. This company offers the potential to automatically switch a prompt to a better, newer, or less expensive model, on the fly.
The Benefit is that you do not have to allocate developer time to review all models and then update your application to use the newest AI model provider. This lowers switching costs while allowing a product to stay current.
I am scoring this solution once I get access and can test the process out with a quick POC project. All signs point to a fun time.
The Dream: Could this solution be integrated into a vibe-coded application, allowing for multi-model solutions with a single API key? Now that is super low-code.
On to the Meat of this Post
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.
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.
Find out why 1M+ professionals read Superhuman AI daily.
In 2 years you will be working for AI
Or an AI will be working for you
Here's how you can future-proof yourself:
Join the Superhuman AI newsletter – read by 1M+ people at top companies
Master AI tools, tutorials, and news in just 3 minutes a day
Become 10X more productive using AI
Join 1,000,000+ pros at companies like Google, Meta, and Amazon that are using AI to get ahead.
Also the Launch by Lunch community keeps growing. We pivoted from the standalone the AI class model into a community. This means we offer everything for a set monthly price. We offer weekly expert sessions, and office hours, where founders bring in their issues and we solve ideas as a group.