When a product update is in the works at Realtor.com, the mile-makers come fast and frequent.
“My rule is to ship small, observable changes behind guardrails,” Gelan Almagro, senior manager of engineering, said.
Almagro swears by progressive rollouts so that no single release carries outsized risk, and he measures success by how reliably the product behaves in the wild — not just in staging.
“The clearest expression of that is our Service Level Objectives around user-facing error rate and latency on critical journeys,” he said.
Want an inside look at how engineers at Realtor.com balance velocity with safety? Almagro shared the secret to fast and safe releases — and the KPI that proves his method works, in this latest Built In feature.
Realtor.com is an open real estate marketplace.
What’s your rule for fast, safe releases — and what KPI proves it works?
My rule is to ship small, observable changes behind guardrails. We default to trunk-based development, heavy automation in CI/CD and progressive rollout (feature flags and canaries) so that no single release carries outsized risk. The KPI I watch most closely is change failure rate on production deployments — when that stays low even as deployment frequency increases, I know we’re moving fast without burning trust with customers or the team.
What is the pace of work like on the engineering team at Realtor.com?
“My rule is to ship small, observable changes behind guardrails. We default to trunk-based development, heavy automation in CI/CD and progressive rollout (feature flags and canaries) so that no single release carries outsized risk.”
— Gelan Almagro, Senior Manager of Engineering
Which standard or metric defines “quality” in your stack?
For us, “quality” is defined by how reliably the product behaves in the wild, not just in staging. The clearest expression of that is our Service Level Objectives around user-facing error rate and latency on critical journeys (e.g., search, listing views, lead submission). If we’re consistently inside those bounds — and not burning error budgets — then it’s a strong signal that our automated tests, code review and observability are doing their jobs. When SLOs slip, that’s our cue to slow feature work and invest in hardening.
Name one recent AI or automation deployment and its impact on the team or business.
Recently, my team shipped an internal AI assistant that plugs into our observability and delivery tooling. It automatically correlates alerts with recent code and config changes, proposes likely owners and drafts first-pass incident timelines and release notes. This has reduced the time we spend on triage and coordination, cutting down on “who owns this?” pings during incidents and gives stakeholders more consistent, timely updates when something does go wrong.
