> What would be your stack if you are building an MVP today?
Many years ago a CIO told me he didn't really care what technologies I picked for an upcoming MVP backend, as long as I was already comfortable with them and would therefore be productive quickly.
He also told me we would almost certainly need to rewrite everything at least once, so not to dwell too long on the initial stuff.
Build the MVP, build it quickly, get it in front of users. It just needs to work, you're not going to get marks, or customers, for backend coding style.
He also told me we would almost certainly need to
rewrite everything at least once, so not to dwell too
long on the initial stuff.
Build the MVP, build it quickly, get it in front of users.
It just needs to work, you're not going to get marks, or
customers, for backend coding style.
1000% agree. Overengineering things is the death of MVPs. But man this is hard to do in many real world situations.
Stakeholders and managers want you to keep adding incremental features. Never had a situation where they were like "okay, cool MVP, see you in a few months after you tear it down and rebuild it 'for real'."
That "build a fast crappy MVP" mentality takes serious buy in from stakeholders from day one. That mentality might be common in SV and other startup communities but boy is it tough to find elsewhere.
Agreed, but it is also easy to see the tension in your second paragraph. You can plan to rewrite everything at least once, but you will never get that actually in the plan.
My only somewhat clear path out of it is to make sure you built it so it will be easy to rewrite. Either do the least that you can, or keep an eye for improvements, but don't necessarily act on them.
That CIO is brilliant. That's the kind of wisdom you get with experience. Always good when stakeholders ask for additional features because the MVP isn't completely throw-away and then my team doesn't know the language. Then they learn the language, but we need to hire new devs and grow, and no one in the market knows the language. I always tell the new hires that we have a lot of learning opportunities - Go, Ruby, Python, Elixir - you name it. All the fresh college grads can't wait to jump in and contribute within 2 hours of getting hired. My grand-grand father always said "If you can't pick up a new language in a day, you aren't a good programmer and don't belong on Hacker News." He also said using C#/Java/Python is "sus booomer ** fr".
This is excellent advice. The "worse is better" manifesto says similarly:
> The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads.
Many years ago a CIO told me he didn't really care what technologies I picked for an upcoming MVP backend, as long as I was already comfortable with them and would therefore be productive quickly.
He also told me we would almost certainly need to rewrite everything at least once, so not to dwell too long on the initial stuff.
Build the MVP, build it quickly, get it in front of users. It just needs to work, you're not going to get marks, or customers, for backend coding style.