Why Developers Always Want to Build — and How It Costs Us

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.”