Today we are going to talk about how to design your system. A lot of posts and articles have been written about this, and I wanted to throw my opinion out there as well.

So how do you build a scalable system for your startup?

A lot of startups decide to go with one of the standard monolith/all-in-one frameworks for their projects, for example Ruby-on-Rails or Django. The allure of these systems is quite understandable. You get a complete package of routing, templating, database management, ORM, etc all in one set of components, and they generally work well enough. However I want to caution against these systems, for a few reaons:

1. Generally, they are hard to upgrade. Ruby upgrades can sometimes be hard enough, Ruby-on-Rails even more so. You can easily see teams of engineers spending weeks or longer on large code bases trying to handle all changes needed to do an upgrade even if they are trying to follow the releases closely. The same is true for Django. Although Python upgrades are generally more painless than Ruby upgradess, Django upgrades can take a lot of time. If you don’t use a monolith, its easier to update individual dependencies as the number of changes you are doing in one shot is far less. This also drastically helps rolling out these changes in a confident manner!
2. They allow, or even encourage, design patterns that will make it harder to scale and separate things out later on in your systems life cycle. I am not advocating a microservices architecture, but within your monolith you’re still going to want to have a ‘services’-like orgnanization. Organize your code into functional units and try to maintain ‘public’ apis between those subsystems. This will make it FAR easier to reason about how code works, as well as FAR, FAR easier to refactor should you have to change some of the fundamentals (ex: a new datastore, or maybe some part of the system you DO have to extract for performance reasons).

If you and your team love python, you can easily start with Flask or FastAPI + SQLAlchemy and have an extremely easy to use + maintain system, that should be easier to upgrade and maintain long term. If you love Ruby, I am not as plugged into the Ruby world anymore, but I assume similar such frameworks exist that can help you avoid RoR. Other languages have their own versions, Go has a wide variety of http frameworks, Kotlin has a bunch of kotlin specific, as well as being able to use a lot of Java frameworks with relative ease. The possibilities are all there, and will likely serve you better in the long run, over the massive bundle of an all-in-one framework.