Not sure what you classify as big, but we're a relatively small team (grown to 7 devs now) working on a CRUD-ish B2B desktop application, mostly installed on-pr

Not sure what you classify as big, but we're a relatively small team (grown to 7 devs now) working on a CRUD-ish B2B desktop application, mostly installed on-prem. We have a few hundred customers, well over half have some custom modules or integrations. Our niche involves sending and receiving data to official systems. Between our customers and the gov't, we constantly have to deal with a lot of external systems that change. With our customers we're often notified when stuff breaks, as very few of our customers have complete overview of their dependencies. So, being a small team with a relatively large codebase in constant flux and with customers who are quite price sensitive (so can't afford huge QA team), one of the better architectural decisions we made was to accept that we will have bugs and instead focus on reducing impact. Application-wise this means ensuring DB schema upgrades are done such that older versions of our application can use an upgraded DB without issue, and have a way for users to easily launch older versions of our application. Application updates are distributed frequently, and DB upgrades happen automatically over night. Few customers have a separate test systems, so this also allows them to test new major versions in production before rolling out to all users. Another choice that's worked out well is to not adhere to DRY when it comes to the integrations. Often customer B needs an integration that's the same as what customer A has, but with a few tweaks. For example they might both use the same ERP systems, but have slightly different configuration or workflow. In those cases we've found it's almost always much better to copy A's code and modify it, rather than refactoring into a common base. Yes we might have to fix a bug multiple times, but it also means when changing A's integration due to a change request, we don't have to worry about messing things up for customer B.