This is well said. Writing well-factored, robust, scalable and easily-maintainable code takes more time than shortcuts. It produces a much better result also, and that time is a worthwhile (and needed) investment only after you've figured out what the final product is.
Iterate quickly, knowing you are building some some technical debt. When you figure out the product, chances are that significant portions of code have been thrown out, and now you should focus on upgrading the quality of that early code.
The engineers I've seen that struggle at early stage startups are the ones who want to go from 0 to 1 on a prototype but want to write well-factored, robust, scalable code because they are worried about how it will be maintained. I can't stress enough, to be successful at most early stage startups, the goal has to be to create a product that people love, and then figure out how to get it maintainable.
It's a tough switch both ways. The ideal experience IMHO is starting at a small company with prototyping and fast delivery that then transitions to a more established business and makes you clean up all your messes.
Iterate quickly, knowing you are building some some technical debt. When you figure out the product, chances are that significant portions of code have been thrown out, and now you should focus on upgrading the quality of that early code.
The engineers I've seen that struggle at early stage startups are the ones who want to go from 0 to 1 on a prototype but want to write well-factored, robust, scalable code because they are worried about how it will be maintained. I can't stress enough, to be successful at most early stage startups, the goal has to be to create a product that people love, and then figure out how to get it maintainable.