Top 5 Challenges in startup software development

Motivation and scope

I’m a tech lead and software engineer from Germany who did work for more then ten years in different companies in various industries mainly in the startup environment. Within this time I have seen repetitive patterns and reasons why startup companies do sooner or later struggle with the software they have implemented. This article is the start of a series of reports based on my personal experiences. It is not a scientific article and you may have experienced different scenarios and may have found different explanations for the scenarios I describe and that is fine. I decided to share my experiences in this series because I hope it might help other tech leads, engineers or entrepreneurs in building better software in the startup environment from day one or to get their current challenge they might face faster in control.

In this article I will give you a brief overview of the challenges I faced in almost every job. I grouped them into 5 main topics and will give you a brief insight. In the following articles I will explain each one more in depth and also describe the strategies I have researched, adjusted and developed on my own to deal with those challenges.

Challenge 1: Choice of tools and Frameworks

You have an idea and want to bring it to live. So far, so great! One of the main questions now is: how to start? There are so many programming languages, frameworks and other tools available that even experienced software engineers often have a hard time deciding for the right ones. As always in life, each benefit will come with downsides you need to take in consideration. Example: imagine you decided to buy a new car. If you decide to buy a camper van you get a lot of space and could use the car to sleep in it if you want to. Two downsides may be that you have to pay a higher amount of money and may need more time to find a parking slot which is big enough especially in bigger cities. If you decide to go with a compact car you will likely pay less and also find a parking slot easily, but you have to compromise on the space available and sleeping in the car will not be very comfortable. Your decision depends on your desire and, in startups not infrequently, on the money you have available.

The same pattern applies for frameworks, programming languages or other tech related decisions. Developers of programming language X might be simpler and cheaper to hire as one of programming language Y but therefore that language might be not as performant as the other one.

Challenge 2: Technical debts

If you want to buy yourself something very badly but you do not have the money you may consider taking a loan. Usually this is not a big deal, but if you take another loan and another and another you will soon find yourself in the situation that you can’t pay off your debts anymore. So making debts may not necessarily be bad in the first place but you should pay attention that you keep them in control.

When we talk about technical debts in software engineering we mean something very similar. It is okay to take a shortcut from time to time to achieve a new feature or prototype of a new idea fast, but you should pay attention that you do not do this over and over again without fixing the previous edge cases or bugs which were caused by the shortcuts you have taken.

If you don’t pay attention to it you will find yourself after no time in the situation where your team will have to spend more time fixing bugs, outages and implement workarounds instead of being able to develop your product further. Based on my experience I’m sure that at least one of the three mentioned scenarios is something you might have experienced as well if you made it so far through the article ;)

Challenge 3: Team capabilities and experience

“Experience is simply the name we give our mistakes”, this quote by Oscar Wilde is one of my favorite quotes. It shows where experience and therefore a big part of our capabilities comes from. You can read tons of books or watch tutorial videos to gain knowledge. To learn to use this knowledge efficiently you need to apply that knowledge in practical scenarios. And those practical scenarios are often leading to circumstances that books or videos do not cover and then you need to adapt and you will make mistakes in the beginning. Some will be bigger and some smaller, but they all will count into your personal experience if you are willing to learn from them.

I have seen a lot of inexperienced engineers in early startup stages. By this I do not only mean their technical knowledge. Knowing how to act in a crisis situation like a server outage, how to ensure meaningful monitoring or how to share workload and knowledge are key abilities for successful software engineering teams, which do require a certain level of experience aside from technical skills. I saw this often missing when I joined teams and that led to various crucial impacts which could have been way less impactful if you would have had those skills in place.

Challenge 4: No awareness of data value

A couple of years ago I discussed successful and unsuccessful startups with a former colleague of mine, he said a sentence that is still in my head: “Startups are successful if they are able to learn and adjust fast.” I can confirm that, because I experienced huge differences in the speed of a company’s development when a company was making the decisions based on facts and insights versus companies that decided based on gut feelings and assumptions.

To be able to make fact and insight driven decisions you need to define meaningful KPIs and gather data which does support the measurement of them. It may sound simple and self-evident to you if you read those lines… I can assure you it’s not.

I remember one company that did a tremendous job by working fact and data driven from day one. Even though we struggled to clean, filter and validate the data (like in every position I worked in), we celebrated all kinds of insights we could get. Compared to my other positions I need to say that we achieved a lot of learning for a way lower price.

Challenge 5: Security

The security of the application code is the area where I have experienced the biggest gaps and risks in almost every team and company. Non technical persons often do not know about the connected risks and the early stage startup teams are often so under pressure that they do certain things even though they know that it creates a risk. Hardcoded passwords in application code or weak password management are just two examples I have seen in almost every company I worked in. Despite the fact that a successful cyber attack will harm your business tremendously if the news about it gets public, you should also know that missing security related actions do lead to tech debts, which can be very expensive to fix or to continuously work around the given solution.

Just assume how expensive it would be, to own a big building complex with more than 1000 hired out flats and suddenly you realize you have to hand out new keys and locks to all flats at once because you received a report that one key can open multiple flats. You could lower the initial costs by adding additional cheap security layers to cover the big effort like adding a key card or additional pin for each flat. If you do so, you will have two systems instead of one to manage and maintain and that means you need to pay additional costs to lower a pain that could have been solved with an initial higher investment in the long run.

Thanks for reading all along if you made it so far. I hope I caught your attention. As promised in the next weeks I will add additional articles to describe each challenge in depth and how they can be solved. Looking forward to the feedback