Use Boring Solutions

Leider ist der Eintrag nur auf Britisches Englisch verfügbar.

Often when working with both startups and project teams at larger, more seasoned companies I encounter a variation of the not invented here syndrome.

This usually starts with the well-intentioned idea that in order to build the actual product you need ancillary services A, B and C in order for the product to work.

However, more often than not instead of building the ‘perfect’ solution for your product yourself it might be a good idea to take a step back and think about if there might be a less than perfect but perfectly adequate solution to the problem. This solution might come in different flavours such as 3rd party services, existing tools that just need some orchestration to fulfill the purpose or simply by winging it and implementing a partially scripted, partially manual process.

The problem with the elusive perfect solution built in-house is that it takes time away from your actual product and drains your team’s energy.

Interestingly, with developments like containerization and DevOps and the widespread use of application infrastructure such as monitoring and logging this phenomenon seems to have become more prevalent again.

Occasionally, I come across companies and teams that try to solve what for myself I’ve termed “nerdy non-problems“: In lieu of working on their actual product and most importantly that product’s market fit they spend a lot of time and energy on first implementing the perfect, “scalable” deployment infrastructure (“You know, because we’re going to be the next Facebook …“).

This frequently is an utter waste of time.

Don’t get me wrong. It’s important to spend some thought on your infrastructure and how your software will be deployed but the keyword here is some. As usual, the Pareto principle applies: Most of the benefits will be reaped from implementing a working solution that’s maybe a bit rough around the edges. Additional benefits on top of that come at a tremendous cost.

The elephant in the room is: There’s an opportunity cost to everything.

If you waste time and energy on something that’s only of secondary importance to your business you’ll have less energy and time at your disposal to spend on those aspects of your business that actually matter!

Hence, only build something yourself if it works as a key differentiator for you. If you absolutely have to build it yourself do so by using standard tools first. You can still automate and optimise later.

In other words: Use boring solutions to secondary problems and spend your precious time on working on your actual problems instead!