It's not an absolute rule, I've certainly inherited projects in a consulting capacity that were written by small teams and were atrocious. But more often than not, a small team working for a small company has fewer of the internal "forces" that incur "technical debt."

Those forces are things like

- Silo'd teams working on a common code base in parallel but never talking to each other, thus duplicating code and having wildly different conventions

- Layers of middle management each with different management styles, leading to inconsistency and product-wide short-cuts

- Dealing with sudden success-induced scalability disasters that result in bandaid solutions

- More employee churn which means that the way we did things yesterday is not the way we're doing things today because someone new is in charge ... more inconsistency in code and software decisions

- More "old code." Companies very rarely do rewrites and when they do they're often failures. So the bigger the company, the more "legacy" spaghetti code typically because you don't fix what isn't broken (especially when the entire system is broken because it's one big giant mess that no one understands and yet somehow it actually works ... as long as we don't breathe on it or get a sudden surge of new account sign-ups).