I bet every CTO at a certain stage looks at the production code, sighs with disappointment, and wonders if it would be easier to just re-write the whole thing. Typically this stage comes after the seed period is over and the product/market fit has been found.
The thought is very logical. During the early stages startups are iterating at an incredible rate in pursuit of the product/market fit. Each tug in a certain business direction leaves a trace in the code. Since there is no time to properly remove unused fragments, the code base quickly becomes a bundle of used and unused classes and functions glued together in a hacky way. Obviously, this is the opposite of consistency and elegance, and of course constitutes a huge technical debt. Development process slows down, bugs creep in, enthusiasm fades. So yes, how about simply re-writing the whole thing? We've just raised Series A, so we can afford a quiet moment. Moreover, a new hip technology/library/paradigm has just appeared, using it will bring so many benefits!
We've seen several cases when even the most experienced C-level execs have succumbed to the idea. It didn't end well in any of these cases. Neither it did for these guys. Others were lucky to have a good adviser who talked them out of it. Typically the outcome of the decision to re-write is lost momentum due to distraction, which can prove fatal to most startups. Less dreadful outcomes are changes in the management team, wasted financial resources or lost market share.
Of course ignoring technical debt is not an option either. In our experience, the best course of action for a startup in this situation is to gradually refactor instead of re-writing. There is plenty of great advice on how to refactor in a smart way. Backups, tests, CI pipeline, changing one thing at a time, logging, DB schema migration scripts, architecture diagram - these are some of the things needed for refactoring without unpleasant surprises. By the way, being in this situation is not so bad after all. For one thing, your startup is alive and is likely moving forward. Also, the chances are you are the one who wrote the original code, so you know intricacies of the business logic. Let the thought that there are people whose job is to refactor legacy systems they've never seen before soothe you in dire moments.
As a final comment, re-writing from scratch is not always the wrong option. It might be warranted when refactoring is out of question, for example when the system was implemented so long ago that all the people who know the language are already retired. The bottom line is that you should only decide to re-write when you fully understand the risks and are sure than you can handle them.