✨ New rule - Bus Factor - Add guidance to clients and an email template for reducing single-developer risk

Requested by: @ricksu978 via YakShaver.ai 🦬
cc: @jakebayliss, @PennyWalker, @ricksu978, @calumjs, @tiagov8, @adamcogan

Hi Team!

  🟥  Watch the video (1 min 58 sec)

Pain

Add new content to Rules (Content) explaining how to protect client projects from single-developer risk ("bus factor"). This should include guidance on maintaining shared knowledge through practices like pair programming and minimum secondary-developer involvement, even when clients request cost reductions. The content should also include a drafted client-facing email that explains the rationale in clear, non-technical terms.

Acceptance Criteria

1. A new SSW Rule is added addressing single-developer risk (bus factor).
2. The content explains why projects should not rely on a single developer and references scenarios such as holidays or unexpected unavailability.
3. Guidance includes a concrete example (e.g., 1 day of secondary developer involvement for every 5 days of primary developer work).
4. The benefits of practices like pair programming and shared ownership are clearly described.
5. A reusable client-facing email template is included that explains this approach and its value.
6. The draft email is reviewed and approved by Jake and Rick (and optionally Callum).
7. Content tone is suitable for both internal guidance and external client communication.