Architecture for Contraction
robbyonrails.comI've spent my career writing software in non-profit/academic library/museum/archives sector with tiny teams (15-person development team would be an embaresment of riches), but usually with (an attempt at) cross-institution open source collaboration -- and this definitely matches some of the ideas I've developed about how to do so responsibly in tiny poor institutions.
The team size may not get smaller -- but it may disappear entirely, which kind of the only room it has to get smaller! More likely, the actual team size may stay the same, but the experience/skill/initiative level the team exhibits may drop drastically.
Still same stuff.
One thing you don't mention that I do prioritize is keeping dependencies up to date. I'm thinking "if the development team disappears entirely, I want the runway to be as long and affordable as possible for you to figure out what to do about this (likely with some per-hour consultancy support) before the thing dies or will require investment you can't afford to survive."
What if your team gets smaller? Not as a failure scenario. As a design constraint.