Choose boring technologies if you want to build a successful product
Or what we learned from startup failures
“Instead of learning from others people success, learn from their mistakes.” — Jack Ma.
As young engineers, we always tend to spend a lot of time investigating and improving the technological world around us. We tend to use more complex tools and try to solve a problem in general, so we don’t have to do the boring stuff — solving it again. Many of us get inspired when new frameworks or tools arrive and we quickly start to use them on our projects. Is it good or bad? It is good and bad at the same time. On the one hand, new technology enables us to do the same work more quickly and elegantly, makes maintenance easier and everyday work simply more enjoyable. On the other hand, if you pick up something new you’re not always fully aware of how it might affect the project in the future.
I personally believe that any new technology needs to be validated before used on a product. Especially, when you work on startup you don’t usually have much time to think about how you would do a certain feature. You have to produce results. If you don’t, you set a product on the path to the death. One of the ways to validate new technology, it is to solve problems from real products using new technology. It’s important for a product to be real, not a simple to-do list. If you don’t do interesting stuff you don’t usually think deeply and motivated enough. Think about a side project you always wanted to implement and spend some time implementing the first version of it. You’ll learn and enjoy at the same time. The next step would be to share this side project with your experienced colleagues to get some feedback. In most cases, they will see many potential issues you don’t see and will help you to shape technology before it is used on a real product. Another great idea is to follow and learn from other companies experience. I personally enjoy reading Technology Radar. They share a lot of useful insights and help me to make decisions about a particular technology.
I’ve fallen into the trap of new technologies many times. As an engineer, I love spending time researching new tools and technologies, but what I’ve learned a hard way is not to use them right away. Does this sound familiar? Below you can find a couple of stories from my personal experience.
Back in 2011, I joined a newly established startup company, which were building a product very similar to mint.com — a technology that helps to manage your finances. The founders demanded very high quality and fully featured product. As a business founder what I wanted that as well, but the biggest issues is to find a balance between quality and speed.
At that time our team was particularly enthusiastic about DDD, CQRS & Event Sourcing. We invested a lot of our time to carefully design the system, think of all edge cases, write all kinds of tests from a unit, to integration to UI. The system was nearly perfect from an engineering point of view. Every team member was overly committed to the success of the company. That was an exciting time for us, we had time to do everything in the right way and advance our engineering skills.
18 months since starting the company went bankrupt. That was terrible! It feels a bit like losing someone you held dear. Three things we’ve learned:
- 12 months is inexcusably slow for the first release
- Few core features are good enough to share a product with early customers
- Over-investing in the technology too early increases the chance of failure
A few months later, I had joined another promising startup. We were building an employee-driven learning social network, similar to Yammer. One of the founders sold his house to fund the business. He was pretty confident, the software will skyrocket in the growth very early and instructed the team to build a large-scale solution. The first member of the team was an experienced CTO with 20 years of experience in a large, well-known corporation. We went into the world of distributed computing. This time the first release took us about 5 months. 2 months out of 5 were spent on building a large-scale infrastructure and performance tests. 5 years later the product had no more than 1000 users.
Things we’ve learned:
- 5 months is still slow for the first release
- Most products aren’t likely to have thousands of users over the first year, even if the idea is very ambitious.
- Growing your infrastructure without having actual users is often a waste of time and money.
- Сorporate rock-stars are too expensive for self-funded early-stage startups.
- You should have a budget for at least 6 months, so you have three months to release an MVP and three other months to find at least 100 users who will use your product.
A success, finally
Early in 2013, I had a chance to work on a healthcare business automation idea. We picked the most simple approach: we took tested(boring) technology. We had neither time nor money to have a designer in the team. We bought a bootstrap theme for $15 and crafted clickable prototype of entire MVP functionality in 7 days. We showed this prototype to the very first two clients and they loved it. In 2 months we built and released an MVP of a B2B SaaS product. Over the next 6 months, we developed a number of features and were replying to any client request within 2 hours and were fixing and deploying any issues within 24 hours. We didn’t think much about new technologies at that time. We were focused on getting things done. 7 months after the launching, we had 100 companies loving and using the product. 5 years later the product is competing for the #1 position in its niche and has over 5000 companies using it worldwide.
I still feel 2.5 months is too slow for an MVP. It took only 1 day for Airbnb founder to release an MVP. That was one page published on the internet. And that was enough to get first clients.
Here are the top 5 hypotheses, based on the stories above:
- Launch your product fast.
- Be ready to run a marathon after the first launch.
- Choose boring, tested technology.
- Carefully listen to your clients, they will help a lot to shape your product.
- Do not think about scaling your product, as most of the products grow slowly in the first year.
If you like hypotheses — continue reading. The top 3 hypotheses are about fast and technology. That was the primary reason, why we started Auxilin as an open-source product early in 2017. We’ve been working on it for about two years now and never felt it’s completed.
A few months back, one of the products, which was partially based on Auxilin was acquired. Is it time to share? We hope it might help others to avoid the mistakes we’ve made.
So what is Auxilin? We think of it as a set of technologies, which allow developers or businesses to deploy the first version of their products within one day. We solve a number of common issues like CI, deployment automation, simple frontend, and backend architecture as well offer some very basic common functionality, like profile management. You can set up your product or play around in a few simple clicks.
Why did we start Auxilin?
- We don’t work on routine tasks while working on a particular business idea.
- We want to help others avoid the mistakes we made.
- We want to work on ideas that help others.
- We want to grow as engineers.
- We want to test new hypotheses and release new ideas quickly.
- We want to help business owners, who don’t have much technical experience.
- Success delivers smiles, smiles deliver great products.
- Business drives technology in the first place. If the product is not successful it is hard to raise money, if you don’t have money, the product is likely to die.
How we help
I work on Auxilin. A free, high-quality product starter kit that will help you release your product in a single day. Download and play around. Criticism and thoughts are more than welcome. Write a comment.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +397,714 people.
Subscribe to receive our top stories here.
