Blogbeitrag DIY-Software Teaser

DIY software: Why it's the one and only way to do it and everyone else is wrong

David Beuchert, Tech Lead E-Commerce - Jan 3, 2022

A few years ago, I talked at a panel at code.talks commerce in Berlin. I said that we never use standard software and that everything we use was developed by ourselves. Just like my provocative headline that was a lie of course. But when I look at the development of our industry over the last few years and compare that with the way we approach solutions as a team, I see that there are differences between us and the rest of the world. And these differences are increasing rather than decreasing.

My statement at the time still doesn't hold true but somehow, it's a matter of perspective. In this post, I'd like to shed some light on our perspective and despite the fact that my headline is just clickbait, promote building software yourself more often and use standard modules less often.

First, let’s agree on semantics

What do I actually mean when I say that we do things differently than the rest of the world? No e-commerce company close to our size can afford to just install Magento (or Woocommerce or who knows what) and fill it with content. Our stores have to be agile and stand out from the rest. In addition, our customers develop special wishes that we have to cater to. That means that at some point you’ll have to hire at least one or more developers who build exclusive features.

By the way, it doesn't work the other way around either: No company in this world can afford to develop everything on their own. We use operating systems, programming languages and their compilers/interpreters, web servers, databases and code versioning tools, none of which were developed by us. Every now and then companies develop their own programming languages: Apple has Swift, Google has Go, Mozilla has (or had) Rust, and JetBrains has Kotlin. I can't say whether each of these have been worthwhile. What I want to say is: You and I, we are simple people, we will always use ready-made software in some capacity. In Thomann's case, that's software like PHP, MySQL, git, node.js, nginx, etc.

Being on the right path for the right use case

Once again, this topic seems to boil down to the appropriate shades of gray. It's all the more irritating that when I'm talking to devs, CTOs and leads from outside the company, I often get the feeling that I have to justify our approach to in-house development. It's not uncommon for me to find myself in the defensive. But we, like everyone else, are proud of what we have created and above all how we have created it. We serve a niche market that craves a level of detail that standard software cannot provide. It is part of our DNA not to lower our expectations to the limits of available technology and it is probably our Franconian madness that we believe we can always do better.

Always?

Okay, you got me there: That was another lie. We prefer to stay out of areas like enterprise resource planning, logistics and financial or payroll accounting. The complexity of these problems exceeds our available headroom. However, when it comes to thomann.de, there is hardly anything we would give up control over.

For example, the store framework is a complete in-house development. Request and response handling, routing, the handling of the entire application flow: Everything was built in-house. This gives us priceless creative freedom for functionalities and presentation in the store. We can implement solutions at all software levels. The same applies to content maintenance and housekeeping tools. We design our processes and the software maps them, not the other way around.

There are also other components that needed custom solutions. For example, our service that calculates when orders will be with the customer. As well as our service that knows shipping rules for over 160 countries, including specifics about cities and zip code areas, and is able to apply them at check-out in real time.

And lastly, there are components that are so specialized that a standard solution would not even come close to what we need: For example, Stompenberg FX. It’s a software that can make analog effects units digitally controllable and at the same time visually conveys the feeling of the real effect. This didn't exist before we came up with it and built it.

Everything used to be worse

These days, when I encounter a problem, I know that someone has probably already solved it before and that the solution is somewhere on the internet. If the question was not too simple, it’s on Stackoverflow - and otherwise on gutefrage.net (German website like quora.com).

thomann.de exists since 1996. Stackoverflow launched 12 years later, npm 14 years and Composer 16 years later. Most of the store systems known today also appeared years after the first revision of our online store. That means the number of ready-made solutions to draw from was close to zero.

Shop development at Thomann before Stackoverflow went live

So the basic situation that you either develop software on your own or a feature will not exist on your website, we encountered for at least 25 years. However, the use cases have changed a lot. Nowadays, there is standard software that is so good that in-house development can no longer be justified. Things like template engines or test frameworks were developed in-house 10 years ago. That’s hard to imagine today.

