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.
