Not Invented Here is a popular mantra in many companies. Majority thinks that you should focus on business value, and all other things are secondary. Let’s take a small company of 20 people that creates iOS Apps. Obviously, you should use existing tools for coding, tasks management, team communication, continuous integration, CRM, recruiting, marketing analytics, etc. Should you build your own chat? Create your own internal task management software? Invent your own CRM?
“No!” is a no brainer answer to all these questions. You should focus on your area of expertise: create iOS Apps and do nothing else. Or should you?
I believe the situation is more complex. Imagine you start making (and use) your own tools. What benefits you’ll get?
When you make your own tools, you have a chance to solve problem differently and better. That is, in a nutshell, how we invent things.
In software development there are thousands of examples. Every major company invents few JavaScript frameworks. React was created by Facebook (and it is good). Angular was created by Google (and it is not so good). Uber, AirBnB, Alibaba, Microsoft — so many companies created own JS frameworks and tools. From the industry perspective this is great! We have competitive ecosystem where good frameworks shine and bad frameworks die. But it is hard to say who will win analytically. You have to build stuff and push it to the wild world. The world will use it, evaluate it and score it. We have evolution of ideas, mutual influence and mutations. Companies learn from each other and move frontiers forward.
Evolution of JavaScript frameworks. Source.
From specific company perspective it may look like waste of time and money. In some cases it is. But in some cases it gives enormous benefits:
We write all of our own tools, no matter what project we’re building. Pretty much anything that we’re doing requires some sort of design tool that didn’t exist before. In fact, the design tools that we write to do the projects that we’re doing are a sort of product in and of themselves.
I think in reality, today, if you use the same tools as everyone else, you kind of build the same products. If you write your own tools, you can sort of see new things, design new things. — Saul Griffith
The tools you’ll make will have at least one fervent user — yourself. Indeed, you have this problem, this burning need. You make a tool that solves the problem. There is a very good chance that other people or companies have exactly the same problem as well. If you really enjoy your solution, there is a good chance that other people will enjoy it too.
In a conversation with potential customer you have rapport and resonance. You fine tune your mutual problems, exchange ideas and feel motivated. You can feel your own pain, but it is extremely hard to have similar feeling if problem is not yours.
Thor’s internal tool spectre. Source.
How often startups try to solve a problem that does not exist at all? How often we try to climb abstraction ladder and invent a problem that is hard to comprehend and explain? When you build a tool to solve your own problem — everything is deadly explicit. This explicitness guides your decisions, your vision and your product (or service). It helps you to reduce ambiguity, select important feature and release something early. It helps to validate value and spot bad ideas that don’t work. Everything becomes much more simple.
How many great products, companies and technologies were created this way? There are many: Basecamp, Git, Slack, AWS, GitHub, Twitch, Apple, Patagonia, Docker, Linux, Clojure, Holacracy, etc.
I don’t think you should make all your tools. But at least you should make some of them. This is the path to novelty. And fun.