If you're like me, you worry a lot about whether the code you write is "good enough".
For the past year I've been building Gush, a personalized guide for things to do in NYC, which is currently in private beta. I'm constantly asking questions like "is this properly abstracted?", "does this have enough documentation?", "is this easy to reuse?", "is this maintainable in the long term?", or "is there a smarter way to write this?". Answering these questions is a valuable exercise, no doubt.
But Gush's future is uncertain. Code quality doesn't matter if we fail to gain user traction. I've had to learn to stop improving my code a bit earlier than I might like, because user's don't care how good the code is. For situations like mine, I think "code quality" needs a slightly different definition.
The first measure of code quality should be "does it work?". The next most important measure of quality is "does it provide an excellent experience for our users?". Until you prove that your product has traction, all other measures of quality are nice-to-have's.
Spending time on code quality is a privilege - one that must be earned by building a product that people love.
I'm not advocating sloppy code. I care about code quality and I do everything in my power to avoid accumulating tech debt. But for early stage projects, you have to find a balance, and that balance isn't always pretty.