Usually, every digital business starts as a startup with one or two people who write code. They have to build features fast, compromising on code quality and engineering standards.
At that point, time to market is the main metric. The insights from the customers are more valuable than the name of the variable in the code.
Let’s imagine that it was a perfect market fit for the product. The startup keeps growing and hiring more engineers. Things are starting not to go as smoothly as they did with a single developer.
What can you do about that?
I identified the following crucial actions that each startup should apply in a scaling phase. They will help to keep the organization efficient and deliver new features at the same pace.
Think in Domains
Domain-driven design (DDD) is not something new and revolutionary. That is an approach to structuring the architecture according to the application domains.
Every application is built around a certain area of our lives. Strava serves all around running and other activities, Instagram is a social media platform, and WhatsApp is a messenger.
When we pick the Strava application, the main domain is sport. But that’s how it started. Nowadays, Strava offers many features, and you can imagine they have a dedicated engineering team working on different parts. Those can be activities, groups, premium features, messaging, or anything else.
How would teams need to structure their work now?
Each team becomes responsible for its domain. The messaging team is not aware of the details regarding the implementation of the groups and activities. They will use common interfaces to exchange data.
This is a big step in the transformation from the startup phase. In the beginning, each component knows everything about the other components. Now, you need to define the boundaries and isolate domains.
It might not be an easy task. However, the book Domain-Driven Design by Eric Evans will give you some insights into how to think in domains and architect your solutions in a scalable way.
Event Tracking
Returning to the startup mode, you know how every single feature works. And even if it stops working, finding out what is broken is easy. How is it going on the scale-up?
The situation changes drastically as the product gets a significant number of users. How can you say which feature attracts the most customers? How do the customers use the product? What is the typical user flow?
To answer these questions, you need to have data. The metrics can speak for the product more than you initially thought. There is a reason why each business has an entire data division. The team consists of data scientists, data engineers, and data analytics.
But before that, the product has to collect some data. Therefore, consider adding data tracking as soon as possible.
That can be any type of data:
- User events such as clicks and page visits
- Money metrics such as payments and refunds
- Technical metrics like CPU/Network utilization
- Logs and metadata for debugging
It is better to have more data rather than lack some when it’s needed. Don’t be afraid to collect all possible metrics. There are plenty of tools for any purpose. For example, you can explore Google Analytics, Firebase, NewRelic, Datadog, and Kibana.
Documentation and Documentation
Documentation is the most boring task for software developers. We all know that. Every time they receive a task to write documentation, they delay and avoid it as much as they can.
At the same time, we always complain about the missing documentation. In the current rapid environment, the documentation becomes outdated as soon as you publish it. The code and requirements are constantly changing to accommodate the customer’s needs.
That’s why writing documentation to the source code doesn’t make sense unless you are building an external API. The code is the documentation. However, what makes sense to write is conceptual ideas, data structures, and relations.
You can start with a simple README.md file in each module describing how this module works and how to use it. It doesn’t have to be perfect. A simple explanation of the entities and the data flow should be enough. The Mermaid diagram is helpful in this case. Using a simple interface, you can build informative diagrams. It is easy to maintain them because it is stored as code and not as an image.
Solidifying software engineering is not a single task that can be completed in a day or two. It is a process that involves permanent changes and adaptation to them.
I have observed the transformation with the items from the above multiple times. They guide the entire engineering department successfully towards scalability. However, the organizations are not limited to only those steps.
Let me know what else you would add to the successful startup scale-up.
Do you want to know how to grow as a software developer?
What are the essential principles of a successful engineer?
Are you curious about how to achieve the next level in your career?
My book Unlock the Code: The Ultimate Guide to Advancing from Junior to Senior Software Engineer in 7 Actionable Steps offers a comprehensive list of steps to boost
your professional life. Get your copy now!