Surviving the Gauntlet: My Journey Through the Startup Death Valley — 1
Prologue
After I first joined my team as a SWE intern in 2021, the circumstances around me were quite devastating for several months. Several senior engineers, including my mentor, left the company, the CTO resigned, and our business model was unstable. Clearly, my company, Miridih , was falling into the startup valley of death, or perhaps it had already fallen. At the end of the year, it was announced that a new business model based on subscription plans would be launched by the second quarter of 2022. Some staff doubted the company’s decision due to the lack of human resources and prevalent technical debts. I was one of them, saying that we had hundreds of tasks that needed to be completed before switching gears. Nothing changed except a few more teammates left their jobs.
Currently, our service has over 13 million users with an average of 2.4 million monthly active users (MAU). More surprisingly, we have become the number one web-based graphic design platform in Korea. This would not have been possible without:
- Prioritizing business circumstances over technical perfection
- Focusing on one or two strong differentiators that locked in our customers
- Creating a good workplace culture to help colleagues stay
I’m going to describe these three factors in more detail. In this article, you will read about why we prioritized business over technology.
Business Over Technology
“Better done than perfect.” This simple phrase reminds us that it is important to just get on and do it. However, engineers often get too obsessed with making their systems perfect. My experience leads me to think about how risky this pursuit of perfection can be in a startup.
The Fed was holding the federal funds rate at around zero as recently as the first quarter of 2022. Once the Fed decided it was time to address inflation, it moved forcefully. Since then, South Korea’s consumer sentiment dropped sharply in June, worrying about higher interest rates and higher inflation.
At that time, I was completely ignorant of these financial circumstances. When our leaders pushed to meet the April 2022 deadline, It was my team that was the unhappiest of the decision and I tried to persuade them to push the release date back to July for the sake of system sustainability. We were a group of only three full-time backend engineers, all juniors, managing a few interns. At the same time, we were in charge of three different domains: account, payment, and cloud storage. In this situation, my biggest concern was creating countless cruft due to the tight schedule. I tried test-driven development to keep our code coverage as high as possible, but in the end, I had no choice but to watch it fall to almost as low as 10%. Even worse, I lost my motivation to design a solid system that could be deployed with minimal debugging costs.
I searched for and read as many articles as possible to solve the problem, and one of Martin Fowler’s articles guided me properly:
“Many non-developers tend to think of cruft as something that only occurs when development teams are careless and make errors, but even the finest teams will inevitably create some cruft as they work. (…) The difference is that the best teams both create much less cruft but also remove enough of the cruft they do create that they can continue to add features quickly.”
The essence of his article lies in the lesson that even the best development teams can write bad code under tight schedules, but they do not neglect their efforts in designing their software. They continually improve their code to ensure their project can adapt to diverse business requirements and maintain long-term speed.
Keeping his practice in mind, I put as much effort as I could, along with my teammates, into designing our software while implementing functions that aligned with our business plan and leveraged the prolonged pump-priming measures.
This is one part of my success.
I try to post a new article at least once a month. It’s my way of documenting my journey — a collection of insights, reflections, concepts and ideas that I came across over the years and that I believe are valuable for others who embark on a similar journey.
It is easy to come across lessons learned by excellent engineers and entrepreneurs. But it’s much harder to see those learnings unfold and how they apply in the reality of running a business. My story tries to bridge that gap and is a way of giving back to the community. It shares our learnings, our highs & lows, and gives a unique view into what it is like to build a global tech company. Please stay tuned.