In addition, the entire IT industry is learning how important it is to keep components small and expandable. This includes many headless systems that take care of the work we don't want to deal with but give us time to take care of what's important: What our users see. In addition to the smaller components, standards have been established that allow interoperability between standard and custom components (a good example are the PSRs in the PHP community).

So what’s what?

You need to find the right balance between purchasing components and developing in-house. To do that, you usually have to listen to your gut feeling. There are no metrics or blueprints to draw from. The cost of purchasing may be calculable, but the dependency you are putting yourself into is not. The same applies to a development team: You can calculate what a team costs per sprint, and hopefully they correctly estimate the time needed. The fact that during that period, the team is not available to develop other features that may add more value, could be a risk factor.

Time for the crystal ball: What does the future hold?

Component requirements will continue to become more complex, especially when looking at the performance and the level of detail to be mapped. It will become more important for us to work with specialists who focus on sub-areas. We also need to make those sub-areas smaller so that the expertise can be retained in the respective field.

For us, this means that we will have to adopt standards better and faster and above all, learn to evaluate standard solutions concretely. Otherwise, we run the risk that our pride in self-developed software will prevent us from implementing better solutions or that we will not be able to implement them if we have not created the necessary interface standards.

There will still be situations like us having ideas that no one has had before or us running into problems that no one has solved yet. Then we will do what we always do: We will build the solution for it. 5-10 years later there will be standard solutions to these problems and we will keep discussing why we prefer to do our own development.

Our offices

Remote. Distributed. Together.

Work from home or any of our offices. Our team is 100% remote and will stay this way. You need a stable internet connection and your laptop.

Treppendorf

Our Thomann headquarters. Just a few minutes drive outside of Bamberg. Come by to visit our shop or meet with colleagues apart from tech & data.

Berlin

Our thomann.io office in the heart of Berlin. Easily reachable at Rosenthaler Platz. Perfect for workshops and team building.

Erlangen

Our thomann.io office in Nuremberg's metropolitan area. Just a few minutes by foot from Erlangen station. Nice, quiet location to do some deep work.

Our thomann.io Blog

May 13, 2022 - Ralph Cibis

Thomann.io goes Cyberpunk

We went fully cyberpunk! Our branding community's last side and heart project.

Jan 3, 2022 - David Beuchert

DIY software: Why it's the one and only way to do it and everyone else is wrong

My provoking approach wooing for more in-house development.

Dec 8, 2021 - Nadine

Going fully responsive

Why we redesigned our shop - and why purple's the new blue.

Oct 18, 2021 - Julia Manger

Open Space 2021

Summer 2021 - Home office, lockdown, a fourth wave and: huh?! An Open Space!

Aug 6, 2021 - Stefan Stammler

Bits, Beats, Ops-Team

Someone needs to bring our shop online. This is our mission.

Jul 7, 2021 - Ralph Cibis

Hello, Webteam

We are the Thomann Web Team. We create thomann.de and the Thomann App.

Jan 27, 2021 - Nadine

What Kan Kanban do

The idea behind moving cards - with a crispy epilogue.

Oct 11, 2020 - Julian Kern

ThomannUI: Der Beginn einer Component Library

Ein Einblick in die Component Library auf Basis von React von Julian Kern

Sep 7, 2020 - Francesco

Guitars to Oslo or: The Art of Offering the Right Shipping Methods

Our developer Francesco provides you with behind the scenes insights

Jul 14, 2020 - Thomas Tischner

How Thomann is mastering the move to Kubernetes

Our Sysadmin Thomas tells you from his day-to-day work

Dec 9, 2019 - Julian Kern

thomann.io v2

Frisch aus dem Kühlregal: Hier ist das neue Frontend!

Nov 4, 2019 - Domi

Thomann Dev Camp 2k19

This year under the Slogan "ready for our collective take-off".

Aug 24, 2018 - Julia Manger

Das Thomann Dev Camp

Wir wissen, was das Dev Team letzten Sommer gemacht hat. Ein Einblick.

Severe case of I-wanna-work-with-you?

...or any questions to us? Give Anni a call!

Welcome to Treppendorf, welcome to Thomann Music

We're inspiring and enabling people to speak music, everywhere. 24/7.