Every engineer at Google has access to a code search tool called Kythe that can index and cross-reference billions of lines of code in seconds. No version of it exists for the public. Facebook’s internal task manager, used by product teams to coordinate launches, is faster, more reliable, and less cluttered than any project management software the company sells or competes against. Amazon’s internal dashboards for monitoring AWS infrastructure are, by most accounts of former employees, substantially more capable than the monitoring tools Amazon sells to AWS customers. The pattern is consistent enough across the industry that it stops being a coincidence and starts being a policy.
This dynamic connects directly to how large technology companies maintain structural advantages over competitors. As we’ve examined in “Platform Companies Don’t Kill Competitors. They Make Competition Impossible.”, the most durable moats in tech aren’t built on better products for customers. They’re built on capabilities that competitors simply cannot replicate, often because those capabilities were never designed to be sold.
The Economics of Not Shipping
The standard explanation for why internal tools outperform commercial ones is that enterprise software is ugly, slow, and confusing because the people who buy it are not the people who use it. A procurement officer selects software based on compliance features, vendor relationships, and price. The engineers and analysts who actually open the tool every morning had no vote. This misalignment has been well-documented, and it is real, but it only explains part of the gap.
The deeper reason is that internal tools face a completely different set of economic constraints. When Google builds Kythe for its own engineers, there is no pricing decision, no sales cycle, no customer support burden, and no obligation to maintain backward compatibility for paying clients who haven’t upgraded. The tool can break old workflows if the new ones are better. It can require training. It can assume that every user is highly technical. It can be ruthlessly optimized for a single use case rather than stretched across a thousand different customer configurations.
Commercial software carries enormous overhead that has nothing to do with making the software better. As explored in “The Hidden Reason Enterprise Software Looks So Terrible”, the ugliness and complexity of enterprise tools is frequently a structural outcome of how they are sold, not a failure of design ambition.
The Compounding Advantage
The gap between internal and commercial tools does not stay constant. It widens.
When a technology company builds a tool for its own engineers, those engineers use it daily and file bug reports immediately. The feedback loop is hours, not quarters. Product decisions are made by people who understand the problem technically. Improvements ship continuously. There are no contract cycles that lock in a feature set for 18 months.
Commercial software, by contrast, must balance the competing demands of thousands of customers who want different things. A feature that 40 percent of customers need urgently might get deprioritized because the other 60 percent don’t want their workflow disrupted. Software updates keep breaking things in commercial products partly because vendors are managing this tension between innovation and stability across a fragmented customer base. Internal tools don’t face that constraint.
Over three to five years, this compounds significantly. A commercial tool improves incrementally, constrained by sales cycles and customer conservatism. An internal tool, used by highly motivated technical users with direct access to developers, can evolve an order of magnitude faster. The result is not just a better tool. It is a fundamentally different category of capability.
Why Companies Don’t Just Sell the Good Stuff
The obvious question is why companies don’t commercialize these tools. Some do. Amazon Web Services is, in some respects, Amazon’s internal infrastructure offered to the public. Stripe’s engineering tools have been partially productized. But in most cases, companies with genuinely superior internal tools choose not to sell them, and the reasons are instructive.
First, the tools are often deeply entangled with proprietary infrastructure that cannot be extracted cleanly. Google’s code search works partly because Google’s entire codebase sits in a single monolithic repository, a structure almost no other company uses. The tool isn’t just better because it was well-built. It’s better because it was built for a specific environment that can’t be replicated.
Second, commercializing a tool requires a level of generalization that often destroys what made it good. Stripping out the Google-specific assumptions, adding configuration options for other architectures, building a support organization, and maintaining compatibility across diverse customer environments would, by most engineers’ accounts, produce something much closer to the mediocre commercial alternatives it would be competing against.
Third, and perhaps most importantly, some companies recognize that their internal tools are a competitive advantage precisely because they aren’t available to competitors. Releasing them would level a playing field that currently tilts in their favor. This is the logic behind tech companies hiring overqualified engineers on purpose: the goal is to build capabilities that justify the investment through structural advantage, not necessarily through direct revenue.
What This Means for the People Buying the Public Version
For the businesses and individuals buying commercial software, the implication is uncomfortable. The tools available on the market are, in many documented cases, deliberate simplifications or partial releases of what their creators actually use. The customers paying subscription fees for project management software, developer tools, analytics platforms, and communication products are not getting the best version of those products. They are getting the version it made business sense to sell.
This is not conspiracy. It is economics. Building a tool for 50,000 of your own highly technical employees is a completely different problem than building one for 50 million customers with varying technical sophistication, different workflows, and legal requirements across 40 countries. The constraints produce different outcomes.
But the gap should recalibrate expectations. When a developer tool feels slow, or a productivity platform feels bloated, or an analytics dashboard feels three steps removed from the insight you actually need, the likely explanation is not that the problem is unsolved. It is that the solution exists somewhere inside the company that sold you the inferior version, running on servers you’ll never touch, used by engineers who work there.
The best tools in the world are not for sale. They are competitive advantages that their owners have every reason to keep exactly where they are.
