Published in


Make your own tools.

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?

You have a chance to invent a new approach

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:

  1. There is a chance that a new tool will lead to a new approach. This might give you an edge in competition. In our fierce and rapid world any edge is invaluable. If you can increase UI development speed by 20% you may win the race with some major competitors. If you will interact with customers better you may significantly improve conversion rate and reduce churn. Quite often risk to loose this opportunity outweighs all expenses.
  2. Your unique tools may lead to unique products. When you invent new technology or new tools, you open up new product opportunities. Pixar had been making own software (and hardware) for years to enable 3D graphic movies. Amazon created AWS to solve internal scalability problems and changed the way how to buy things.
  3. When you build your own tools you learn a lot. You become an expert in the field with deep knowledge and deep understanding of the domain. If you build JavaScript frameworks, you become a better JavaScript developer. If you build CRM, you learn how customers interactions work. In case of product failure you still accumulate knowledge and can make something great in the next iteration of your life.
  4. It is fun! Unfortunately, fun is beaten out of corporate world. This is sad. Life is short and you should have fun at your workspace.

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

You solve existing problem and might create a great product

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.

We are having fun creating Fibery — process agnostic work management platform. Go see what it means 🐛.




A second brain for teams. Replaces costly isolated tools and brings teams together.

Recommended from Medium

Personalizing Terminal and the macOS shell — a developer must

HackerRank 30 Days Of Code: Day 13 — Abstract Class

Tutorial Using GIT and Connect to Github for Your Project in Pycharm

Wow No Gcd Hack 3.3.5 Download

A Conservative Case for Concerns

Python Ctypes for Loading and Calling Shared Libraries

What is NoSQL?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Dubakov

Michael Dubakov

Fibery founder I write about systems, software development and products.

More from Medium

SDD Conference Top Takeaways — Evolutionary Architecture

Venn diagram showing fitness functions as the central ellipse, and each of monitors, unit tests, metrics, chaos engineering and new stuff overlapping the fitness functions ellipse but not each other.

How to Choose the Right Project Management Tool

Tools vs Process

How Low-Code Accelerates Agile Development?