To me, an MVP is about reducing functional and non-functional scope: which requirements (functional and non-functional) can I take away from my solution, while still having built something people want?
Maybe your MVP doesn't require full HIPAA compliance, or nine nines availability, or the ability to manage users via a front-end, or...
Typically people do want software that's intuitive to use and doesn't crash, so you don't want to ignore those requirements, but most of the others are for grabs.
This implies your MVP is tightly coupled to your ideal customer profile, your GTM strategy etc:
Which audience will want to pay for this specific piece of functionality, despite all of its flaws (why opt for a non-established supplier? What's the out of of the ordinary part of the service that makes me willing to buy this? ...)
An MVP is built to validate a business hypothesis, and you should try to do the minimum to do this. Technical debt is unavoidable, as you usually don't know upfront what all the requirements will be within 5 years from now. Trying to architect upfront for this will usually fail, as most of your assumptions will be wrong anyway.
My #1 tip is to try to build a composable system where you assume the majority of the components will have to be replaced multiple times over a cycle of n years, so make them easy to throw away and start over...
Maybe your MVP doesn't require full HIPAA compliance, or nine nines availability, or the ability to manage users via a front-end, or...
Typically people do want software that's intuitive to use and doesn't crash, so you don't want to ignore those requirements, but most of the others are for grabs.
This implies your MVP is tightly coupled to your ideal customer profile, your GTM strategy etc:
Which audience will want to pay for this specific piece of functionality, despite all of its flaws (why opt for a non-established supplier? What's the out of of the ordinary part of the service that makes me willing to buy this? ...)
An MVP is built to validate a business hypothesis, and you should try to do the minimum to do this. Technical debt is unavoidable, as you usually don't know upfront what all the requirements will be within 5 years from now. Trying to architect upfront for this will usually fail, as most of your assumptions will be wrong anyway.
My #1 tip is to try to build a composable system where you assume the majority of the components will have to be replaced multiple times over a cycle of n years, so make them easy to throw away and start over...