I get your points. We did finally get there with the MVP; the initial roadmap was full of envy, and I set the bar way too high regarding build, tooling, ci/cd & testing.
I thought that those would help us further down the road, and I was right, but the issue was more about the time/effort it took me to get there, eventually.
I wouldn't say that code quality doesn't matter, but I certainly should've made more tradeoffs on that front. It was just really hard to judge.
With my background (enterprise frameworks, mostly), quality almost always needed to be top notch, because our deliverables were the basis for many other developments. I guess this created a bias in my way of looking at code quality? :p
And to reply to your question, the first two projects mostly failed because my partners did not believe in the projects enough and weren't ready to invest the required time/energy; maybe it was more envy than profound motivation; idk, cannot speak for them. But I abandoned those too, so they're not the only ones to blame I guess ;-)
The lack of belief and investment is not the root cause but a symptom - you had a limited budget of motivation and belief, and you ran out of it before getting a MVP. If you had "spent" that very limited motivation-time-runway more sparingly on a more-minimal-MVP, perhaps it would have been sufficient.
I.e. I'd suggest looking at the constraints the entirely opposite way around than "weren't ready to invest the required time/energy" - in this equation, you can (and must) change the "requirements" for time/energy, as the time/energy available for the project is your core limitation that you should treat (in the short run) as out of your control, especially as it concerns the time/energy of others before funding. From the classic project management tradeoffs, this is a "limited budget - adjust scope to match" scenario, not "fixed scope - let's see what the budget will be" one.
I thought that those would help us further down the road, and I was right, but the issue was more about the time/effort it took me to get there, eventually.
I wouldn't say that code quality doesn't matter, but I certainly should've made more tradeoffs on that front. It was just really hard to judge.
With my background (enterprise frameworks, mostly), quality almost always needed to be top notch, because our deliverables were the basis for many other developments. I guess this created a bias in my way of looking at code quality? :p