Landa Function

Many tech founders wonder which technological decisions are going to help them build a successful company. Founders that sold their company or went to an IPO tend to talk about the culture, the spirit, and the core team but they usually leave tech decisions out of this scope. After 15 years of working in the Israeli tech industry in different roles, including being a consultant and working for Armis Security, I started to see patterns of decisions that successful startups tend to take.

Start with DevOps practices from day one

You have an idea and you start proto-typing around it. Sooner or later you are going to have an application (mobile/web or backend). It is going to run somewhere and have some impact on the world. Even if it’s only 1000 lines of code, you should start using source control (Git) and keep consistent naming conventions for branches. It will help you prototype faster and after having a working prototype you can throw this Git repository and start a new one from scratch. Source control is not enough, you should also have an automated build and deployment. “Dockerizing” (putting the application in Docker) is even better. Nowadays you don’t even need to have your own CI server, you should use managed services like Travis or Circle CI and Github/Gitlab for Git. Why? Because having a 1-click demo reduces stress and ensures stability before meeting potential investors. It will also make the life of the non-technical founders much easier.

Small data big insights, take care of BigData later

Building BigData infrastructure is complicated and costly. It requires experienced developers, choosing the right data store for your data and complicated code that works around the datastore limitations. If you are not developing a BigData service per se don’t go there. Handling small data applications is a solved problem. There is a wide variety of databases such as MySQL, PostgreSQL and even document databases like MongoDB that will work great with your data. These databases are battle proven and come with mature tooling and developers that already know how to use them.

Monolith first, microservices later

Microservices are one of the hottest buzzwords in the last few years. When starting a new startup it is tempting to start writing microservices from the first day, defining a good domain and separating concerns. But what most developers forget is that microservices come with a complexity price. Microservices require common infrastructure, orchestration, and dedicated deployment tooling. When your domain is not fully defined and your startup contains up to 10 developers, microservices will probably hinder more than help. It doesn’t mean that the code you write shouldn’t be modular, we used to write modular code even before we had microservices. I recommend not to bother writing microservices until you have a good grasp of what you are aiming to build.

Adopt cutting edge technologies and avoid bleeding edge ones

At the beginning of a startup, you have lots of different concerns about hiring, finance, culture, and whatnot. The last thing you want to worry about is having your demo environment crashing because you chose to use a database because it got 1000 stars on Github. Even though the temptation for using the latest technology is high and it seems that it fits exactly to your business requirements, try to keep to cutting edge technologies or even just “good all fashion working technologies”. Cutting edge technology is the latest technology proven to be working (or at least partially working). It doesn’t come without risks but it is stable enough to use and can attract good candidates for hiring that are looking for work opportunities to gain experience with new tech.

Disclaimer: All of these decisions helped startups to grow faster and find product-market fit better. It doesn’t mean that if you don’t follow these decisions you will not succeed.