My experience building a technology product startup

Last week, I was helping a startup founder review his technology architecture and helping them move cloud providers. One of the points that came up in the review, was how do I make sure this platform scales. It sent me thinking to my first year as a CTO for tech product startup. I had just left my job a large investment bank, where I had built large scale solutions. Definitely I was feeling confident that I could build a good scalable product. 4 months into the task, I realized I was so wrong !!

Here is what I learned from that experience.

Your product will evolve very quickly

When you are working for a large established investment you have the liberty of spending a lot of time talking to all your customers, and then have detailed requirements of what you want to build. This is something that most tech startups don't have when they start working on their product. Which means that from MVP to a product that is accepted by your consumers it might change completely. We went through 5 iterations of the product before we found the right solution for the problem that we were trying to solve.

So your technology and architecture have to evolve with the product, and it has to evolve quickly. If you build something very rigid, you might have to start over when iterating on a product, which is what we had to do when we went onto our 2nd iteration. We were over confident about our MVP, and we built it so rigid that we had to go back to the drawing board for our 2nd iteration.

Always consider your team size, and money when designing the architecture

When I was building platforms for an investment bank, team size and hardware capacity were never an issue. You can build a complex architecture, because you have the money to back you up.

In the startup world its not the same. Your resources are limited, and you have to adjust your approach accordingly. E.g. I had a dedicated DevOps team always during my career so I depended on them when it came to hardware decisions, security and scaling. This is not something I had the liberty of when we were building our first few iterations, so I had to evolve into learning those things, and picking the right tools, hosting and architecture so that these things don't become a burden on the team as we are moving forward.

Cloud provider and scale of the hardware is also something you need to consider. Again money will be limited, so you need to start small, constantly monitor and scale accordingly where required. Things that I had no experience on, when I started this. Somethings I learned the hard way, like over procuring cloud servers and then realizing that we don't have enough users, and we need to be more agile in terms of scale as well.

End users don't care if your tech stack is future ready

Quite often I found myself getting drifted into building the best technology solution without thinking of the actual end user. As I spoke to more people I realized a lot of tech background founders had the same problem. We focus to much on which tech stack, what framework, what database etc. Although these are important decisions, but in your early days its more important to have stable working product that you initial users like. It should be something that is easy to use, solves the end users problems and something that you can quickly iterate on. Till you reach a critical mass of users focus more on user experience, than on what tech stack is future ready.

Another thing to consider is how easy it is to find good talent in the tech stack you are about to use. As you build your engineering team, you will good talent and you will need them to get accustomed to your stack quickly so that they can start helping out. As a startup you will not have the liberty of a long onboarding period, so if your application is too complex scaling your engineering team will become a challenge that might stop you from growing fast.

Build something that a small engineering team can manage

One of my biggest mistakes was I looked at the Googles, Netflixes and Facebooks of the world to find good design patterns and how they were doing it. Why was it a mistake, simple they have 100s of engineers to manage single products/services, while I had 5 !! So where things like microservices might work for them, it became a disaster for me because managing & maintaining them was a huge cost. I could not afford to keep multiple versions of the services running, for me the changes had to move together with every piece in sync, else I would end up spending more cloud costs.

Never look at organizations that are not at your scale or size for technology architectures. It will most of the times end up in unmanageable product, which will require more money to maintain than you can afford.

Do what makes sense for you

Overall what these last 4 years have taught me is that my product is unique, my requirements are unique, and I have boundaries that I need to work within so I will have to do what makes sense for my product. My end users don't care if my UI framework is the coolest one in the industry, they care that their experience is nothing like any other product

Also, for me I can manage scale because mine is B2B product so I will always know how many licenses are being sold and how many new users I should expect to be on the platform. I can plan easily, and I don't have to worry too much about a sudden spike, so why worry about that instead I can spend energy on something else.

Finally, always remember when you have 1 Million users, you will have enough money in the bank to hire people smarter than you to fix any scaling issues that you might have !!!