Probably the microservices-based one for async video messaging (i.e. Slack for video) for workers in the field. Each service was small enough that we could do a blue-green deploy to prod in about 2 minutes running only the service's tests and a tiny (intentionally limited) set of about 8 system journey tests (can onboard a new user, user can create a contact/group, user can send a common content-type message, user can receive messages, user can react/respond to a message). Every commit to main/master automatically either deployed to prod or broke the CI/CD pipeline and needed to be fixed ASAP. Each service was also well-known by team members that it literally could be rewritten in a week or two if desired to change a key part of its design.
Thinking about what I wrote, I suppose my criteria for a good codebase is one that has the lowest friction to change: a fast edit/run/test/debug loop, a meaningful sense of security (without dogma), and fast automated deployment/revert (via blue/green). Given those a bad codebase can become a good one again (by uncoordinated action of individuals) without everyone having to buy into a large investment.
