Matching renters and landlords on what they actually qualify for

The principle: requirements are the product

Every screen in Rentmor touches the same few qualification facts: minimum credit score, minimum income, evictions, bankruptcy, co-signers and Section 8. I treated them as the backbone of the product instead of fields in a form. A landlord enters them once when setting up a property, a tenant filters by them while searching, and both see them again when an application is reviewed. The same facts, in the same words, at every step.

Decision 1: Separate the property from the listing

A property is the permanent record of a home: its basics, its requirements, its amenities and its photos. A listing is the published offer to the market. I modeled them separately so a landlord enters the details once and can publish, edit or relist without starting again.

The Properties page shows each home as a card with its state and the next action in one place: Unverified, Verifying, Verified and Not Listed with a List Property button, or Listed with a View Listing button. Inside a property, the information is grouped into Basics, Requirements and Amenities, and each group can be edited in place with its own edit control. Creating a listing is a guided flow: choose a property, step through the sections, and review a full preview before it goes live.

What I chose not to do: one long form that mixes property facts with the advertisement, which would have forced landlords to re-enter the same details for every listing.

Decision 2: Make verification a visible state

Trust on the supply side matters as much as trust on the demand side. A property carries a verification status that is visible everywhere it appears: on the card, and as a badge on its Basics section (for example Verified or Rejected). The actions follow the state. A verified property offers List Property, while one that is still unverified or being verified does not, so a landlord cannot publish something the platform has not confirmed.

What I chose not to do: let anything be listed first and fix it later, which would have put unverified homes in front of tenants.

Decision 3: Show requirements before the application, not after

The fastest way to waste a renter's money is to let them apply to the wrong home. On the tenant side, listings can be filtered by home type, rent, beds and baths, minimum credit, income requirement, and evictions and criminal history, in both a grid and a map view. On a listing, the requirements appear as clear chips (for example, no minimum credit score required) right above the Apply button, so a tenant knows where they stand before they start.

Landlords get the mirror image. Their property list can be filtered by minimum credit, income verification, evictions, bankruptcy, beds, baths and rent, so they can see their own portfolio through the same lens tenants use.

Decision 4: Make applying one short, clear path

A tenant who decides to apply chooses between two kinds of application: a one-time application, or one that saves their information for future use (offered as QuickApply). A tenant who expects to apply to several homes should never have to retype their details, and the listing page also invites them to sign up for QuickApply. The application then moves through three steps: choose the type, complete the application, and enter payment. Each step opens over the listing, so the home the tenant is applying to stays in view.

What I chose not to do: require a long form or an account before the tenant understands their options.

Decision 5: Treat application review as a decision, not an inbox

A landlord reviewing applicants is deciding, so the Applications table puts the decision data in the row: applicant, property, credit score, move-in amount, date and status. It can be searched, sorted and filtered by property. Opening an application shows the applicant's details with Approve and Reject at the top, and the page is built to hold the TransUnion screening result, so the landlord can check the report and decide in one place.

Decision 6: Give tenants control over their account and alerts

The tenant's account holds sensitive information, so it is treated carefully. Profile details can be edited in a short dialog. Changing login details asks for the old password, and then for a six-digit code sent by text before anything is saved. Notifications are limited to three events that matter: a new property listed in the tenant's area, a new property that matches their preferences, and a change to an application's status. Preferences and account deactivation sit in the same page.

What I chose not to do: a long list of notification switches that nobody reads.

Decision 7: Give staff the same patterns in a clearly different context

The super admin view reuses the tables, filters and cards that landlords and tenants already know, with the extra reach staff need: sections for landlords and a Tenants and Leases overview searchable by address and filterable by beds, baths and rent. A darker green sidebar separates the admin from the light sidebar used by landlords and tenants, so staff always know which context they are working in.

Result

I will be precise: I am not claiming usage figures or business outcomes.

What the work produced:

• A connected set of flows across three roles: landlords from property to listing to application review, tenants from search to application to account, and staff from a single oversight view.

• A property and listing model that removes repeated data entry.

• One set of qualification facts, shown in the same way in setup, search, application and review.

• Verification and requirements surfaced as visible states, so both sides trust what they see.

How I would measure it:

• The share of applications that come from tenants who meet the listing's requirements.

• Application completion rate, and the share of applicants who choose the saved application.

• Time from adding a property to publishing a verified listing.

• Time a landlord takes to approve or reject an application.

• How many support requests are about requirements or verification status.

What I would do differently

Two areas need more depth. First, a Rejected status tells a landlord that something failed but not why or how to fix it. I would show the reason and the next step on the property itself. Second, the application detail page reserves room for the TransUnion report, but a landlord's decision depends on that content, so it deserves a fully designed view with a clear summary of how the applicant meets each requirement. I would also give tenants a status timeline for each application, so they are never left wondering.

Reflection

In a two-sided marketplace, the work is making both sides see the same facts. Once requirements were structured and shown consistently, search, application and review stopped being separate screens and became one story about whether a tenant and a home fit. That is the habit I would bring to any marketplace: find the shared facts both sides care about, and design everything around them.