Fixing a Broken Rental Lifecycle: A Multi-Product UX Case Study

Renting a home is broken for everyone involved.

If you're a tenant, the experience goes something like this: browse five listing platforms, message a dozen brokers on WhatsApp, schedule visits through text messages, show up to find the apartment looks nothing like the photos, eventually find something acceptable, deal with unclear paperwork, move in, and then spend the next year wondering who to call when the plumbing breaks.

If you're a broker, you're managing leads across WhatsApp groups, tracking visit schedules in your head, matching properties to requirements from memory, juggling calls from tenants and landlords simultaneously, and running your entire business on a combination of instinct, spreadsheets, and prayer.

If you're a landlord, you're collecting rent through bank transfers and manually tracking who's paid, handling maintenance complaints via WhatsApp messages that disappear in the scroll, managing occupancy across multiple properties from a notebook, and relying on brokers you've never met to find tenants you've never screened.

Three completely different experiences. Three completely different pain points.

But one shared reality: the entire rental lifecycle — finding, booking, living, managing — was running on disconnected tools that were never designed for rental operations.

StayPe's vision was to fix this. Not by building one app for everyone — that never works when user needs are this different — but by building a connected ecosystem where each user type got exactly the product they needed, while all products shared the same underlying rental journey.

"Tenants used listing platforms. Brokers used WhatsApp. Landlords used spreadsheets. Everyone was solving the same problem — renting — with tools that were never designed for it."

The ecosystem, not the app

Most PropTech case studies describe a single product. A listing app. A property management tool. A broker CRM.

This project was four products:

Four products. Three user types. One rental lifecycle.

The design challenge wasn't any individual product — each one, on its own, was a manageable mobile or web project. The challenge was making all four feel like parts of the same ecosystem while serving fundamentally different needs.

A tenant booking a visit in StayPe needed to trigger a notification in StayRealtor for the broker. A broker adding a property in StayRealtor needed it to appear in StayPe for tenants. A landlord tracking rent in StayRealtor needed it to connect to the tenant's payment flow in StayPe.

The products didn't just share a brand. They shared a data layer, a workflow layer, and a lifecycle.

The app that changes shape

StayPe — the tenant app — had the most unusual product concept in the entire project.

Most apps present the same interface regardless of where the user is in their journey. A food delivery app looks the same whether you're a first-time user or someone who's ordered a thousand times. A banking app shows the same dashboard whether you opened your account yesterday or ten years ago.

StayPe was different.

The app transformed based on the user's stage in the rental lifecycle. It wasn't one app with all features visible. It was effectively three apps wearing the same skin — each one appearing when the user needed it.

Level 1: Explorer

"Where should I live?"

When a user first opens StayPe, they're looking for a home. The app presents itself as a property discovery platform:

• Property search with filters and recommendations

• Detailed property listings with verified information

• Saved listings and comparison tools

• Visit scheduling

• Broker discovery

• AI-powered property recommendations

• Neighborhood information

• Rental price comparisons

At this stage, the app looks and behaves like a polished listing platform. Clean search. Beautiful property cards. Filter by budget, location, type, amenities. Save favorites. Schedule visits.

Nothing about household management. Nothing about rent payments. Nothing about maintenance requests. Those features exist — but they're invisible, because the user doesn't need them yet.

Level 2: Booker

"How do I secure this property?"

Once a user selects a property and begins the booking process, the app transforms. Discovery features recede. Booking features emerge:

• Visit management and tracking

• Booking progress and status

• Payment confirmation workflows

• Rental documentation

• Move-in preparation checklists

• Property status tracking

The interface shifts from browsing to converting. The emphasis moves from "explore options" to "complete this transaction." The design language becomes more focused — fewer choices, more guidance, clearer next steps.

This transition wasn't just a feature swap. It was a mindset shift communicated through design. The browsing phase is about possibility. The booking phase is about commitment. The interface reflected that emotional transition — from wide and exploratory to narrow and purposeful.

Level 3: Resident

"How do I manage my home?"

After move-in, StayPe performed its most dramatic transformation.

The discovery and booking features disappeared entirely. In their place: a household management platform.

• Housemate management

• Vehicle registration

• Pet profiles

• Daily help services (cleaning, cooking)

• Maintenance request tracking

• Utility tracking

• Bills and receipts

• Complaint submission and tracking

• Community features

• Household profiles

The app that helped users find a home was now helping them live in it.

This was the phase most rental platforms ignore completely. Every PropTech product fights over discovery — helping users find properties. Almost nobody stays for what happens after the lease is signed.

StayPe stayed. And the post-move-in experience became one of the most unique and defensible parts of the entire ecosystem — because a tenant actively using StayPe to manage their household is a tenant who won't switch to a competitor when their lease renews.

