Key takeaway (TL;DR)
Not Invented Here, or NIH, is the bias that makes design and engineering teams reject a solution because it originated elsewhere and insist on rebuilding it themselves. JVDS believes digital-product decisions should be based on business fit, system complexity and maintenance cost, not on who created the solution. Thoughtfully adopting and integrating established external components and standards can reduce internal friction and improve delivery efficiency.
1. The hidden cost of starting over: lessons from business history
During product development and system redesign, teams often reject existing work because an external solution supposedly does not fit the business closely enough. Rebuilding is not free, however. Dismissing established assets can create substantial system-level costs:
- Ecosystem compatibility and the loss of user assets: Timex's T/S 1000, introduced in 1982, was highly compatible with the Sinclair ZX81 and succeeded. Its later T/S 2068 pursued a proprietary architecture that disrupted compatibility with the Spectrum's rich software ecosystem and soon lost ground with developers and users. In product evolution, abruptly breaking established interactions and interfaces can impose high learning and migration costs.
- Asset inheritance and unclear improvement targets: after acquiring the Sonicare electric-toothbrush business, Philips did not discard its established drive mechanism and brush-head ergonomics. It retained core engineering assets while integrating the brand presentation and industrial appearance. Meaningful engineering evolution identifies what to preserve and what to rebuild; starting over should not conceal an unclear objective.
- Closed control versus an open ecosystem: Sony's early AIBO robot dog became the focus of disputes over copyright and blocked interfaces when third-party users wrote extensions such as dance routines. Netflix took a different approach in 2006, offering a million-dollar prize for outside algorithm teams to improve its recommendation engine. Organizations able to absorb external knowledge can often move beyond performance limitations more quickly.
2. Four deeper reasons teams resist outside solutions
Organizational psychology and incentives can combine into a chain of resistance to useful external work:
- Overconfidence in internal capability: success in a limited set of previous projects can create technical or aesthetic superiority. Familiar stacks and interaction patterns become unquestioned doctrine, while better shared standards are ignored.
- Defending control: external frameworks and open-source components can disturb established responsibilities and comfort zones. Teams may resist because they fear losing technical ownership or influence.
- Credit and prestige: when evaluation rewards internally written code or total in-house development, teams can confuse rewriting with productive output and undervalue reuse.
- Attachment to sunk costs: effort and emotional investment in an inefficient early solution make it difficult to abandon weak code, drawing the team deeper into unproductive rebuilding.
3. A four-dimensional build-or-adopt decision matrix
For corporate website design and complex enterprise systems, the following matrix helps teams assess solutions without bias toward their origin:
| Evaluation dimension | Core functions or assets | Occasional supporting functions or assets | Redundancy or superficial differentiation |
|---|---|---|---|
| Basic interactions and component libraries | Integrate established open-source approaches such as AntD, Tailwind and Radix, drawing on their accessibility and compatibility work. | Create limited extensions and micro-interactions around the company's brand palette. | Rebuild every button, date picker and dropdown from scratch merely to make minor visual adjustments. |
| Business logic and architecture | Develop proprietary calculation flows, fulfillment models and transaction engines that support the company's distinctive commercial value. | Use standard OpenAPI interfaces and established SaaS authentication or data services. | Reject shared protocols in favor of an obscure private communication format without a clear need. |
| Content and design assets | Develop distinctive brand symbols, high-quality industry photography and a tailored vector-icon system. | Acquire legitimate third-party font licenses and supporting vector assets through a controlled process. | Redraw every ordinary status icon, doubling production time while producing less legible results. |
| Decision criteria | Evaluate delivery time, robustness, maintainability and business conversion value together. | Conduct limited technical sandbox tests and disaster-recovery exercises for exceptional scenarios. | Judge acceptance solely by whether code was written internally or the visuals are completely unlike anything else. |
4. Open collaboration in JVDS practice
In digital-product development and brand consulting, JVDS uses shared standards and outcome-focused collaboration to help clients break down knowledge barriers:
- Make build-versus-buy reviews transparent: before beginning a redesign, require a lifecycle maintenance-cost comparison between rewriting and adopting a mature external solution. Rejecting a framework should be supported by specific evidence about security vulnerabilities, concurrency limits or business incompatibility, rather than subjective preference.
- Run lightweight sandbox tests and local pilots: trial an external approach in a peripheral business module or a selected page before broader adoption. Use conversion, loading speed and error rates to inform the decision.
- Reorient performance evaluation: reward the speed of solving business problems, launch stability and code reuse. Skillful use of established industry assets should count as valuable professional work. Explore our design work for examples of complex-system collaboration and digital brand development.
5. Frequently asked questions
Q1: Will adopting external components make the product lose its brand identity?
No. Fundamental interactions such as grids, inputs and modal behavior should align with familiar mental models and accessibility expectations. Novelty for its own sake often adds cognitive load. Brand distinctiveness should concentrate on clear communication, a coherent visual identity and an exceptionally smooth core business journey.
Q2: How can we judge whether an external solution fits the existing architecture?
Assess four areas: community activity and maintenance, including whether updates have continued over the past six months; extensibility and style isolation; licensing and permission for commercial use; and migration or decoupling cost, including the impact of replacing it later.
Q3: How do we persuade a team accustomed to building everything from scratch to adopt open source?
Frame the discussion around focusing on high-value core work. Rebuilding basic infrastructure consumes attention that could address strategic problems. Releasing that capacity for retention, conversion-path improvements and the company's distinctive capabilities can do more for the team's professional reputation.
