Architecture for your startup’s MVP

Finding product-market fit is key to a startup's success. A startup needs to iterate on product ideas fast to find the right problem. You read it right - a startup needs to find the ‘right problem’ before finding the ‘right solution’.
To land on the right problem - a startup needs to have the ability to build MVPs fast and test it out in the market. Getting MVP - Minimum Viable Product - out of the door is essential.

I like to introduce an approach startups can take to build an MVP. Before arriving at this approach, I took multiple scenic routes that landed me nowhere. The stories of these ‘scenic routes’ are far more entertaining than this article. But, let us save scenic route stories for future articles and focus on this architectural approach.

This architecture isn’t typical client-server architecture, n-tier architecture, or microservice architecture.

If I had to describe this architecture in technical terms, I would describe it as a monolith 🏢 connected with multiple providers.

If I had to describe this architecture in poetic terms, I would describe it as an orchestra with a lead vocalist 🎵 accompanied by multiple instruments chiming in.

But, If I have to be brutally honest, I will describe this architecture as
** ‘Survive today to fight more tomorrow’ [™]] ** architecture.

Curious? Let’s go!

Guiding Principles:

A typical software project goes through multiple rounds of architecture with fancy slides and is followed by multiple rounds of discussions. The pros and cons of each technology choice are debated ad nauseam, and when we are exhausted by the technology debate, engineers start to build the product.
Startups must keep the architectural phase to a minimum and go straight into the coding phase. Here is why -

• What can be learned by building and being in the trenches can’t be learned by debating technology on fancy slide decks.

• You don’t know what you don’t know.

We, the techies, love solving technical problems - especially the painful ones. The euphoria we get after solving a painful problem makes our minds seek more pain. Despite knowing the danger of over-engineering - we fall for the trap over and over again. To avoid the mental trap, follow these guiding principles 📖.

Follow the echo chamber: MVP isn’t where you try out new technology. Select technology stack is a widely used stack in the industry. This saves dev time, as cookbooks and recipes are widely available. You will have an advantage in hiring - marketplaces have candidates with similar expertise.

No premature scaling: Architecture decisions need to be future scalable - but shouldn't be scaled at this stage.

No premature automation: The engineering time required for automation should align with the time saved to do things manually.
Stay out of Labyrinth - Choose Managed services over GCP/AWS: Unless you have a certified AWS/GCP practitioner in your team, I advise against choosing Amazon’s AWS or Google’s GCP. Google and Amazon have built a giant portfolio of products in an effort to please diverse customers. The giant product portfolio is morphed into a giant Labyrinth. Labyrinth in which one can easily get lost for days. Stay out of the labyrinth unless you want to spend days searching your way out. Choose managed services instead of AWS/GCP. Managed services have tailored solutions just for building MVPs. You save time on dev-ops, and no one is babysitting servers.

“Time is the only dimension that all the decisions need to be hinged upon”

Conclusion:

What I outlined is one way to build MVP. However, there are multiple ways to build one. It is never about the tools - it's about execution.
Build your MVP, and share your recipe with me. What worked for you? What didn't work? Failure stories are juicer than success ones! You can reach me on Twitter @Meera_Datey Follow me for your no-code/low-code and code MVP journey.