To deliver on that promise, Stake operates as the renter's financial layer, using banking infrastructure to financially empower renters while proving to properties that Stake residents pay more reliably and stay longer.

I served as Senior Product Designer and Product Lead, owning end-to-end UX across mobile and web, core system architecture and IA, and the design of rewards, banking, and rent-payment flows. I partnered closely with product, engineering, and leadership, drove major system-level pivots from Stake 5.0 through Mobile 6.0+, and defined design principles around trust, legibility, and financial UX.

Stake's north star is instant, in-app cash back across the renter journey, supported by an ecosystem of rewards and financial tools that materially improve renter financial health. By incentivizing key moments from apartment search to renewal, Stake delivers real value to renters while generating measurable financial signals for property owners.

Every product decision sits at the intersection of renter empowerment and property performance.

Features must deliver meaningful value to renters while creating defensible, trackable impact for properties. The goal is not one-off rewards, but an ongoing financial relationship.

Stake launched as "cash back on rent," but functioned like a transactional rewards product. Users collected rewards and churned, payouts were delayed and confusing, and trust was fragile. Lifetime value remained low, and Stake lacked credible proof that it improved renter financial health or property outcomes.

At a more fundamental level, users did not understand the system. An escrow-based rewards experience prioritized visual novelty over comprehension, using a circular slider to display rent match and savings bonus balances. Users struggled to understand how rewards worked, when they would be paid, or why multiple balances existed. The result was predictable churn and no defensible claim of renter wealth.

What was broken

Users could not trust what they did not understand. Stake 5.0 removed novelty-driven escrow visuals and replaced them with a clear, standard rewards model. Balances, reward types, and timing were made explicit, establishing a stable mental model. This solved comprehension, but not outcomes.

Legibility Is Not Enough

Stake 5.0 improved clarity, but it did not change behavior or business economics. Rewards remained one-off transactions, lifetime value stayed low, and Stake still lacked proof that it improved renters' financial standing. Legibility was necessary, but insufficient.

Problem

To change behavior and economics, Stake needed financial infrastructure. The Stake Visa Debit Card became the wedge that kept cash back in-network, made balances actionable, and multiplied value through additional cash back on spend. Engagement shifted from payout to participation, making renter wealth defensible.

Scope Creep

Introducing a debit card required Stake to operate like a real banking product. We expanded core banking functionality including funding flows, card management, recurring deposits, and onboarding for account setup. These were not incremental features, but infrastructure unlocked by the debit card itself.

Banking was not enough

Banking enabled engagement, but it did not direct it. In parallel, we built incentive tooling to guide users toward high-value actions. Features like the Earn More guide and Pay Rent guide made the next best action explicit and tied rewards to behavior over time, transforming Stake from a passive financial surface into an active behavioral system.

Earn More Guide

The Earn More guide translated complex, multi-step actions into a clear progression tied to increased cash-back value. Each step often spanned multiple days and systems, including card delivery, activation, funding, and off-platform rent portals.

The guide evolved from a checklist into a state-aware tracker that handled nested steps, partial completion, off-platform actions, and property-specific offers. Over time, it became an orchestration layer aligning infrastructure, incentives, and external systems around the behaviors that mattered most.

Onboarding

Incentivizing behavior starts at onboarding. Onboarding is not just about teaching users how the product works, it defines what the product is, how it should be understood, and which actions matter most. We treated onboarding as a behavioral system, not a tutorial.

Before the UI, we designed a logical system that consistently guided users toward the next highest-value action.

The underlying logic handled complexity and sequencing, while the experience itself remained simple and intuitive for the user. Next, we designed the UI that established Stake's role in the renter's financial life, made incentives explicit, and created early reward structures that guided users toward high-value actions. This gave the broader incentive layer context, direction, and momentum from the first interaction.

This onboarding flow increased unlocks, but exposed a core problem: The framing of "pay rent with Stake" obscured two required steps, setting up Stake Checking, and configuring direct deposit. This confused users and caused users to drop. In the next iteration, we made Stake Checking the primary action and reframed direct deposit as an optional funding method that unlocked additional value. This clarified intent, reduced drop-off, and aligned onboarding with the actual setup flow.

Pay Rent (Almost)

Rent payment was the hardest problem to solve, not because of UI, but because of system constraints. In order for the business to generate interchange revenue from the transaction, rent payments needed to flow through ACH rather than debit rails, which immediately introduced complexity. ACH requires account funding, funding requires time, and timing varies depending on where a renter is in their billing cycle. For 'one click' rent payments, we would need to integrate with each and every rent payment portal. This was out of the scope for this launch, so we stuck with the guide format.

On the user side, rent is not a single clean transaction. Payments can include fees, utilities, taxes, overdue balances, partial payments, and shifting due dates, all governed by external portals with their own rules. Not to mention autopay setup, auto-fund setup, editing payments, payment editing windows, and payment history. Although these edge cases and sub-features resulted in a complex flow logic, it was all abstracted to the user in the final experience.

These guided flows were not ideal, but they were necessary steps that allowed us to move towards our north star even when tech limitations blocked us. Rent payment did not struggle due to design quality, it struggled because it exposed the full complexity of property tech infrastructure.

Engagement and Economics

As banking features expanded, a new issue surfaced. Users could set up automatic transfers and disengage entirely. To address low monthly engagement and reward breakage, we introduced Claimed. Instead of depositing rewards directly into checking, rewards sat in escrow until claimed. Claiming required opening the app and was tied to the next recommended action.

This increased monthly engagement, created natural moments to guide users deeper into the product, and reduced breakage from users who never logged in. Launching claimed increase out claim rate by 43%, reduced breakage, and increased engagement rates.

At this stage, the limiting factor was no longer feature completeness, but depth of engagement: We needed a large subset of users to adopt Stake Checking as their primary account. Interaction with the checking account remained too shallow, and without stronger account primacy, Stake could not grow lifetime value or support a higher business valuation.

To solve this, we shifted from a collection of loosely connected features to a tiered unlock system. Instead of offering all functionality upfront, we gated the features that are most valuable to the user behind the behaviors that mattered most to the business. These two key decision points were presented to the user during onboarding.

What I'd do differently

In hindsight, I would have prioritized account primacy earlier. We spent meaningful time improving rewards clarity and engagement before fully committing to the behaviors that drove long-term economics. Pulling primacy-forward incentives and tiered unlocks earlier would have accelerated learning and reduced time spent optimizing low-LTV behaviors. I would also formalize trust-building as a first-class system sooner. We treated trust as a combination of UX polish, property endorsement, and consistency, but lacked a single, measurable trust strategy early on. Defining explicit trust signals and success metrics upfront would have made experimentation more focused and outcomes clearer. Finally, I would scope rent payments more aggressively around constraints from day one. Early iterations tried to approximate a "pay rent" experience before the infrastructure and partnerships were in place. Framing rent payment explicitly as a staged capability earlier would have reduced user confusion and internal churn while keeping expectations aligned.