Architecture for Contraction(robbyonrails.com)

3 pointsby robbyrussell9 ay önce2 comments

https://robbyonrails.com/articles/2025/10/13/architecture-for-contraction/

2 comments

I'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."

robbyrussell9 ay önce

What if your team gets smaller? Not as a failure scenario. As a design constraint.