"Most rental apps abandon users after the booking. StayPe followed them home. The app that helped you find an apartment became the app that helped you manage your life in it."

Why the transformation mattered

The three-level architecture wasn't a clever feature. It was a retention strategy embedded in product design.

Rental platforms have a fundamental business problem: once a tenant finds a home, they have no reason to open the app again until their lease expires. That's twelve months of silence. Twelve months of lost engagement. Twelve months where a competitor could acquire that user.

By transforming into a household management platform, StayPe created daily-use value beyond the transaction. Submitting a maintenance request, tracking a cleaning service, managing a utility bill — these are regular, ongoing interactions that keep the app installed and the user engaged.

When the lease ends and the tenant searches again, they're already in StayPe. The lifecycle is complete. And it starts over.

StayRealtor: the professional side

While StayPe served tenants, StayRealtor served the people who make the rental market work: brokers and landlords.

These are fundamentally different users with fundamentally different needs — but they shared enough operational overlap that building one professional platform (instead of two separate apps) made sense.

The broker experience

Brokers are salespeople. Their world revolves around leads, conversions, and volume. They need to move fast, manage many relationships simultaneously, and never let a prospect fall through the cracks.

The broker experience was designed around a lead management funnel:

New → Contacted → Visit Scheduled → Booking Completed → Move-In Completed

Every lead in the system existed at one of these stages. The broker's dashboard showed the funnel — how many prospects at each stage, which ones needed action, where the bottleneck was.

This was deliberately borrowed from CRM design patterns, not real estate patterns. Most real estate tools organize by property. We organized by lead. Because a broker's business succeeds or fails based on conversion, not inventory.

AI property matching

One of the platform's most impactful features for brokers.

The traditional broker workflow: a prospect describes what they want ("2BHK in Koramangala, under ₹25,000, pet-friendly"). The broker mentally searches their inventory, checks availability, and recommends options from memory.

This works when you have twenty properties. It collapses when you have two hundred.

StayRealtor's AI matching automatically connected lead requirements with available properties. When a new lead came in with specific criteria, the system surfaced matching properties from the broker's inventory — and from the broader StayPe ecosystem.

This reduced the time between "I'm looking for a place" and "here are three options" from hours to seconds. And it eliminated the most common failure mode in brokerage: forgetting about a property that perfectly matches what a client needs because it's buried in a spreadsheet.

Features that surprised us

Several features emerged during the design process that we hadn't anticipated:

Broker Connect — a networking feature that let brokers connect with other brokers. In Indian real estate, brokers frequently collaborate: one has the tenant, another has the property. Broker Connect formalized a workflow that was already happening over phone calls and WhatsApp groups.

QR-based lead collection — brokers could generate QR codes for properties, marketing campaigns, or open houses. Scanning the QR code captured lead information directly into the broker's StayRealtor pipeline. Physical marketing (flyers, signboards, newspaper ads) connected instantly to the digital funnel.

Personalized broker websites — every broker could generate a branded property website that automatically collected leads and visit requests. This gave individual brokers the kind of digital presence that usually requires a marketing team, and every lead generated from the website flowed directly into StayRealtor.

These weren't in the original brief. They emerged from understanding how brokers actually work — the informal networks, the offline-to-online gap, the need for individual branding in a relationship-driven business.

The landlord experience

Landlords needed something entirely different from brokers.

Brokers think in sales funnels. Landlords think in operations.

Their questions were:

• "Which of my properties are occupied?"

• "Who hasn't paid rent this month?"

• "What maintenance complaints are open?"

• "When does this tenant's agreement expire?"

We designed the landlord experience around property portfolio management:

Property portfolio overview — all properties (flats, PGs, shared housing) visible in one dashboard with occupancy status, rent collection status, and active issues.

Tenant management — current tenants, agreement status, move-in/move-out tracking. A clear picture of who lives where and when things change.

Rent collection — this was the killer feature for landlords. Due rent tracking, payment records, payment history, automated reminders, and rent reports. No more WhatsApp messages asking "did you transfer the rent?" The system tracked it, reminded tenants, and showed landlords exactly who'd paid and who hadn't.

Complaint management — tenants could submit complaints through StayPe. Those complaints appeared in the landlord's StayRealtor dashboard with status tracking, assignment capability, and resolution timelines. The leaky faucet WhatsApp message became a tracked, manageable work item.

Property creation workflows — a guided, multi-step onboarding process for adding new properties. Different property types (flats, PGs, shared accommodation) had different data requirements, and the workflow adapted accordingly.

"Brokers needed a CRM. Landlords needed an operations dashboard. They were on the same platform, but they never saw each other's interface."

The websites: separate funnels, one brand

The ecosystem included two marketing websites — each targeting a different acquisition goal.

StayPe Website

