Operational platform for SFR3 & American Avenue

SFR3 and American Avenue operate a large ecosystem managing the full lifecycle of single-family rental homes — from acquisition and renovation to leasing, maintenance, and resident support.

At this scale, the product wasn’t a single application, but a set of interconnected tools supporting different parts of the operation — including mobile tools for field teams (OnSite), internal web applications, and multiple supporting systems.

Over time, this ecosystem became increasingly fragmented. Information was spread across tools, workflows were not aligned, and decisions depended on data coming from multiple places.

When operating at this scale, even small inefficiencies translated directly into operational cost and delays.

One of the directions I explored was consolidating parts of this ecosystem into more unified internal tools, such as FlightDeck, to provide a clearer operational view across systems.

I worked at the intersection of product, operations, and engineering — focusing on aligning decisions across teams in a constantly evolving environment.

My role combined hands-on product design with shaping workflows and supporting operational decisions that impacted delivery speed, cost, and system scalability.

The business was evolving faster than the software supporting it.

Priorities shifted over time — from acquiring homes, to renovating them at scale, and later to ongoing maintenance and operations. Each phase introduced new requirements and different ways of working.

At the same time, the ecosystem consisted of multiple interconnected tools. Shipping new functionality often depended on changes across several systems, which had to align to support real workflows. The team had to deliver continuously to support day-to-day operations, often under tight timelines and with limited design capacity.

The real challenge wasn’t just building features — it was aligning product, operations, and engineering around decisions that kept the system understandable as both the product and the operational model evolved.

The team operated in constant tension between speed, clarity, and ROI. Perfect solutions were not an option — what mattered was whether they worked in real field conditions.

Over time, this approach led to denser interfaces and overlapping responsibilities. It became harder for users to know what to do next — especially when working under time pressure in the field.

The system landscape included multiple interconnected products supporting different parts of the operational lifecycle:

• OnSite (iOS) — field operations: inspections, scoping, quality control, and task execution.
• Internal tools (Web) — operations, reporting, and process coordination.
• Resident Portal — payments, lease visibility, and communication.
• Vendor Portal — job management and execution tracking.
• Brand Websites & Home Listing — SFR3 corporate site and American Avenue platform used for browsing, reserving, and renting homes.

In addition, several custom backend tools and third-party SaaS solutions supported specific workflows.

The OnSite app was the primary tool used by field teams. It supported inspections, task execution, and communication with internal teams and vendors, as well as resident communication where needed.

The structure of the app evolved alongside changing roles within the company. As the organization changed, responsibilities shifted, and strict role-based separation was not always practical.

Over time, this created overlapping responsibilities and a structure that tried to support multiple use cases within a single interface. I introduced incremental improvements — clearer navigation, better separation between task and property context, and more predictable access to information.

Several areas required deeper changes. One example that had a significant impact was the Quality Control (QC) workflow.

I took ownership of redefining how quality control should work — not just as a feature, but as an operational decision point.

Quality control had become a documentation exercise — rather than a decision about whether a home was ready for the market.

The process itself was rigid and linear. Inspectors had to go through a long checklist step by step, regardless of the actual condition of the property. In practice, this didn’t match how inspections worked. Users often had to revisit the same areas multiple times just to complete required steps.

This resulted in long, static reports — often exceeding 80–90 pages — combining rigid checklists with large volumes of photos. Since images were not directly tied to specific issues, finding relevant information required manually navigating through the entire document.

Additionally, these reports had to be printed and physically handed over to vendors, as they had no direct access to the system. This introduced delays and broke the feedback loop.

The process relied heavily on a separate tool (FotoNotes), which required a stable internet connection to function properly. In field conditions, connectivity was often unreliable or unavailable. This forced inspectors to either delay documentation or risk losing data altogether.

To cope with this, inspectors started working outside the system — capturing photos or notes separately and uploading them later. This led to missing information, inconsistencies, and costly re-inspections.

The key change was not in the interface, but in the underlying model. Instead of asking how to improve documentation, I reframed the problem around decision-making.

I shifted the process from a “document everything” approach to an issue-based model. If the property met the required standard, no action was needed. The user’s attention was focused only on elements that required fixing.

This reduced cognitive load and aligned the process with how inspections actually happened in the field.

I redesigned the QC process as a continuous loop rather than a one-time documentation step. Inspectors captured issues directly in the system, attaching photos and context where needed.

Project managers and inspectors could review and acknowledge issues in real time. In many cases, problems could be resolved while both parties were still on-site.

The impact was visible in day-to-day operations.

Inspection time dropped from 3–4 hours to around 1 hour in many cases. Teams spent less time documenting and more time resolving actual issues.

Cycle time reduction: By resolving issues faster on-site, this significantly shortened the time it took to get a house back on the market.

Lower Operational Cost: This nearly eliminated the need for “re-inspections” caused by poor documentation.

Most importantly, the process aligned with real-world workflows, making it easier for teams to act quickly and make decisions on-site.

This project reinforced my belief that UX is a business lever. Reducing cognitive load for a field worker isn’t just about usability — it’s about reducing operational debt and improving how work flows through the system.

It also required aligning multiple teams around a shared understanding of what “quality” means in practice.

Today, I think less in terms of screens and more in terms of how design decisions affect speed, cost, and scalability across the entire product ecosystem.

Designing in a hyper-growth environment taught me that "perfect" is the enemy of "shipped." Success wasn't about the most polished UI, but about identifying the one friction point that, when fixed, unlocked the entire operational flow.

Product design, in practice, is about knowing where to put the lever to move the biggest rock.