24/11/2021
Recently the Jellyfish.tech team faced the challenge of convincing prospects they need to invest in a scalable MVP architecture from the very beginning.
Yes, this requires a software architect/team lead spending extra time thinking through & planning out the product architecture. However, considering application scalability at the first stage of working on MVP is a great time & money saver in the long run.
Alternatively, the bad architecture will cost a project hundreds and thousands of dollars.
So, before actually building something, our CTO Roman Latyshenko strongly recommends considering the following factors that directly influence the architecture thus the scalability of your future product:
πΉ Number of users. From the very beginning, we should have an understanding of how many users your product intends to have for planning out the architecture based on this number.
πΉ Tools. The tools we use for product development depend on the estimated number of users as well as other factors, among which are project timeline & scope, designs, etc.
πΉ Usage scenarios. Going through product usage scenarios briefly would be of great help when planning out the architecture, as at this stage we define the focus areas for a software architect (i.e. an application should be used without Internet access).
πΉ Amount of data to be stored.
πΉ Amount of files (images, docs) that will be used regularly.
πΉ High-level plan of product development. How do you see further steps of project development? Will the team have time for code refactoring? Do we need to make room for horizontal scaling?
πΉ Protocols that will be used between application parts (i.e. WebSockets for chats, HTTP for REST API).
P.S. Assuming your product is a house, donβt let it be built on the quicksand of poor architecture.