But then you run into team problems with engineers feeling very exhausted working with your codebase and you have to constantly deal w/ missing confidence in the developed software.
In my experience "Acknowledged technical debt" is usually a good middle ground to work with. It usually also works with die-hard engineers.
Building software is not about writing optimal code. The goal is to have confidence in the code you wrote. Constantly wondering how something works only to realize that it doesn't is energy draining and needs to be avoided.
Acknowledge and document technical debt. Explain (in notes) how stuff is meant to be, how it should be, what does work. Essentially you want to reduce the amounts of "WTFs" the next person (eg future you) has reading the code.
The most important lesson here is: technical debt can be a good thing. You buy expensive short-term impact with future time. Very often you never need to "cheque" that future time because that part of the product might have been thrown away.
That said, tracking tech debt is important. Creating issues in Jira, or whatever you're using, can be valuable over time. Maybe there's one specific piece that gets in your way of building features every week, and tracking it will make it more obvious or help you realize, e.g. "we could make this 10x better with a few hours of effort vs. 12x better with a few days". Remember that product-market fit stage is when you'll have the highest percentage of your time to dedicate to building features -- might as well make the most of it.
I would consider a few things before making your choice:
* Likelyhood of Pivot while Repurposing Codebase
Obviously, people don't just go into a startup thinking that they are going to pivot and they aren't easy to predict because it means something unexpected is working well. Your architecture should allow for services and components to be broken out, e.g you will suffer massive technical debt if you want to pivot a service that is dependent on a schema based mysql database with a very rigid data model. All of this is set up on docker instances with crazy services and held together with a staple gun.
If you want to carve out a small service that is working, it will be impossible as it is inextricably tied to your bloated deathmachine. Death will quickly catch up before your revenue does if you have to port and rewrite your entire application and redeploy it. Make sure you can be sort of agile, in the sense that you at least have a componetized modular structure for services large enough to charge for.
* No One Likes Your Product
If your product is not great and no one wants it, having an immaculate and eloquent codebase will kill you as well. Something that does a great job performing a task no one will pay for is also negative.
my 0.02, tolerate technical debt at the micro level, but never at the macro level. E.g you can do refactoring if you need to, your code is not extremely dry, there are plenty of optimizations available but your code/functions work.
DO NOT TOLERATE IT AT THE MACRO LEVEL You used the wrong tool, are trapped on the wrong database structure, your application is extremely unstable because of a major design choice, etc.
Lot's of small errors are better than a few big ones.
However, I don't think it's a good goal to aim for.
Like @andreasklinger and @hashkb said, you should have agreement with your engineers about your limit.
Refactoring can never be enough, because we always try to improve, try to be better.
You can think about the "later days" when you can come back on your codes and fix those crap codes, but you know you won't. The bigger the debt for now, the costlier it will be in the future.
Trust me, my startup is managing on that.
Startups with a short runway probably don't have a future, so technical debt can be viewed as something with little downside that gets you to market faster. The tradeoff is that as your runway gets shorter debt makes it harder to try new things.
I'd say don't worry too much about technical debt before p/m fit. However, don't let anyone on your team use debt as an excuse for half-assing something that could deter finding market fit.
There is also something to be said for building a v1 MVP to prove product/market fit, and then build an entirely separate v2 that is refined to what you have learned.
At what point do you consider p/m fit achieved?
How many developers are working on the software?
What makes you think features are important?
How mature is your market?
What's your value proposition? Etc etc etc.
If you are entering an established market then code-quality can be your biggest competitive advantage.
