Not Invented Here
Not Invented Here is an anti-pattern where teams refuse to adopt external tools, libraries, or ideas, preferring instead to build and maintain their own solutions from scratch. This behavior leads to unnecessary reinvention, higher maintenance burden, and slower time to value.
Background and Context
Many engineering teams take pride in solving hard problems. But when that pride turns into rejection of outside solutions, it creates inefficiencies. Avoiding external ideas not only wastes time but often results in building inferior versions of tools that already exist.
The result is duplicated work, brittle internal solutions, and a lack of focus on solving customer-facing problems.
Root Causes of NIH Syndrome
This anti-pattern typically stems from team culture or past experience. Common causes include:
- Pride in internal technical capability or engineering purity
- Past failures or integration pain with external tools
- Belief that external solutions are too complex or generic
- Underestimation of maintenance cost for homegrown systems
Inventing something is often easier than maintaining it forever.
Impact of Reinventing the Wheel
Choosing to build instead of buy or borrow has long-term costs. Effects include:
- Slower time to market due to duplicated effort
- Increased maintenance overhead for internal tools
- Reduced feature richness compared to mature external offerings
- Missed opportunities to learn from broader ecosystems
Internal focus should accelerate delivery and impact, not isolate teams from proven solutions.
Warning Signs of NIH Behavior
This anti-pattern tends to emerge in platform decisions and architectural choices. Watch for:
- Teams dismissing tools or patterns with “we’ll just build our own”
- Critical systems maintained internally despite available alternatives
- Poorly documented or rarely updated internal tooling
- Engineers unaware of standard approaches to common problems
If every system is bespoke, collaboration and onboarding suffer.
Metrics to Detect Not Invented Here
These minware metrics can signal inefficiencies caused by duplicating existing functionality:
Metric | Signal |
---|---|
Cycle Time | Long delivery timelines suggest internal build efforts are slowing value delivery. |
Rework Rate | Frequent changes to internal tools reflect design churn or incomplete implementation. |
Work in Progress (WIP) | High concurrent work may indicate duplicated systems or internally scoped efforts that increase delivery load. |
Metrics help highlight where custom tooling is draining focus from core product delivery.
How to Prevent NIH Thinking
Preventing this anti-pattern requires cultural humility and outcome-driven decision-making. Recommended practices include:
- Evaluate build vs. buy tradeoffs for every platform-level decision
- Reward teams for delivery outcomes rather than architectural ownership
- Include maintenance and support burden in planning decisions
- Normalize use of third-party solutions and open source adoption
Smart teams borrow proven solutions so they can focus on building where it matters.
How to Phase Out Unnecessary Internal Systems
If NIH behavior is already embedded in your team:
- Inventory internally owned systems and assess external alternatives
- Migrate low-value custom tools to standard solutions with wide support
- Redirect team bandwidth to product-facing problems, not infrastructure reinvention
- Share examples of successful integration efforts to rebuild confidence in reuse
Building everything in-house may feel empowering, but it limits how fast and far teams can go.