I would offer that there is a definite correct answer to this in most, if not all, cases. It can go either way depending on what is going in your company and market.<p>I would consider a few things before making your choice:<p>* Likelyhood of Pivot while Repurposing Codebase<p>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.<p>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.<p>* No One Likes Your Product<p>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.<p>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.<p>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.<p>Lot's of small errors are better than a few big ones.