As the Guest Experience tribe entered a phase of rapid growth, we were adding new people, shipping features at a faster pace, and expanding into products our customers rely on daily. Growth was exciting, but it also came with trade-offs. Coordination between teams became harder, risk spread across more moving parts, and the number of production incidents climbed.
At this point, we had two options: slow down to protect stability, or invest in practices that would let us keep moving quickly without sacrificing quality. We chose the latter. By putting in place practical guardrails, clearer ownership, and higher standards of craftsmanship, we made sure our engineering culture evolved alongside our product.
This post shares the specific actions we took to meet the challenge head-on, focusing on common patterns we observed and the holistic solutions that now help us sustain progress.
Making Critical Changes Impossible to Miss
When production incidents spike, a frequent root cause is unnoticed edits to high-impact files such as configuration, security policies, or core modules slipping through reviews. These changes often go unrecognized because not everyone knows which files are risky to touch, and reviewers may not understand the broader implications if they’re not deeply familiar with that domain.
By explicitly flagging important file modifications in pull requests, reviewers gain the context they need. This reduces the chance that subtle but critical updates go unexamined.
It also supports onboarding. New developers quickly learn which parts of the codebase carry outsized risk, improving shared understanding across teams.
Why did we introduce this?
Online check-in in the Demo environment went down, disrupting sales demos and testing for larger customers. The root cause was a single-line configuration change that was overshadowed by other edits in the same PR.
Surfacing Testing Gaps Before Merging
Low code coverage often correlates with fragile releases. Untested paths are where regressions hide.
By integrating coverage visibility directly into pull requests, we surface under-tested areas at the moment decisions are made. This nudges contributors to expand tests and validate critical logic before code lands on the main branch.
This consistent feedback loop:
- Builds stronger testing habits
- Reveals blind spots early
- Leads to more resilient software that resists failures under real conditions
As coverage insights become part of everyday review, teams gain a clearer picture of risk, enabling more disciplined, incident-resistant merges.
Why did we introduce this?
We saw multiple guest-facing failures where insufficient test coverage was the common thread:
- Kiosks froze on a grey screen during check-in due to a refactor bug
- The search bar threw errors whenever results included bills, due to unsupported date formats
- The booking engine went blank when one room category was unavailable, caused by a shared component bug
PR-level coverage expectations now make these blind spots harder to miss and reduce downstream incident response work.
Freezing Deployments When End-to-End Tests Fail
A scheduled deployment freeze triggered by failing end-to-end tests becomes a critical guardrail. It prevents unstable code from progressing to production until issues are investigated and fixed.
Want to see these solutions in action?
Check out our open roles and join the team!
This deliberate pause enforces accountability, prioritized stability, and guarantees known breakages never reach customers.
Why did we introduce this?
Feature-flag initialization once failed silently, causing every flag to evaluate to “off.” All beta features stopped working, creating operational issues across many properties.
Now, if E2E runs fail, deployments stop. This makes sure this type of incident is caught before it escapes to production.
Where We Are Today
We didn’t just confront the dip in quality and the rise in production incidents, we rallied. We reshaped how we build and ship.
Now:
- Reviews concentrate on high-risk edits
- Untested paths are visible early, with time to fix
- Unstable releases are stopped in the pipeline, not reaching customers
The result is a system leaning into resilience. Even more importantly, our culture is evolving with it: stronger ownership, sharper craftsmanship, and tighter collaboration have us trending in the right direction.
The outcome is a more predictable delivery cadence, fewer avoidable outages, and renewed trust, both inside the team and across the properties that rely on us daily.
Building a Resilient Culture
Rapid growth can easily overwhelm quality if teams keep pushing forward without adjusting how they build and ship. At Mews, we learned that sustainable progress comes from guardrails that are both practical and cultural: flagging critical changes, making test gaps visible, and freezing deployments when stability is at risk.
These changes have already paid off in fewer incidents, more predictable releases, and stronger collaboration. Most importantly, they reinforced a mindset that quality isn’t a trade-off against speed but a foundation for scaling confidently.
We’re still learning and evolving, but these steps have helped us turn a period of instability into a stronger engineering culture that’s better prepared for the next wave of growth.
