29
16 Comments

A minimum viable product (MVP) needs a minimum viable architecture (MVA)

  1. 5

    I like this perspective. The distinction between an MVP and a prototype is important. Unlike a prototype, an MVP isn't something designed to be thrown away after its initial use. It should be something you can develop and build on without having to start from scratch.

    1. 2

      Exactly, I think the term "minimum" sometimes makes people assume it's something to be developed quickly and is of little value. But developing your MVP is part of the product development process. Yes, it's the minimum (i.e. the threshold you need to reach before putting it out there), but the whole point is, it should be something you can build on and adapt based on the feedback you receive.

      1. 1

        Although I'm not entirely sure I agree with the point about: "But customers do care about the sustainability of the solution, which makes the architecture important to them." - I agree customers want the solution to be sustainable, but they probably don't much care about the architecture so long as you arrive at the same solution. Unless you argue that's not possible (i.e. you can only get to a solution using one architecture).

        1. 1

          Yes and no - you're right in that customers probably only care about the solution. But if you're changing you're changing your architecture to arrive at the same solution, you're actually agreeing with the article - they're saying your MVA should be flexible in order to be sustainable. To minimize your work, ideally, you want to get to a stage where you're not changing the MVA completely, but rather adapting and making changes to the one you started with.

  2. 3

    I think we should invest a middle step between a POC and an MVP. I have to update my customers on the road to a working MVP and the milestone must show visual progress because they won't check the amount of lines in the backend.
    Minimum Viable Update :)
    Minimum Viable Milestone :)

  3. 2

    You just need to do few projects and you’ll know what that looks like…

  4. 2

    Bookmarked it! Amazing

  5. 1

    Interesting! I guess it all boils down to wether the "product market fit" has been nailed or not. If not, then you probably shouldn't put too much effort into an MVA. But if your idea is validated it's probably a great mindset.

  6. 1

    Minimum viable...from which perspective. Many forget, its from the consumers perspective not from a producers perspective.

  7. 1

    What a fantastic and informative post. Thank you for taking the time to share this here!

    Quick question, if anyone has an idea: when is the right time to consider this? I feel that stepping away and making a technical overview for (potential) infrastructure that could be built in the future is outside of the scope of MVP'ing.

    To what extent should the relatively little amount of resources available to nascent companies be focused on developing scalability at such an early stage?

    On a more procedural level, shouldn't this entail a relatively significant time investment? I don't feel that it's possible to simply sit down in one day and formulate a well thought out plan for my architecture.

    Opinions and criticism welcomed!

  8. 1

    In other words, a monolith.

  9. 1

    I would say MVP need a robust framework because codes written during MVP stage will will become a part of actual product eventually.

    So MVP needs a lot of code generators, pre-built standard module etc. So that it could be completed faster.

  10. 1

    Using the MVA model has so many benefits. And often results in a highly polished agile product.

    I appreciate this breakdown of the main aspects of MVA by protecto.io:

    • Build for the most likely scenario. Keep the design flexible enough to tackle edge-case scenarios as they arise.
    • Keep the major technologies and the programming language intact. The product is built in small increments over a certain length of time.
    • This type of architecture is grounded in concrete and factual requirements instead of assumptions or gut feelings.

    Great share/reminder!

  11. 1

    Everyone Try This Cool Game Moded Version. Thanks.
    https://modapkshop.com/monster-legends-mod-apk/

  12. 1

    I wonder how nocode fits into this entire picture. You could build a minimum viable product with nocode tools. For example, 2 days ago I published an article where a guy recommended you don't build a SaaS but white-label it for a start. This provides several advantages (the biggest one is you save a lot of time).

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments