In the world of agile methodologies, Minimal Viable Product (MVP) is a widely accepted concept among application developers. MVP is geared towards developing just enough features to gather validated learning about the product and its continued development. Not only this approach improves time to market, but it is also significantly cheaper from the perspective of both the upfront investment and cost of change to the direction of the product based on feedback. However, that same mentality haven't really crossed into the realm of underlying architecture.
As an industry, we're fascinated with solutions that are presented and blogged about by companies working with the bleeding edge technologies. Problem is - most of us don't have the problems those companies are trying to solve. But many don't try to find a solution that matches the problem at hand. That's why reference architectures are treated as tutorials instead of references and technologies are picked based on their rankings on Reddit. In this talk I discuss some of the anti-patterns for technology selection and architecture design as well as talk about the approach to designing a minimum viable architecture for your use case.