Yes and no. The problem is that most of the time the train of thought goes something like:
* we already have a working product
* we might aswell just add the features and visual polish we need and then launch as soon as possible
* we have too much work to do to rewrite it
* we can't refactor effectively because automated tests are mostly missing
This results in the project becoming increasingly burdened with technical debt, where it becomes impossible to add new features without breaking something. The next step after this is usually a rewrite (which, given the low quality of developers already in the company, since nobody sane will work on such bad code, is also likely to fail, unless IT is restaffed completely).
If the prototype is binned outright and the rewrite happens at the very start, I imagine that this can be avoided. Again, the trap here is that if the founder learned to write code in 6-12 months then they will be in that cute phase where they think that programming is easy and will not realise this.
In short, having a senior developer on board (at the very least as a consultant) from the very start appears to be mandatory for long term success and minimisation of headaches. It's just what I've seen in the real world. Companies which went for quality from the very start grew rapidly. Those which attempted to minimise development costs at the expense of quality did not reach the heights.
I just got off a short contract where this exact thing happened. The company had a MVP they were using that was made by the founders. They were obviously young and inexperienced. The code was awful to say the least. I told them straight up it would be best to just throw all this code away and start again from scratch. Its best to do it now while the company is young, rather than much later. They were neck deep in technical debt.
They claimed it would take "a really long time" to rewrite everything. I can understand a junior developer thinking that (it apparently took them 2 years to create the code they were using at that point). But using good engineering practices, building a site that did what they needed could have been done within a few weeks using Django and MySQL. Its really hard to make this point stick when you're dealing with developers in that "sophomore zone" of programming ability.
Needless to say, they told me "no way jose". I ended it with them right then and there. I can't tell you how many times I've seen that happen.
* we already have a working product
* we might aswell just add the features and visual polish we need and then launch as soon as possible
* we have too much work to do to rewrite it
* we can't refactor effectively because automated tests are mostly missing
This results in the project becoming increasingly burdened with technical debt, where it becomes impossible to add new features without breaking something. The next step after this is usually a rewrite (which, given the low quality of developers already in the company, since nobody sane will work on such bad code, is also likely to fail, unless IT is restaffed completely).
If the prototype is binned outright and the rewrite happens at the very start, I imagine that this can be avoided. Again, the trap here is that if the founder learned to write code in 6-12 months then they will be in that cute phase where they think that programming is easy and will not realise this.
In short, having a senior developer on board (at the very least as a consultant) from the very start appears to be mandatory for long term success and minimisation of headaches. It's just what I've seen in the real world. Companies which went for quality from the very start grew rapidly. Those which attempted to minimise development costs at the expense of quality did not reach the heights.