The Startup Tech Journey: Building for Speed and Scale

As engineers, we harbor an innate desire to build scalable solutions from the get-go. However, this often leads to an overly complex application, particularly when designing an MVP for a startup or a product from scratch. In this blog, I'll share my experience and some practical advice on striking the right balance between simplicity and scalability.

?? Simplicity vs. Scalability:

The question often arises - why not start with microservices from day one? Developers, much like artists, enjoy the challenge of creating something intricate and unique. However, we must remember - time is money in business. An overly complex, yet scalable architecture is of little value if it hinders swift progress. What works best, in my experience, is a solution that operates effectively and efficiently, regardless of its simplicity or complexity. For instance, if you're catering to 100 users where load is not much, a straightforward API, database, and UI would be the perfect architecture.

?? Launching an MVP Quickly:

When time is of the essence and the goal is to launch an MVP to validate an idea, simplicity is key.

?? Case Study - Airlift:

Let's consider our journey at Airlift. Launching our grocery delivery service was a formidable task. With a two-month deadline to beta launch, we had to develop various components, including inventory management, product management, picker application, packer application, rider application, customer application, and an admin portal. All this was achieved by a team of just eight engineers!

Our technology stack was as follows:

• Backend: NodeJs (our team was already proficient due to our previous Airlift transit application)
• TypeScript: Although new to our team, it offered significant value in terms of code management
• Frontend: Angular (for the Admin Portal, which our team was well-trained in)
• Framework: NestJs (for better control and easier library selection)
• E-commerce: WooCommerce (for rapid implementation)
• Database: Postgres (our team was familiar with it and it provides JSON support)

We opted for a monolithfirst architecture. We used NodeJs events to keep the modules separate, allowing for more efficient separated transactions.

For mobile apps, we chose native development due to our in-house expertise and the complex nature of the applications that required superior hardware performance and integration.

This was how our initial architecture looks like

?? Scaling Fast:

Our architecture served us well during the beta launch. Our team pulled off this feat by putting in 14 - 18 hours daily (Thanks to Covid period where we were not allowed to go out of home :p). The following months were challenging as we scaled quickly. From 25 orders a day, we were soon delivering 1000s of orders daily, hitting 40000+ orders per day in a year! This means almost 1000+ concurrent requests in a second.

?? The Rewaa Journey:

Currently, we're on a similar scaling journey at Rewaa. We started with a simple, yet functional application. Now, we're working towards making it more scalable and performant and matches our technology with the business growth. I look forward to sharing our progress on this path in my future writings.

In conclusion, every journey to build a tech startup is unique. The key is to balance simplicity and scalability, understanding that what works and works well is indeed a great architecture. Let me know your thoughts and if you're interested in how we managed our rapid growth at Airlift, or if you're keen to follow our scaling journey at Rewaa, do drop your comments. ??