Many times, early-stage founders (esp. ones from non-tech background) when they have a rough idea of the MVP they want to test in the market, split their hair on the design choices when talking to their in-house founding team members or external developer freelancers/agencies.
The core purpose of a MVP (esp. version 1) is to test assumptions and validate customer needs quickly - minimising potential waste arising from actual customer feedback. The best outcome is getting early conclusive customer feedback and tweak the idea & product OR abandon the idea altogether.
Hence, the focus while building the MVP, should be deal with only those architectural decisions as required for the MVP's success proposition. The scope of the MVP should guide architecture choices, determining which parts to build with the future in mind and which to consider "throw-aways." Hence, early tech-teams typically make trade-offs between product capabilities and architectural capabilities.
If the MVP works and there are need for further improvements, the tech teams need to gradually evolve the system's architecture through short intervals, validating and improving it over time to build better solutions. Hence the concept of “architectural runway” might need to be accommodated as part of the overall “product runway” for an early-stage idea.
PS: All of this is under the assumption that the idea is being implemented through full-code.
PPS: No-code / Low-code based MVPs have their own design choices and accordingly shelf-lives. Will tackle in another post.
