Is AI Better at Avoiding “Not Invented Here” Than We Are?

This weekend I was driving to get gas when a software term popped into my head.

Whatever happened to “Not Invented Here?”

“Not Invented Here” (NIH) was one of those software discussions that always seemed settled. Don’t reinvent the wheel. Build where you differentiate. Stand on the shoulders of everything that came before.

And yet, almost every experienced software engineer has a story about the homegrown ORM, the custom messaging framework, the proprietary workflow engine, or the internal tool that slowly became another product to maintain.

I’ve seen NIH from several different perspectives over the course of my career.

At Logi Analytics, our Logi Info product was, in many ways, a wrapper and orchestration layer around numerous third-party components. That wasn’t a weakness. It was the strategy. We focused our engineering effort on the pieces that differentiated us rather than rebuilding every layer of the stack.

Later, while leading our Sales Engineering team, I encountered the same idea from the opposite direction. One of the recurring conversations with prospective OEM customers was whether they should embed Logi Info or build reporting and dashboarding themselves. The biggest point of friction usually wasn’t whether they could build it. Many absolutely could.

The customers we eventually won often weren’t the ones evaluating the decision for the first time. They were the ones who had already built reporting into their application.

The initial implementation wasn’t the problem. It was everything that followed.

Every enhancement request. Every browser change. Every export format. Every security issue. Every customer asking for another reporting feature.

Eventually, many concluded that reporting wasn’t where they wanted to spend their engineering talent. They had proven they could build it. What they hadn’t anticipated was owning it.

Years later, at PerformYard, I experienced almost the opposite philosophy. We had our own ORM. Like many growing software companies, we accumulated internal frameworks over time. As the company matured, we became more pragmatic, adopting products like PostHog for analytics and AG Grid instead of continuing to build and maintain everything ourselves.

Neither approach was inherently right or wrong. Different companies, products, and stages of growth lead to different decisions.

A lot of the discussion around AI has focused on whether companies will build more software instead of buying SaaS.

The next question is what happens after you’ve already decided to build.

Once you’ve decided to build, how does an AI coding agent decide what to build?

That’s a different question than build versus buy.

That’s when I thought back to GeoSheet.

A few months ago I built GeoSheet with Claude Code. I made a few architectural decisions up front. I wanted PostHog for analytics and Stripe for billing. Beyond that, I spent very little time prescribing frameworks, libraries, or implementation details.

Mostly, I described the product I wanted to build.

Out of curiosity, I looked back through the project’s dependencies.

The project leans heavily on mature open-source infrastructure: Fastify, Drizzle ORM, React Query, Yjs, Mapbox, Zod, Zustand, React Hook Form, and many others. The custom code is concentrated almost entirely in the parts that actually make GeoSheet… GeoSheet.

Looking back, that’s remarkably similar to where many of our Logi Info OEM customers eventually landed. Building the parts that differentiated their products created value. Owning every layer of infrastructure often didn’t.

Curious whether anyone had actually studied “Not Invented Here,” I spent a little time reading.

One paper in particular, Opening the Black Box of “Not Invented Here”: Attitudes, Decision Biases, and Behavioral Consequences, describes NIH as a more general decision-making bias: a tendency to reject or undervalue ideas, technologies, or knowledge simply because they originated somewhere else.

There are other explanations for what happened in GeoSheet. AI coding agents have effectively “seen” millions of software projects. Reaching for Fastify, Drizzle, or React Query may simply reflect the most common successful patterns rather than any architectural philosophy.

The research describes “Not Invented Here” as a human decision-making bias. AI is trained on the output of millions of human engineering decisions.

Does AI learn the “Not Invented Here” bias… or is it learning to avoid it?

P.S. One last thought I had after I finished this article was that I wonder if Claude Code will ever reply to a request, “Have you thought of buying this instead of asking me to build it?” I’m guessing an ad-supported Claude might one day.