Small teams do not have the same infrastructure budget as large teams. The limiting budget is not only money. It is attention.
Every new component creates work:
- Provisioning.
- Monitoring.
- Access control.
- Backup and restore.
- Upgrades.
- Security patches.
- On-call knowledge.
- Failure modes.
The right infrastructure choice is not always the most available or most elegant choice. It is the choice the team can actually operate.
Prefer boring ownership
For small teams, the best architecture is often the one with obvious ownership.
Questions I like:
- Who receives the alert?
- Who understands the failure mode?
- Who can restore from backup?
- Who knows whether this can be upgraded safely?
- Who can explain the tradeoff to the business?
If nobody owns the answer, the architecture is borrowing confidence from the future.
Make expensive decisions explicit
Some decisions are expensive because they are hard to reverse:
- Database topology.
- Network boundaries.
- Identity and access model.
- Data retention policy.
- Queue semantics.
- Multi-region assumptions.
These deserve short decision notes. Not a ceremony, just enough context to remember why the team chose this path and what would make the decision change.
Optimize for the next operator
Infrastructure is not finished when it works once. It is finished when another engineer can understand, verify, and recover it.
For a small team, that often matters more than using the newest tool. A simpler system with clear runbooks can be more reliable than a sophisticated system nobody can debug.