Beyond the Rent Check
How a two-sided payment ecosystem targets a 60% cut in landlord admin overhead and a 95% on-time payment rate.
Situation
A Two-Sided Transaction Running on One-Sided Software
Rent payments are stressful, fragmented, and highly manual and rent is the largest recurring transaction in most people’s lives.
For renters, the process is plagued by a fear of late fees, a lack of transparency in processing timelines, and inconvenient manual transfer methods. For landlords, managing payments means juggling scattered spreadsheets, manual bank reconciliation, chasing late payments, and handling disjointed tenant communication.
Existing digital tools are often complex, untrustworthy, or built exclusively for one side of the market. The goal of RentEase was to design a unified, bidirectional B2B2C payment ecosystem where renters achieve financial transparency and peace of mind, while landlords gain consolidated property oversight and automated ledger reconciliation.
I owned the complete product lifecycle over four months: discovery, ecosystem journey mapping, systems scaffolding, high-fidelity UI design, trust engineering, and rapid front-end prototyping in Bolt.new.
The Challenge
Rent is a two-sided transaction running on one-sided software. Renters pay into a black box and fear late fees they cannot verify avoiding. Landlords reconcile by hand across spreadsheets and discover problems days after they mattered. Existing tools pick a side, serve it well, and relocate the work rather than removing it.
The Solution
A unified, bidirectional B2B2C ecosystem built on one shared record. A renter’s payment reconciles against the landlord’s ledger the instant it clears no export, no import, no nightly sync. An AI layer reads that shared record and surfaces risk on both sides before it becomes a late fee or a cash-flow gap.
Actions · Phase 1
Discovery & Research
Rent generates friction on both ends of the same transaction, and the two sets of pain are mirror images of each other. Three outputs came out of discovery.
Two-sided stakeholder interviews
I conducted structured qualitative interviews with 4 renters and 4 independent landlords, auditing their manual payment workflows to uncover the distinct psychological and operational pain points on both sides of the rental transaction.
Reciprocal user personas
I synthesized the research into two primary personas: “The Anxious Renter,” who needs reminders, transparency, and one-tap pay, and “The Overburdened Landlord,” who needs central visibility and automated ledger updates. They guided design choices by constantly balancing the opposing friction points inside the marketplace.
Ecosystem journey mapping
I mapped the emotional and operational cycles of both renters and landlords onto a single aligned timeline, looking for high-friction overlapping touchpoints. The finding: rent due dates are a shared stress spike for both parties, not just the renter.
What the two personas needed
The interviews compressed into two quotes:
“Reminders, transparency, and one-tap pay.” The Anxious Renter
“Central visibility and automated ledger updates.” The Overburdened Landlord
Mapping both cycles onto one timeline showed these were not two separate feature requests. Rent due dates are a shared stress spike for both parties the renter bracing for a late fee, the landlord bracing for a gap in cash flow, on the same date, from opposite ends of one transaction.
The strategic insight: A tool built exclusively for one side of the market doesn’t remove the reconciliation work. It relocates it to whichever party the software wasn’t designed for. The only durable fix is a shared record both parties read from and write to.
Actions · Phase 2
Define & Strategy
Research gives you findings. This phase decided what the project was actually promising: a B2B2C two-sided rent payment ecosystem where renters gain financial peace of mind and landlords gain consolidated control both drawn from a single source of truth.
Ecosystem “How Might We” constraints
I framed the core design challenges around three constraints automating manual reconciliation, designing trustworthy proactive reminders, and lowering the barrier to entry to focus ideation on mutual, balanced value rather than prioritizing one user group over the other.
How might we automate manual reconciliation so neither side has to close the gap by hand?
Constraint: no payment state may exist on one dashboard that the other side cannot see.
How might we design proactive reminders a renter actually trusts?
Constraint: one-tap pay cannot come at the cost of transparency — speed and proof must ship together.
How might we lower the barrier to entry for both sides at once?
Constraint: prediction must resolve to a single human action, never an automated one taken on the landlord's behalf.
I tied the goals to four value pillars, following James Hsu’s business value levers, so every designed component supports a measurable business outcome. These are targets the system was engineered against, not measured results:
My role and tools
Lead Product Designer, end to end. I owned discovery, ecosystem journey mapping, systems scaffolding, high-fidelity UI design, trust engineering, and rapid front-end prototyping. Figma and FigJam for interface design and collaborative ecosystem mapping, Bolt.new for the vibe-coded React prototype, and Google Workspace for user surveying and feedback consolidation.
Actions · Phase 3
Systems Design & Architecture
Bidirectional ledger scaffold
I engineered a systems-thinking backend flow where a renter’s frontend payment action instantly triggers a ledger reconciliation event on the landlord’s dashboard. Getting there meant mapping the reciprocal journeys rather than sequential ones, because in a two-sided system every action on one side is an event on the other.
- Renter journey: payment setup → transaction → history tracking → smart notification loop
- Landlord journey: tenant onboarding → revenue dashboard → predictive payment tracking → intervention
Mapping them in parallel surfaced the central requirement: the moment a renter’s payment completes, the landlord’s ledger must already reflect it. Any lag reintroduces the exact uncertainty the product exists to remove and any manual spreadsheet or bank-statement match puts the work straight back on a human.
The bidirectional ecosystem loop
The scaffold is a closed loop: Renter ↔ RentEase ↔ Landlord. Payments and notifications flow one direction; rent tracking and management flow the other. Both dashboards are views of the same record, not synchronized copies.
The second output of this phase was information architecture and contextual hierarchy. A renter’s frontend payment action dynamically reconciles and updates the landlord’s master financial ledger in real time. There is no export, no import, no nightly sync, and no spreadsheet. I organized both dashboards to isolate critical actions prioritizing immediate financial tasks over secondary communication or documentation which reduces the cognitive load of financial software and turns complex ledger data into readable visual cards.
Why this matters commercially: The 60% admin-reduction target isn’t a UI improvement. It’s an architectural consequence. Reconciliation work only vanishes when the two sides can no longer disagree about what happened.
AI-first intelligence features
Reminders alone don’t reach a 95% on-time rate. Prediction does. I designed and positioned two predictive modules one per side that surface risk before it materializes.
Predicted Rent Readiness (renter side) a score visualizer reading “Predicted Rent Readiness: 92% you’re on track to cover next month’s rent.” It converts an unshaped financial anxiety into a number the renter can act on with time to spare, alleviating rental stress before the due date arrives.
AI Predictive Alerts (landlord side) an automated system flagging at-risk accounts (“2 tenants at risk of late payment”), paired with a one-tap Send Reminder nudge button. The landlord intervenes before the due date instead of chasing after it which is what drives the on-time payment target.
The governing principle: The model predicts and recommends; the human decides and acts. The alert never sends the reminder on its own, and the readiness score never moves money. In a financial product, that boundary isn’t a limitation it’s the basis of trust.
High-fidelity interface design
Renter dashboard: I designed a comprehensive visual library in Figma using calm, trust-inducing green tones and clean sans-serif typography, so a financial interface reads as secure and reliable. Rent day collapses to one card unit, amount, days remaining, and two actions: Make a Payment or Set Up Auto-Pay. Pay now, or decide once and stop thinking about it. Beneath it, payment history lists every prior month with an explicit Completed status. Renters weren’t anxious about paying; they were anxious about being unable to prove they had.
Landlord dashboard: the console opens on the four numbers that drive decisions total properties, monthly revenue, collected this month, pending payments then drops into a payment table where every tenant carries a plain-language status: Paid, Due, Late, Partial. Complex ledger data becomes readable visual cards, and quick actions sit inline so the response is one click from the information that triggered it.
Actions · Phase 4
Prototyping & Proving Feasibility
Static wireframes cannot prove that a bidirectional ledger stays consistent. So I didn’t stop at Figma. I designed a comprehensive visual library there calm, trust-inducing green tones and clean sans-serif typography, chosen to make a financial interface feel secure and reliable then built the thing.
I vibe coded a fully interactive, responsive React prototype in Bolt.new, integrating the automated reminder logic and the payment simulation. Building it live is what exposed the state questions a static file lets you skip: what the landlord sees during a pending transaction, how a partial payment renders on both sides, when the predictive alert should fire.
Testing real-world click fidelity and state management this way accelerated stakeholder validation roughly 2× faster than static wireframes and, more importantly, moved the two-sided claim from an assertion in a deck to something demonstrable in a browser.
The takeaway: When a design’s core promise is systemic, code is the only honest fidelity. Vibe coding isn’t a shortcut past design thinking it’s a stress test for it.
Actions · Phase 5
Usability Testing & Iteration
I ran unmoderated remote usability sessions with five participants, testing both the tenant payment and landlord dashboard flows validating task completion speed, ease of navigation, and comprehension of the predictive AI elements. Two rounds changed the structure of both dashboards. Neither round changed the styling.
Iteration 1 Renter CTA streamlining
What testing showed: tenants wanted instant access to payment actions and found the auxiliary features distracting. My first renter homepage treated payment, maintenance requests, and messaging as peers, so participants opened the screen looking for the pay action and found four competing entry points of equal visual weight.
What I changed: I restructured the tenant homepage, pushing Make a Payment and Set Up Auto-Pay into a primary, hero position and demoting maintenance and messaging to secondary actions below the payment card. The dashboard now answers one question on load is rent handled this month? before it offers anything else.
Why it matters: the on-time payment target depends on paying being the path of least resistance. Every second a renter spends locating the pay action is a second they can decide to handle it later, and later is where late fees live.
The “after” state matches the shipped prototype. The “before” state is reconstructed from the pre-iteration design for comparison.
Iteration 2 Landlord alert consolidation
What testing showed: pending payments, late-payment alerts, and manual matching notifications lived in separate modules. Property managers running more than a couple of units were tab-switching to reassemble a picture the system already held in full, and described real cognitive fatigue from the fragmentation.
What I changed: I consolidated pending, late, and manual-matching alerts into a single “Action Center” banner on the landlord console, sitting alongside per-tenant status, the revenue summary, and inline quick actions putting the response one click from the information that triggered it.
Why it matters: the landlord persona was defined by a need for central visibility. Consolidation was the only fix that removed the switching rather than shortening it, and the admin-reduction target is the direct consequence of that decision.
The “after” state matches the shipped prototype. The “before” state is reconstructed from the pre-iteration design for comparison.
The pattern across both rounds: neither problem was visual. Both were hierarchy problems an interface presenting equally weighted options for decisions that were never equally weighted. Iteration here meant deciding what each screen was for, not how it looked.
Result
Outcomes
What I delivered
Measured · delivered
- A two-sided qualitative research synthesis and two personas The Anxious Renter and The Overburdened Landlord
- A dual-perspective journey map covering reciprocal payment flows and emotional cycles
- An ecosystem ledger and systems-thinking architecture scaffold documenting the shared-record model
- A high-fidelity responsive interface system in Figma covering both dashboards, payment and history flows, tenant management, and the AI alert components
Interactive predictive AI elements Predicted Rent Readiness and AI Predictive Alerts
A fully functional coded web prototype in Bolt.new, demonstrating the live reconciliation loop and automated reminder logic
A KPI validation dashboard layout for tracking the four value pillars after launch
The business case the design targets
Projected · not measured
RentEase is engineered to move rent from a monthly friction event to a background process: automated ledger reconciliation and smart notifications that cut landlord admin work, predictive readiness scores and alerts that drive on-time payment and eliminate late-fee disputes, transparent transaction timelines that build trust on both sides, and streamlined onboarding that halves setup time.
Each pillar traces to a specific mechanism. Automated ledger reconciliation and smart notifications are what cut the manual admin time. Predicted Rent Readiness scores and predictive alerts are what protect landlord cash flow and remove late-fee disputes. Standardized, transparent transaction timelines and prominent trust indicators are what earn the trust rating on both sides of the marketplace. Streamlined digital tenant onboarding and bank integration are what halve setup time. No major competitor leads with predictive intelligence in the product UI, and almost none treat the tenant as a co-equal user which is what makes these targets credible as design goals rather than optimistic guesses.
Bottom line: The category has spent a decade building rent software for landlords and mailing renters a password. I designed for both sides as first-class users, architected the shared record that makes it possible, and built the working prototype to prove the model holds.
Reflection
Next Steps & Lessons Learned
Next steps. Work closely with software engineers to integrate a secure payment gateway API — Stripe Connect or Plaid to support live bank transfers. Then formulate a quantitative testing plan to monitor payment processing latency and verify transaction success rates during pilot launches.
Future considerations. Given more time, I’d explore Split Rent features, letting multiple co-tenants or roommates connect independent bank accounts and split monthly rent dynamically, with individual status cards syncing directly to the landlord’s ledger view.
Lessons learned. Designing for B2B2C marketplaces requires balancing the psychological anxieties of two completely different user groups. True systems design means aligning seemingly conflicting needs renters’ desire for calm financial privacy and landlords’ need for absolute financial control into a single, mutually beneficial feedback loop.
Rent is one of the most stressful recurring workflows in ordinary life, and almost all of that stress is manufactured by software that only ever understood half the transaction. RentEase is an argument that when a problem has two sides, the architecture has to as well.