The purpose of writing clean code is to reduce costs.
This seems counter-intuitive because writing automated tests, reducing function complexity, and maintaining proper version control procedures takes time.
Obviously, not writing clean code is cheaper in the short term. In the long term, bad things can happen, including going out of business.
How long is long term? How quickly is clean code paid off? It’s hard to answer. Sometimes one day. Sometimes a few months. But it’s worth pointing out a fallacy. People often think that they’re short on resources now and they will have more resources later. So let’s not write clean code now that we’re building the product and have zero income—let’s leave it until a few months later, when we’ll have paying users. The problem is that when we actually have paying users, they are often screaming paying users. The system will need a huge amount of effort to maintain, and the pressure to develop more features may be too large. Once you start developing with unclean code, you establish a habit that will be hard to unroot when such pressure inevitably arrives.
That said, being too picky about clean code can increase costs too much. Finding the right balance is an art. But most people suffer from being too lax, not by being too picky. Therefore, it’s hard to err on the side of too clean.