Many DevOps professionals and managers in early-stage companies are debating whether to invest minimal time and resources in building a product just to get it working, achieve basic functionality, and bring it to market quickly, or to show investors that there's something tangible. Well, it depends on several factors that can influence decision-making later on, which could sometimes become obstacles if the company succeeds. One of the main factors is money – how much has the company managed to raise? If you've received an investment that provides breathing room for a period that allows building stable infrastructure without expecting immediate returns, it may be worth considering. But if that’s not the case, you need to carefully consider how your product will look when the company gains momentum and the product is used by multiple paying customers. In this situation, you need to assess how much maintenance and resources will be required. Why is this critical? From my experience, especially in small and medium-sized companies, there's often the saying "if it works, don’t touch it," which implies that if we start developing a product with a flawed architecture, it will remain that way. Moving to another system or improving the existing one can pose challenges, such as requiring significant resource investment, patching the product with quick fixes that demand a huge IT effort, all of which costs a lot of money, time, and results in less satisfied customers. So how do you approach this situation and benefit from both worlds? One approach is to develop two products in parallel. One will serve as a demo, usually with basic security and support for a small number of users, while simultaneously developing a product with appropriate infrastructure and architecture that will give us a generic and modular product in the future, capable of supporting heavy loads. Another approach is to design an architecture that can support heavy loads and a large number of users, with well-organized processes that differentiate between environments, proper communication between machines, correct division into microservices, and proper alignment between the code platform and system usage, for example, Node.js or Python. But in the end, start by developing a single basic feature from the future system. Of course, each case is unique and depends on the product's purpose and nature, but I shared a macro perspective on how to approach the problem. Read more