Why startups fail
You have a great idea! You’ve found a niche in the market and know that your solution will be the best fit for it. You investigated your idea and already have potential customers. OK, let’s build the product, this is the easy part. WRONG!
As you already know, a lot of startups fail. Let’s look at some statistics in 2023.
Starting a startup is in the first place a market test. The customers will love your product or they will love your competition more. Your product must be better than the competition or must change faster (like Darwin’s theory).
Let’s see why startups fail:
3 most common reason groups are: 1) market and competition, 2) product and team, 3) financing, pricing, and business model.
There are a lot of articles about market fit, financing, and competition. Also, there are a lot of articles about technologies, frameworks, databases, AI, and technology in general. To reduce the risk of startup failure, the technology and team behind must meet the market needs and business model in perfect balance. If you fail in one of them, your startup will fail.
How to increase a chance to survive longer on the market
I will start with MVP (Minimum Viable Product) or the most desired feature that the market needs and how to assemble one. MVP is the most essential part of any startup, everybody starts with some small idea that can quickly be accepted by the market, or fail. MVP is the idea presented in a product that the customers can use and they see a value in it. Do you need to spend a lot of coding to test value? No, there are several solutions how you can test the value on the market, like the Lean Startup approach or similar. In essence, you can put some mockup or presentation together and hit the market with it, and you will soon get a response if your idea is valid or not. Do not start coding or heavily invest until you verify that your idea has market potential. It’s a golden rule of any business.
The other part is technology and the team behind the MVP. You choose or influence both of them. There’s a big chance that you will hire engineers who have skills in particular frameworks and technologies, and this will probably be the tech stack for your MVP. Whatever technology they pick, it is not a failure. Failures are born later. Losing focus on the business side of MVP and gold plating as over-architecting the technology part is one of the pitfalls of failed startups. Do not use cool technology, use the one that brings business value.
Starting s Startup – Myths
Most engineers pick standard MVC (Model, View, Controller) paradigms with some already proven language or framework like Java, PHP, JavaScript, and some relational database like Postgres or MySql which can offer fast start and rapid prototyping capabilities. Start with simple architecture, and use a monolithic approach, it is OK. This again is not a bad thing and will not push you fast into failure, just focus on customer value and this technology will deliver it. (or not, this is a myth)
Now let’s fast forward 5 years in the future of this startup. Your MVP has been a hit on the market and your startup grew to 100 people and your ARR (Annual Recurring Revenue, a SaaS KPI) is 25M$. You have a few thousand B2B customers and your focus is now on growing this business. But there is an elephant in the room.
Starting a Startup – Pitfalls
Statistically, your engineering team is about 30% of your costs, or you have an engineering team of 30-40 people. Your MVP has grown to be a little monster, already rich in features. Customers want more features, so you again develop more features. And slowly you neglect the tech debt. The basis of all code is still early-stage MVP developed by one of two engineers in the early stage of the startup, upgraded with a lot of new code added later when new hires arrived, but in essence still MVC architecture with some relational database. You noticed that feature development time has increased from weeks to months, sometimes even a year. When you ask the engineering team why, they just complain that the code is complex or that the database is hard to develop further. And they are right. During my work with Berlin startups, this has been a major obstacle to scaling the business further. Slow feature development, it’s one of the greatest pitfalls of software development.
If you look at the Cost/Benefit side of this and calculate how much money you invest in engineering (salaries plus technology cost) can you return this money when the feature is out with the customers? If the development of the feature is a year-long, for sure it’s either something that nobody saw before and instant hit on the market (less than 0.01% chance) or is a very very expensive feature that needs a lot of time until it returns the money spent. Or you have received a heavy series B investment and you don’t care. Still, you are losing a lot of money and you should care.
Ergonomics and Economics of Software Development
In theory, this is part of the Ergonomics and Economics of software development. When you spend more time in development and less time receiving value, you are already on the bad side of Economics. If the performance of the system is worse with the new feature, then Ergonomics is worse than before and delivers less value to customers. If you look at the graph below, you can spot where these two lines intersect, that is the point where you should start worrying that your business will grow slower because of the platform itself. Feature development will take longer and your competitors will outgrow you. Eventually, your business will fail.
How we can prevent this from happening and when? What is the way out of this situation?
Remember the time when you hired your first engineers and they picked the technology before we fast-forwarded 5 years in the future? That is the time when you can make some choices that can influence how your MVP will develop into an excellent SaaS platform in the next few years.
Prepare your code for scaling before you start coding. Sounds strange, but it can help a lot. Simple usage of Domain Driven Design (DDD) and organizing your monolithic architecture to it will enable you in the future to split the monolith easily into smaller parts or even into Microservice architecture. How to do it? Before you start coding, identify on the business side a few domains, or use cases that can be grouped under a similar name – a domain. After identifying a few domains like this, code organization and database design follow it. All controllers in the code that belong to one domain have this domain name in the code structure, like checkout.payments.js or checkout.payments.java, and the code from the same domain is in the same folder in the code structure. Look below for an example of how MVP can be structured on the code level to be aligned with domains, even before you start coding.
Any relational database is OK to start with. Or is it?
Which database to choose before you start crafting your MVP is very important. Most engineers pick some relational database, like Postgres or similar. Relational databases are more than 30 years old and were designed to follow simple architecture designs where just a few objects (like a user can use this feature) interact between themselves. Most SaaS platforms are very complex. What will happen when you model your MVP into a relational database, and after 5 years it grows into big tables (still OK, most DB engines can handle billions of records) and to very complex SQL queries (a problem, that can be improved with profilers, but not too much)? Most Berlin startups that I worked with have a major problem with the size and complexity of database structure after 5 years of growth. Few big tables in the database, very complex SQL queries, and a bad situation to grow with.
What database to pick? My personal choice is to pick any Graph database, like Neo4j or similar. Why? Most of the business problems can be easily described with graphs. Most of the technical problems can be described as graphs. Complex SQL queries in relational databases are trivial in graph query language (like Cypher). All schemas in relational databases are strict and can not be changed during runtime (fixed schema). But in graph databases schema is dynamic. You can very easily add a new object in a database that has never existed before and link it to existing data. That is very powerful when you are building a SaaS platform that evolves from MVP. In the stage of MVP, you never know exactly in which direction will MVP grow, and for a relational database is very hard to follow these changes over time (adding more complex features). Because of that, relational databases have problems with complex SQL queries. Adding a new node to the graph database and connecting it with existing data is easy, which means you can easily extend your current features by enriching the data model with data that never existed before. Dynamic schema of a graph database is a key advantage in how to be prepared to scale the MVP and not lose the ability to fast prototype and deliver features. Or simply, stay on the positive side of the Ergonomics and Economics of Software Development.
Frontend? Any SPA is ok to start with, but what can go wrong
The last architecture decision is what frontend technology to use and how to set it up at the beginning of a startup. Simple, use any framework for frontend in which developers are skilled to develop fast. The most popular frameworks today for SPA are React, Vue, Angular, and some new players. Pick any of those, but follow just one methodology: use components. Using components in front-end development is like using Lego bricks to assemble UI. For every button, table, list, dropdown, filter, graph,…, there is a component that you can reuse. Do not develop every page of UI as a custom page. The most popular tools today that can simplify frontend development using a design tool like Figma which internally works with components that can be easily exported to any popular SPA framework.
But what to do if after 5 years I have slow feature development?
Well, you are not alone. A lot of startups in the Berlin area, and probably also in the US have this issue scaling from MVP to proper SaaS platform. My personal choice is what to do when you have bottlenecks in every component of your SaaS architecture is to plan and execute refactoring. If you have a monolithic backend system with Spaghetti code, refactor it first internally to follow DDD. After that split the monolith into several parts, and after that split more if necessary. Refactoring is not about losing time or money. With refactoring engineers will learn a lot about the code but also a lot about the business, because for making changes in the code you need to understand business rules. After refactoring the value is not to have better code structure, but the goal is to have better-aligned engineers who now better understand your business model and how the code is handling it. This is a starting point of Bottom-up development. You are now ready to make miracles on the feature level, very fast. And your customers will love it.