Featured
Every organization, at some point, faces the question: should we build this ourselves or should we use what already exists? The instinct to build often comes from a genuine place. Leaders and teams want control, flexibility, and the confidence that the system they rely on is shaped exactly to their needs. After all, if it is built internally, every feature, workflow, and integration can be fine-tuned to perfection.
But this instinct can also lead to inefficiency. When the focus shifts from solving the real problem to creating tools for the sake of ownership, organizations find themselves pouring time, money, and talent into reinventing what is already available. Mature products and open-source frameworks exist for nearly every business need, yet they are sometimes dismissed in favor of starting from scratch.
Basically, the “Not Invented Here” syndrome kicks in.
Not Invented Here Syndrome ft. Oppenheimer
The NIH syndrome is a term used to describe a mindset within a team or an organization, where there is resistance in using existing, proven, or open-source solutions and instead an insistence on developing everything from scratch. Usually, what underlies this syndrome are a number of beliefs:
- Acquiring external expertise is costlier than developing them internally.
- Existing solutions cannot sufficiently match the specific requirements and desired outcomes.
- A sense of excessive confidence, suggesting that no one else could develop something as good as the organization itself could.
The sense of ownership and control that comes from having built something in-house is greater than the actual need to solve the problem.
“Regardless of what we create–a toy box, a new source of electricity, a new mathematical theorem–much of what really matters to us is that it is our creation. As long as we create it, we tend to feel rather certain that it’s more useful and important than similar ideas that other people come up with.”
– The Upside of Irrationality, Dan Ariely
In the pride that we have for the system, we get too attached to it. We get down into the field haggling with the nitty-gritties instead of taking a step back and seeing the big picture.
This can be witnessed in looking to build resource and customer management solutions when the likes of Zoho and ERP Next exist, eCommerce from ground up even though Shopify, WooCommerce and entire libraries and projects in open source are available, and chat for communication when Intercom and WhatsApp Business API offer more standard ways.
The Downsides of NIH
Let us look closer at the downsides of NIH.
- Cost: There is always a cost associated to any system. The cost of building a system from the ground up is always considerably higher as you have to taken into account every small module that your system should have.
- Reinventing the wheel: Often, existing solutions have been tested, optimized, and maintained by a broader community of developers. By disregarding them, a team may miss out on potential benefits and improvements when re-inventing the wheel.
- Time: Additionally, developing everything from scratch can be time-consuming and resource-intensive. As resources are directed to implement every aspect, the time taken increases, not to mention scope-creep that comes in during development.
As more time is spent on fine tuning the product, there are high chances you outgrow the very problem you set out to solve. - Maintenance: Finally, after building a system, there is always an overhead of maintenance to the keep the system running smooth and secure. Building and maintaining in-house solutions can become a burden, especially if the team lacks the necessary expertise or resources to handle it effectively.
So, when do we Build from Scratch?
Sometimes, existing solutions may not perfectly fit the specific requirements of a project. In such cases, building a custom solution can lead to better alignment with the project’s needs.
Building your own solution also allows you to eliminate the dependencies. This will allow you to keep your projects light and build a core module that serves the purpose without too much external baggage.
“Find the dependencies — and eliminate them.”
Finally, identify your core business competencies and objectives, and ensure those tasks are carried out in-house.
If it’s a core business function — do it yourself, no matter what.
Make sure to have the development in-house for functions critical to your business, esp. if it is proprietary. You can integrate or delegate the non-essential and standard use-cases.
In Closing
The “Not Invented Here” syndrome can be a double-edged sword in the world of software development and innovation. While it can provide a sense of ownership and control over the solutions, it also comes with significant downsides, such as higher costs, increased development time, and missed opportunities for improvement.
Embracing existing solutions and building on the foundation of others can accelerate progress, allow for innovation, and prepare development teams to be adaptable.
Oppenheimer and his team faced the challenge of needing to invent and develop many new technologies to achieve their goal.These technologies were built upon the foundations and discoveries made up until that time. If all scientists had to begin from the beginning, questioning fundamental assumptions, they would be hard pressed to reach the level of technical sophistication necessary to do useful work.
Finding the right balance between custom development and utilizing external solutions tailored to specific needs is essential for innovation and in optimizing productivity and sales.
References
- Not Invented Here Syndrome Explained
- Why I am an Ethical Thief
- FRIDAY’S WORDS OF WISDOM: THE UPSIDE OF IRRATIONALITY BY DAN ARIELY
- In Defense of Not Invented Here Syndrome
At Coffee, we help organizations make this decision with clarity — when to build, when to integrate, and how to strike the balance. If you are exploring whether to build or integrate for your next project, let us talk.
