There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.
So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows?
There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be.
This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes.
You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it.
I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes.
Being able to pivot and adapt is more important than stability, when you are a startup.
But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.
In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.