Photo by Ian Kim on Unsplash

One year passed and I am yet to have the product I set out to build the way I wanted it. Not everything can be attributed to the technical challenges mentioned in the previous posts. I had to attend to other things in life.


Jumping into the web development bandwagon made me realize that

  1. Software development is easier said than done. Before I got my hands dirty it was easy to say to the developers that the customer wants this and that expecting the same to be delivered immediately. Now I have got a glimpse of their pain, especially when certain requirements were not considered as part of the initial design.
  2. Most of the tutorials out there are written by developers who are already working in an organization or at least have years of development experience behind them. For any beginner/non-programmer who wants to get stuff done fast, the whole domain might look overwhelming and confusing. Hence patience is required.
  3. Things might look simple and easy on the onset, perhaps good for building a small app. When you want to build something with authentication, API, validation, user permissions, third party integrations, etc you are left with little help in a single course or book. You need to tirelessly search and learn things from disparate places.
  4. Never think about scale until there is a real need. When you start off it is more important to satisfy the need of the few customers in hand now, than those who never came. To be precise those customers will never come unless you take good care of these initial few.
  5. Microservices vs Monolith: This is a debate that has no correct answer. The architecture is determined only by the number of customers you have and how large your team is. You are not Uber or Amazon when you start off and the advice that applies to them certainly will not apply for you. The best framework advice given by an engineer working on such teams definitely will be the worst for you as a small startup. Their initial days of struggle are buried in their preset success. For those with a small team and when the product features are not yet confirmed by the potential customer, a Monolith is much easier to handle. Only when you grow and have larger teams that work in functional silos microservices helps. Along the same lines, the synchronous execution of languages like python and an excel-like row-column format of the SQL databases are much easy to reason with when compared to asynchronous NodeJS or NoSQL databases like MongoDB. Again the team size, customer size, and especially the problem domain matters.
  6. Technology keeps evolving: Before you start and end an online course or a book there will be a new technology that seems like a game-changer making you look at the current stack with contempt. Rather than going behind every shiny object, it’s much better to stick with something that has proven to work well. More focus has to be put on the value creation to the customer. Technology does not pay it the Customer who pays and Customers pay for getting their problem solved. This is where I found Django to really shine, with a single installation you have the ability to create something that works.


Choose something that aligns with your core personality. Note that personality theories are just models that help you understand some aspects of your behavior. helps you from getting fixated with one theory. I did some research into knowing why this one year in app development turned out this way.

  1. I am typed as an INTJ according to the MBTI Personality theory. INTJs spent in ideating, conceptualizing, and learning new stuff. They are really good at forming patterns and analyzing different scenarios in their mind and looking out for the best path within them. They can easily spot inefficiencies and what can go wrong in the future. They are good, especially with contingency planning. Being highly rational once such a path is chosen they put their full efforts behind the plan till it gets accomplished. However, they are not very much tuned to their own feelings or that of others and also sensory details. Most product development frameworks/advice seems to be about Empathy rather than effectiveness/efficiency. And software development especially coding is about attention to detail. Finally, they might try to do everything by themselves.
  2. From the very onset, I seem to get into the mode of premature optimization by worrying about problems that didn’t exist currently. Hence rather than sticking with what works, I was over-optimizing even on trivial ones. Repeated refactoring the code got me stuck in a loop without progress only compounded by jumping from one framework to another. The sheer amount of new details that need to be understood by adding additional dependency was overwhelming.
  3. Jumping directly into coding often left me wondering several days what was I doing, to put it better why I am even doing this. Switching from the big picture to details was very tiring. Most of the time spent was on stuff like making D3 work with React, using React and Webpack with Django Template, WebSockets with redux-saga,use WebSockets messages for CRUD rather than traditional rest and so on. This was mainly because of the layer I was working on the lowest part of the software development pyramid. I ran behind fixing problems at this layer that I eventually lost sight of the business problem itself.
  4. During these days Journaling and then verbalizing stuff to my close ones helped me a lot to clear away some of these confusions.
  5. Persistence: Inspite of finding things to be not working I wanted to stick with it. There were even days of thinking this whole endeavor was sunk cost. Throwing the towel would have been easy, however, it leaves with it a feeling of less self-worth. Getting to complete the basic functionality with Django with little efforts made me wonder what I was doing for 11 months. Rest be said there were immense hands-on learning and the choices I make now have more depth than deciding than haphazard decisions based on reading a single article.
  6. I should admit that focusing on your strengths rather than your weakness gives the best ROI. Finally, value creation should be the goal rather than perfection. The perfect framework, model, or language does not exist, searching for the same is delusional thinking. Instead what needs to focus on where I can create ongoing value is most important. It doesn’t need to be confined to software even. An artist can provide the best value through art and a researcher through publishing papers. Either one can definitely learn what new skills however as a person one is wired to processes information and also act on the information in different ways. A researcher tries to learn music, their mind can get obsessed with accumulating knowledge than putting in more effort in practicing the actual art.
  7. Asking help, delegating, and sharing your experience with others helps you see blind spots when running around circles. A new perspective can help you come out of the loop.

The lessons I learned in the process have helped me understand a lot of things about technology and myself. With more people getting into product development, I hope these posts might help them make better decisions.

Previous Post:

Life depends on Your Interpretation of it! I am crafting an interesting story out of it :)