Choosing DIY in home improvement is often a cost issue. In home improvement, you save on expertise and experience to build cheaper, but that is not really the same in building software. DIY in software still requires experts with experience, so this changes the discussion to a build vs. buy discussion. The build vs. buy discussion is often a business discussion, but in this post, we want to take the engineering perspective.

Enterspeed is helping developers deliver high-performing global APIs with no infrastructure, and one way to describe our platform is as a SaaS middle-layer. We often find ourselves involved in discussions with other engineers about the pros and cons of a DIY middle-layer. It will not be a surprise that we will tend to advocate for choosing to buy when you are in need of a middle-layer for your next composable web project.

Even with the SaaS vendor's bias, we do understand why DIY is chosen for some projects. As software engineers ourselves, we sympathise with the urge for writing code, and we believe you should write your own code when you need to support unique business requirements and/or when you need to have full control.

Business uniqueness

Business uniqueness is a tricky parameter to assess. When you are inside the business, you have a tendency to regard yourself as a unique business doing things in a unique way. On the opposite perspective looking outside in, you have a tendency to assess a business as more standard. The outside-in perspective doesn't fully comprehend the intricate details of the business. Satisfying what appears to be a unique business requirement is often the reason to go with a DIY middle layer.

Control

Control is the other argument we hear for going down the DIY route. This is a reasonable argument, but the counter argument is that more control comes together with more responsibility. The more code you write, the more code you need to maintain and operate. Building and operating high-quality software requires more and more knowledge and manpower. You need to consider the total lifecycle of the software - and a simple question you need to be able to answer is: who will maintain this software in 2 years?

The force of laziness

With the concepts of uniqueness and maintenance established, we can get back to the DIY trap. The DIY trap is a bit of a paradox, as software engineers are lazy by nature and many actually want to reuse components and third-party software. But perhaps this is also an explanation, as understanding the code you write yourself is easier than learning and fully understanding a third-party tool. With this understanding, laziness becomes both a force that pushes engineers down the DIY path and one that could lead them towards a third-party tool.

The question you should ask yourself is, if DIY is a trap that will set you up for a never-ending trail of maintenance and missed business opportunity or it is the advantage that allows your business to scale and innovate?