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.
And if that feedback was negative then you would have been able to move on to the next thing sooner.
And if that feedback had been positive it would have provided a lot of motivation for your co-founders.
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