15 - Why Internal Tooling Sucks

Why Internal Tooling (Usually) Sucks

In this episode, Matt kicks things off with a provocative thesis: internal tooling usually sucks. What follows is a deep, nuanced exploration of one of software engineering's most persistent challenges—the build versus buy decision that every company eventually faces.

The Two Types of Internal Tools

The hosts identify two distinct categories of internal tooling:

• Wrappers: Tools that extend existing external solutions (like a custom UI for managing GitHub repository settings)
• Replacements: Complete alternatives to industry-standard tools (like building your own NPM/Yarn/PNPM equivalent)

Through examples from HubSpot, Airbnb, and Whoop, they dissect when each approach makes sense and when it becomes a costly mistake.

The Hidden Costs Nobody Talks About

Scott breaks down the real expenses of internal tooling that go beyond initial development:

• Knowledge transfer when the original creator leaves the company
• Onboarding friction for new engineers who must learn proprietary systems
• Maintenance burden that never ends and always competes with customer-facing priorities
• Documentation debt that compounds over time
• The bus factor when only one person truly understands the tool

Matt shares his perspective that internal tools will always be secondary to a company's core business, making it nearly impossible to invest appropriately in their long-term health. Even with dedicated developer tooling teams, these tools rarely get the polish and support they need.

When Internal Tooling Actually Makes Sense

Despite the skepticism, the crew identifies legitimate scenarios for building internally:

When no external solution exists for your specific problem (and they mean truly doesn't exist) When you have subject matter experts who can build something better and maintain it When wrapping an external tool with company-specific context adds significant value When security or data sensitivity requirements make external tools impractical

They discuss examples like FlowBuilder at Airbnb and Easy Deploy at Whoop, exploring what makes these tools successful versus the cautionary tales of failed projects.

The External Tooling Counterargument

Dillon delivers his first genuinely spicy take of the podcast: external tooling has its own serious problems. Tools can be abandoned by maintainers, new versions can become impossible to migrate to, and companies can pivot their features in ways that don't align with your needs. His critique of Next.js and Vercel's approach generates the kind of heat the hosts have been asking him to bring.

Real War Stories

The episode is packed with concrete examples:

• HubSpot's custom dependency manager that replaces NPM entirely
• Wayfair's Tungsten framework (a React alternative that created years of technical debt)
• A year-long interior design app project that got canceled after launch
• The Jambox testing tool that could have worked with proper buy-in
• The painful reality of forking open source tools and maintaining them forever

The "It Depends" Framework

By the end, the hosts converge on a practical framework for making these decisions:

Questions to ask before building:

• What percentage of your use case does the external tool solve? (If it's 90%+, probably don't build)
• How foundational is this to your engineering system?
• What's the true cost including maintenance, not just initial development?
• Can the tool be replaced in days, weeks, or months if needed?
• Do you have the organizational buy-in and resources to support it long-term?
• Are you building to avoid a 10% gap or because nothing exists?

The general principle: Don't build internal tools that replicate 90% of what external tools already do. The remaining 10% is rarely worth the lifetime cost of ownership.

Personal Updates & Tangents

The standup section includes home renovation updates (mini splits and solar panels), Scott's Rhode Island trip plans, Dillon's Web Guild leadership experience at Whoop (described as "group therapy for front-end engineers"), and Matt's build performance optimization work that might actually be making things slower.

Whether you're an engineering leader making tooling decisions or a developer maintaining legacy internal systems, this episode offers hard-won wisdom about the real tradeoffs in the build-versus-buy debate. Sometimes the answer is "build," but more often than not, it's "please don't."