Building Software That Heals as Fast as It Breaks

What it's about

Frontend engineers can ship excellent UIs while knowing very little about availability, SLOs, or delivery metrics. Many teams are set up that way, and it works, right up until reliability issues, slow rollbacks, or missed incidents start limiting impact and trust.

This talk is about expanding the frontend role beyond the UI and into the system it runs inside. Not to turn frontend engineers into SREs, but to build enough systems awareness to make better tradeoffs. We’ll look at resilience as a delivery mindset, and how practices like atomic changes, trunk-based development, feature flags, and automated rollbacks directly influence availability and recovery, even when failures originate elsewhere.

We’ll connect these practices to real constraints like SLOs and DORA metrics, and show why failure tolerance is contextual, from regulated systems where mistakes are expensive to product environments where controlled failure is acceptable. The goal is simple: help frontend engineers understand where their work fits in the system, so they can ship faster without increasing risk, make safer changes, and increase their leverage within a team.

What you'll leave with

• How frontend decisions influence availability, reliability, and recovery
• What SLAs, SLOs, and DORA metrics mean in practice for frontend work
• Why resilience is a mindset across the SDLC, not a single tool or team
• How atomic changes, flags, and trunk-based development reduce frontend risk
• When failure tolerance is acceptable and when it isn’t
• How full-stack awareness helps frontend engineers ship faster with confidence

Who it's for

Frontend engineers who want to increase their impact by understanding how their work fits into the wider system

Where I've given this talk