Goal: Convince tenants to download the app and start their property search.

The tenant website communicated:

• Property discovery capabilities

• The booking workflow and how it works

• Verified brokers and why that matters

• The post-move-in experience (the differentiator)

• Trust signals — verified listings, secure payments, complaint resolution

The tone was consumer-friendly, warm, and aspirational. Finding a home is emotional. The website respected that.

StayRealtor Website

Goal: Convince brokers to adopt the professional platform.

The broker website communicated:

• Lead management and AI matching capabilities

• Property management tools

• Personalized website generation

• QR-based marketing features

• Business growth and analytics

The tone was professional, data-driven, and business-focused. Brokers evaluate tools based on ROI. The website spoke that language.

The two websites shared the same design system — consistent typography, color palette, component patterns — but had distinctly different voices. A tenant browsing StayPe's website and a broker browsing StayRealtor's website would both feel they were looking at the same brand. But the messaging, the value propositions, and the calls to action were entirely different.

The design challenge nobody warns you about

Designing a multi-product ecosystem isn't three times harder than designing one product.

It's exponentially harder.

Because every decision in one product affects every other product.

Visual consistency across different contexts

The StayPe app was consumer-facing — it needed to feel warm, inviting, and effortless. The StayRealtor app was professional — it needed to feel efficient, data-rich, and business-grade. The websites needed to bridge both worlds.

One design system had to serve all four products without making any of them feel generic. This meant:

