Proudly Found Elsewhere

#architecture #cloud #management #softwareengineering

I've helped many companies ship better software faster. One negative trend I've observed at many of these is what's termed the "not invented here" (NIH) syndrome. That is, they tend to build or self-manage software rather than let another company provide it as a paid service.

I've observed this with its attitude toward cloud-managed services, like Lambda or S3: ("We should stick to Kubernetes because we can easily port this to other cloud platforms if necessary."), with database clusters ("Seriously, how hard is it to run MongoDB?"), and with source control ("We can run GitLab ourselves and keep things secure"). I take a different approach - one aligned with the concept of "the division of labor" that lets specialized companies trade efficient services with one another.

By Division of Labor, I mean "the separation of the tasks in any economic system or organization so that participants may specialize." (Wikipedia). It's the specialization that provides the value. Those specialists then voluntarily trade with one another to mutual benefit. When organizations choose to specialize and trade, they cure themselves of NIH. There's even a term for this new approach: "proudly found elsewhere" (PFE). I like that.

Not everything

However, these companies did not consistently apply NIH. They all used other companies specializing in parts of the business they would otherwise own. For example, they used authentication/authorization providers like Auth0, webinar providers like Zoom, email providers like MailChimp, and, most conspicuously, data center providers like AWS.

My litmus test: "Is this service/app a distinguishing, separately marketable feature of our business? If so, build it. Otherwise, let's find a provider." For example, if we don't have a world-class authentication platform that we could actually market and sell (we don't), then we should look to lease one (we did - Auth0). This helps keep expensive engineering and operations work focused on key business initiatives.

Win-win

When I specialize in building software for a business and let Amazon specialize in providing on-demand data centers, who wins and who loses? When my company and Amazon trade (my company's dollars for Amazon's infrastructure), we both benefit. We both win.

Let's look at a more canonical example that I learned from Dr. Yaron Brook. You want to buy an iPhone. It costs $1,000. As you walk out of the Apple Store with your new iPhone, did you "win"? Yes! You valued the iPhone more than you valued your $1,000 (or you wouldn't have bought it). Did Apple win? Yes! They valued your $1,000 more than the iPhone (or they wouldn't have sold it). Both sides voluntarily exchanged a lesser value for a greater one.

This mutually beneficial nature is the essence of trade. It happens when you are trading for iPhones, groceries, or software. And specialization (division of labor) allows both Apple and my company to maximize the value we can bring to the trade. Win-win.

Should I trade?

Some considerations when approaching build/buy:

Speed. It is often much faster to integrate with an existing SaaS provider than to build your own. I once worked with a startup whose CEO repeatedly told me, "Time is not our friend."

Cost. The provider of a SaaS product knows that domain, whatever it is. They have economies of scale and offer a slice of that scale at an affordable per-unit price.

Expertise. The SaaS provider is declaring: "I am good at XYZ; I can deliver it better than any of my competitors, and I constantly work to improve how I deliver it." Who do you think can better run GitLab, your already overworked Operations team, or GitLab itself?

Security. Your SaaS provider's incentive aligns with yours: protect customer data or go out of business. They focus on their security while you focus on yours. For example, Amazon's AWS access management is world-class. You could spend years on your own and never come close.

Complexity. The more responsibilities we heap on engineers, the less they can retain about any particular part of the system. E.g., if engineers have to run and maintain their backend applications and then we start hosting our own MongoDB servers, we now have to add MongoDB DBA tasks to the volume of knowledge we need to keep up to date. Often, a company in this situation ends up hiring someone with specialized knowledge (MongoDB DBA), which further drives up the costs of not using a SaaS provider.

A Reddit thread on self-hosted vs. GitLab.com captured this well: "If gitlab.com crashes, which isn’t impossible, you’ll have the same problem. But given that their core business is running GitLab servers and your core business is probably something else, they are probably better at running GitLab servers than you are."

The same thread also surfaced the opposing view: "For us always self hosted but we’re just like that. I prefer to be in control so if something breaks it can only be my fault." This is a revealing response. "Always self-hosted" and "we’re just like that" signal convention masquerading as strategy. And the reasoning behind "if something breaks it can only be my fault" doesn’t hold up — self-hosting increases the likelihood of something breaking in the first place. Accepting blame isn’t a benefit; it’s a cost.

The Law of Comparative Advantage

The idea of focusing your efforts on what you are good at and trading with others (who are doing the same) is not new. Adam Smith hinted at the concept in his 1776 book, The Wealth of Nations. It was most famously characterized in 1817 by the English economist David Ricardo as "The Law of Comparative Advantage."

Ricardo was interested in international trade. He demonstrated that, given two countries and two goods, even if one country could produce both goods more cheaply than the other, both countries were better off producing the good they are most efficient at and trading the other. It is a bit counterintuitive, but extremely powerful.

I recently read an example in an article from Dr. Harry Binswanger about the subject, from which I quote:

The Law of Comparative Advantage applies much more widely than to international trade. It used to be illustrated by considering a CEO and his typist—back when there were typewriters and typists. Even if the CEO can type faster than a given typist, it pays him to hire that typist because off-loading the typing work saves him time. He can then use that saved time in the area of his comparative advantage: running the company.

AI and the new NIH

The same syndrome is alive and well in the AI era. As large language models have reshaped software development, teams are facing a new wave of build-or-buy decisions: should we use the OpenAI or Anthropic API, or train our own model? Should we use a managed vector database, or build one in-house? Should we license an AI coding assistant, or build our own?

The reasoning sounds strategic: data privacy, cost control, and avoiding vendor lock-in. But the underlying economics haven't changed. Consider AI coding assistants. Companies are building internal "code copilots" instead of licensing Claude Code, Cursor, or GitHub Copilot. Their engineering teams spend months fine-tuning models, wrangling GPU clusters, and building IDE integrations—time that isn't going into their actual product. Meanwhile, the companies building those tools are doing nothing else. Their entire existence is solving that one problem. Their comparative advantage in this domain is overwhelming.

Or consider the companies standing up their own GPU clusters to run open-source LLMs, because "we don't want to depend on a third-party API." Fair enough—data privacy and compliance are real concerns in specific cases. But for most teams, this means hiring ML infrastructure engineers, managing CUDA drivers, tracking model updates, and absorbing the operational overhead of a business they are not in. AWS, Azure, and GCP have entire divisions whose comparative advantage is exactly this. Trade with them.

The litmus test still applies: Is this a distinguishing, separately marketable feature of our business? If you're not building the next foundation model, you probably shouldn't be operating one.

Wrapping Up

So, what would I tell business leaders who want to build it themselves? The advice is the same whether we're talking cloud infrastructure or AI: use GitLab.com instead of hosting your own GitLab. Use MongoDB Atlas—or better yet, migrate to DynamoDB. Pick a cloud provider that offers a broad array of fully managed services and start consuming them (Hello, AWS!). And when your team starts debating whether to build your own LLM, vector store, or AI coding assistant, ask the litmus test question first. If the answer is "no, this isn't what we sell," find a provider.

The division of labor is not just an economic abstraction—it's a practical engineering strategy. Specialization creates depth. Trade creates efficiency. When you focus your team on what makes your product unique and let specialists handle everything else, you ship faster, operate more reliably, and scale more sustainably. Both sides win. That's the whole point.

Happy building!