From Developer to Architect: Scaling a 0→1 Product

As my mentor once told me, building a product is like birthing a child. You start with a single idea, and then you grow it into a full-fledged entity. You face challenges, you make mistakes, and you learn from them. But the important thing is to keep going.

Working with a new product is always an interesting challenge. The team is small and ideas will come from all directions. When I joined a new product as a core engineer, I understood that failing fast was the typical mantra to handle the speed of the product development. In market whatever we create, there is a non zero probability that it might be something which has already been established by someone else. The best bet is to try to bring what other competitors have done and improve it to our own advantage.

That attitude helped me to run comfortably faster no matter how hard the track was. New ideas bloom out of nowhere and I was comfortable enough to pick it up and try to experiment with it so as to figure out whether are we going in a right direction.

Taking engineering decision are where the engineering mind peaks with tradeoffs, I was clouded with oppurtunities and tradeoffs when I saw a problem to solve. That's where we peak as a "kutty" architect trying to figure out the pros and cons of the solution and quickly having to jump to another way to handle it if this doesn't work out.

The standups are always the best. As engineer I felt some pride in telling that I am accomplishing larger tasks and working with best minds in the team meant that learning more from them. I was also able to learn a lot from the discussions in the standups. Understanding other people's perspectives broadened my own perspective and helped me to see the bigger picture.

Like my mentor used to say, as the honeymoon ends and the reality sets in, the product starts to mature and the challenges start to increase as customer starts to purchase the product. That's when I understood one thing, at every stage of building a product, the priorities will shift, while building 0 - 1, it will be speed, but over the course of the time, it shifts to stability, since we also have to make sure the product is bug free so that we avoid churning customers.

When stability comes into picture, engineering decisions have to be carefuly considered keeping in mind the system scalability and fault tolerance in mind. Although it might look like kneading a fine thread, it is still an interesting way to gain experience with difficult examples.

On a final note, if you get an oppurtunity to work on a startup, it would be a experience of a lifetime.