Tech Anatomy of a Startup – Part 3

The technology architecture of a startup’s product must allow for rapid evolution. The product will likely change and improve quickly as the startup grows and learns more about its customers’ needs. A flexible technology architecture will enable the startup to make changes quickly and efficiently without rebuilding the entire product from scratch.

Hardcoding is easy and gets work done. But that can kill a product even before it launches.

One of the most common mistakes programmers make is hardcoding a few things here and there. At first glance, you may feel, “That is unbelievable! Who hardcodes?”. But we have seen this once too often. At first it is done to make things work properly. Then it is not disturbed, lest it breaks some things somewhere. Why fix it if it is working? This is one of the ways products become rigid instead of sturdy.

Building products using industry standards takes more effort and at times longer. Entrepreneurs may look at this approach with a lot of apprehensions. The idea that it is “just an MVP” can be very dangerous. It is simply common sense that if your product needs to be changed or updated, you’ll have to do a lot of re-work – which can be costly and time-consuming. And guess what, startup products is all about changing features and functionalities. Create generic modules that can be easily plugged in or pulled out. Use variables generously. This trick will save you time and money in the long run.

Build for flexibility, agility & scalability.

The hallmark traits of startups are their agility and flexibility. This trait has to be imbibed in your product. One more method we suggest for this is modularity. Modularity allows for flexibility, agility and scalability.

Scalability is the ability of a system to handle increased loads without breaking them down. It’s essential for startups because they never know when they might experience a sudden influx of users or data. If their systems aren’t scalable, they could quickly become overwhelmed and crumble under pressure.

Scalability has to span across infrastructure, application, database and concurrency of users. Each of these items has to be dealt with deliberately and carefully. The solution for each aspect is different from the other. Therefore, the architect has to be able to visualize all of these together and come up with the right design and structures.

Modularization also allows for updating or replacing parts without affecting the whole. And be sure to choose technologies that will allow you to scale up quickly and efficiently as your user base expands. By planning for growth from the start, you’ll save yourself many headaches down the road.

Ensure the base product handles negative scenarios and exceptions well.

Programmers code for meeting the given requirement. It takes a lot of experience and expertise to start thinking of exceptions and outliers in user journeys during coding. No matter how great your product is, negative scenarios and exceptions will always exist. It’s important to ensure that your base product can handle these well.   

One way to do this is to create a comprehensive test suite that covers all the different negative scenarios and possible exceptions. This way, you can be confident that your product can handle anything that comes it’s way.

It is true that not all exceptions can be handled in the first or even second run of improvement. However, the product can always be developed to handle the unknown gracefully. A message guiding the user to take another step in an unknown situation is more graceful than a crashed user screen with a very cryptic error message that only the developer might understand. By taking care of these things, you can be sure that your product will be able to manage user perception better.

Wherever possible, use methods such as micro-services and APIs

Micro-services break down a large application into smaller, more manageable parts to make it easier to develop and deploy the application. APIs (Application Programming Interfaces) allow different applications to communicate with each other and can be used to create integrations between different systems.

Though these are very well-known methods of developing products, we have often seen startup teams rush through to the end of creating an MVP by writing messy, unstructured and cluttered code. The decision is really about choosing the right way over the easy way. Speed-to-market is very essential, but it should not be at the cost of quality.