• Shared foundations: Typography (Satoshi), icon library (Phosphor), color palette (primary blue-purple #6A71F1), spacing system, border radius, elevation patterns.

• Different expressions: The tenant app used more imagery, softer spacing, and emotional design moments. The professional app used denser layouts, tabular data, and action-oriented patterns. The websites used the marketing expression — larger typography, hero sections, testimonial patterns.

The design system wasn't one set of components. It was one set of principles expressed through different modes.

Data flows between products

When a broker added a property in StayRealtor, it needed to appear in StayPe for tenants. When a tenant requested a visit in StayPe, it needed to appear in the broker's StayRealtor dashboard. When a landlord set rent due dates in StayRealtor, the tenant needed to see reminders in StayPe.

These cross-product data flows weren't just engineering problems. They were design problems. How does a visit request look when the tenant creates it? How does that same request look when the broker receives it? What information does each side see? What actions does each side have?

We had to design the same data from two perspectives simultaneously — ensuring that both sides of every interaction felt natural and complete.

Three mental models, one ecosystem

This was the deepest challenge.

Tenants think in journeys. "I'm looking for a home. I'm booking a home. I'm living in a home." Linear. Progressive. Emotional.

Brokers think in funnels. "I have leads. I need to convert them. I need to close deals." Sales-oriented. Volume-driven. Competitive.

Landlords think in portfolios. "I have properties. I need to manage them. I need to collect rent." Operational. Status-oriented. Recurring.

Journey. Funnel. Portfolio. Three completely different mental models for the same domain.

The ecosystem had to respect all three without forcing any user into someone else's worldview. A tenant should never feel like they're using a broker tool. A broker should never feel like they're using a tenant app. A landlord should never feel like either.

The design system

Building a design system for one product is hard. Building one that works across four products with three different audiences and two different platforms (mobile and web) is a different kind of challenge entirely.

Typography: Satoshi

Chosen for its clarity and modern digital presence. Satoshi provided:

• Clean rendering on mobile screens — where most interactions happened

• Strong readability in data-dense contexts (broker dashboards, landlord portfolios)

• Modern personality that felt consumer-friendly without being casual

• Consistent weight range across headlines, body text, and interface labels

Satoshi was the glue. It's the first thing that told users — across any product in the ecosystem — that they were in StayPe's world.

Color system

Primary Blue-Purple (#6A71F1) The ecosystem's signature color. Used for primary actions, navigation emphasis, and brand recognition across all four products.

The blue-purple was warm enough for consumer contexts (StayPe) and professional enough for business contexts (StayRealtor). It sat in a deliberate sweet spot — not the cold corporate blue of enterprise software, not the playful consumer purple of a lifestyle app.

Supporting palette:

• Softer secondary blues for backgrounds, cards, and secondary actions

• Green for success, confirmation, and payment received

• Red for errors, overdue rent, and failed states

• Orange/yellow for warnings, pending actions, and attention states

• Neutral greys for structure, borders, and disabled states

Icons: Phosphor

Consistent, scalable, and clear at mobile sizes. Phosphor icons provided the visual vocabulary across all four products — ensuring that a "property" icon in StayPe looked identical to a "property" icon in StayRealtor.

Shared components, different expressions

Property cards — used in StayPe (tenant browsing) and StayRealtor (broker inventory). Same structural pattern, different information density. Tenants saw photos, price, location, and amenities. Brokers saw occupancy status, lead interest, and listing performance.

Status chips — a unified visual language for status across the ecosystem. Available, booked, occupied, overdue, resolved, pending. Color-coded and consistent everywhere.

Form patterns — consistent input fields, validation states, and multi-step workflows used across property creation (landlord), lead capture (broker), booking (tenant), and visit scheduling (both sides).

Dashboard cards — metric containers used in broker dashboards, landlord portfolios, and website landing pages. Same structure, different content.

What was harder than expected

The three-level app transformation was technically fragile.

The concept — the app changing shape based on the user's lifecycle stage — was brilliant in theory. In practice, it required extremely clear state management. What happens when a user is simultaneously an Explorer (looking for a new place) and a Resident (managing their current home)? What if they're in the middle of a booking when their current lease ends?

We solved this by making the current lifecycle stage the primary context — with the ability to switch between roles explicitly. But the edge cases were numerous and the transitions between levels needed to feel natural, not jarring.

Broker workflows were harder than we expected because brokers resist process.

Brokers are independent operators. They've built their workflow around speed and personal relationships. Introducing a structured lead funnel — with defined stages, required actions, and tracked progress — felt like bureaucracy to some brokers during early feedback.

We had to design the funnel as a benefit, not a constraint. The lead pipeline wasn't about process compliance. It was about never losing a lead. The AI matching wasn't about replacing the broker's judgment. It was about surfacing options they might have forgotten. Every professional feature was positioned as a growth tool, not a management tool.

Landlord rent collection had to feel gentle, not aggressive.

Automated rent reminders are useful for landlords. For tenants, they can feel like harassment if designed poorly. The reminder system needed to be firm enough to actually prompt payment but respectful enough to maintain the landlord-tenant relationship.

We designed reminders with escalating urgency — friendly the first time, clearer the second, urgent the third — and gave landlords control over timing and tone. The system automated the awkward conversation without making it confrontational.

Two websites, one brand identity, two completely different audiences.

The StayPe website needed to feel like a lifestyle brand — aspirational imagery, emotional copy, warm design moments. The StayRealtor website needed to feel like a business tool — data-driven messaging, ROI-focused copy, professional credibility.

Same logo. Same colors. Same design system. Completely different emotional registers. We achieved this through tone — the design system provided consistency, the content strategy provided differentiation.

Reflection

The StayPe ecosystem taught us something fundamental about product design at scale:

The hardest products to design aren't the ones with the most features. They're the ones with the most users.

Not users in terms of volume — users in terms of types. Three fundamentally different audiences, each with their own mental model, their own vocabulary, their own emotional relationship with renting, and their own definition of what "success" looks like.

A few things this project left us with:

Ecosystems are designed in the connections, not the products.

Any team can design three separate apps. The StayPe ecosystem's value wasn't in any individual product — it was in the data that flowed between them. A visit request that travels from tenant to broker. A rent payment that's tracked from landlord's dashboard to tenant's receipt. A maintenance complaint that moves from submission to resolution across two apps. The connections are the product.

Lifecycle-based apps are the future of consumer products.

The three-level transformation — Explorer, Booker, Resident — wasn't a gimmick. It was a recognition that user needs change dramatically over time, and the interface should change with them. Showing household management features to someone who hasn't found an apartment yet is noise. Showing property search to someone who's already living somewhere is irrelevant. Matching the interface to the moment is respect for the user's attention.

Multi-audience design requires multi-audience empathy.

We couldn't design StayRealtor without understanding what it felt like to be a broker — the hustle, the competition, the relationship management, the constant juggling. We couldn't design the landlord experience without understanding the anxiety of rent collection, the frustration of maintenance complaints, the operational burden of managing multiple properties. And we couldn't design StayPe without remembering what it actually feels like to search for a home — the excitement, the stress, the compromise, the eventual relief.

Each audience needed us to see the world through their eyes. Not simultaneously — that's impossible. Sequentially, deeply, and honestly.

The best PropTech products don't digitize real estate. They reorganize it.

The rental market doesn't need more digital versions of physical processes. It needs new workflows that are only possible because they're digital. AI property matching. Cross-broker collaboration. Automated rent tracking. Lifecycle-aware interfaces. These aren't digital replicas of offline activities. They're new capabilities that change how renting works.

What the StayPe ecosystem became

Four products. Three audiences. One rental lifecycle.

StayPe became the app that followed tenants from search to settlement — and stayed useful long after. StayRealtor became the professional platform that gave brokers a CRM and landlords an operations dashboard. The websites became separate acquisition funnels feeding the same ecosystem.

Not a rental app.

Not a property management tool.

Not a broker CRM.

An ecosystem — connected across every interaction, every transaction, and every stage of renting a home.