Unless your project is tiny or brand spanking new, your codebase should be a mess. If it’s not, you have a problem: you’re not iterating enough. Or if you are iterating, you aren’t doing it in front of customers. This isn’t to say that the code should be unmaintainable spaghetti code, or so unorganized you can’t find a damn thing and when you do the comments only confuse you more. Rather, when you look at it, you should want nothing more than to refactor, rewrite and rethink chunks of it all over the place.
Don’t.
Unless you need to touch the code for something you’re working on, resist the siren’s call. It’s working fine and has collected many hours of bug fixes, tweaks and changing requirements. Think of it as lazy evaluation; you may pivot again and find out you don’t even need the code at all. This is about efficiency. Don’t waste bandwidth cleaning up good (but ugly) code when you could be discovering what code you should actually be writing.
There are, I’m sure, good counter arguments. But, if you’re starting a company and building some software at it’s core, embrace the mess. When you find the business model you can hire folks smarter than you to re-write the thing, now that you finally know what it should look like (You’ll be hiring all sorts of pros to clean up the rest of the business, why not the code?).
