Verifying hosts and tenants before anything goes wrong Verifying hosts and tenants before anything goes wrong

Madrid is booming and its rental market has not caught up. The filters are stuck in another decade: no permanent contract, no flat. That locks out solvent tenants and leaves hosts choosing from a smaller, samey pool.

The paperwork wall

Solvent, and still locked out

Freelancers and expats hit closed doors, blocked for lacking a standard payslip however solvent they are. Hosts are stuck too: rigid paperwork is the only risk tool on offer, so they use it. Urbiqo does not throw that paperwork away; it adds more ways in. A tenant can name a guarantor, family help counts as a real answer to how the rent gets covered, and an optional background step lets them tell hosts who they are: why they are moving, how they live, how they rented before. Hosts decide on more evidence, and solvent non-traditional tenants get through the door.

The problem was never the listing. It was the leap of faith on both sides of it.

Groundwork

Mapping the full journey

Before any screens, I mapped the complete flow for both sides: every decision point from first login through verification, application and payment. It became the source of truth for what to design first. It also fixed three rules the product had to honour: browsing stays open without an account, verification becomes mandatory at the point of applying or listing, and a verified profile is reusable across applications.

Two sides, one problem

The product has to hold two realities at once.

The difference Urbiqo bets on: validating reliability, not just salary.

01 · Verification

Fairer screening

I added alternative proofs beside the classic payslip: bank statements and invoices. Employer letters and tax returns were considered and dropped, both lag actual cash flow. Bank statements and invoices reflect it in real time, and validate through OCR with manual review for the edge cases.

A service blueprint maps the backend logic that adapts verification requirements to the user’s status, accepting invoices for freelancers, for example.

02 · Trust

Humanising the transaction

A verified profile travels ahead of the tenant. The host sees the same verification card before any meeting: email, phone, ID and background check. Hosts declare their relationship to the listing too, owner, tenant or intermediary, so applicants know who they are dealing with. Trust is visible on both sides before anyone books a viewing.

03 · Clarifying

Demystifying the process

Renting is overwhelming enough. The landing page works as a calming filter: the verification journey compressed into four linear steps, understood before anyone creates an account.

Positioning

Where Urbiqo sits

I mapped the Madrid market on two axes: complexity of service and target specialisation. The gap: nobody combines trust-based verification with accessible pricing for freelancers, expats and non-traditional tenants.

The craft layer

Behind the screens

The system underneath: tokens, components and variable theming for dark mode and English/Spanish localisation. Built alongside the product, kept as its own reference.

Third act

Designing it was the easy part

The design was defined, the system documented, the flows mapped. Then I built it, on Next.js. Building your own design is the most honest usability test it will ever get. Every screen I signed off as a designer had to earn its way through real components, real data and real states.

Some decisions did not survive contact with code. A flow that looked clean in Figma met loading states, empty states and awkward real content. I was the designer who had to admit it and the developer who had to fix it, so the iteration loop ran in minutes, not sprints. The product on staging is the result.

One detail only appeared once there was a front end to run it: every section heading draws itself in from the left, behind the terracotta skyline. A motion decision made in code, not in the static design file.

Live on staging today: featured listings; search with type, price and size filters beside a map; listing pages with gallery, amenities and neighbourhood notes; apply and contact host; freemium and premium tiers for hosts, tenants always free; full English and Spanish; a help centre, FAQs and a contact form that routes by topic. The listings are sample data for now, placeholders to exercise the flows end to end until real inventory arrives at launch.

Three decisions from the build earned their own labels.

Build 01 · The restless card

The card that could not sit still

Real descriptions vary in length, so the ‘More details’ button pinned after the text could never sit still. The title now clamps to one line, the description to three and the whole card became the click target.

Build 02 · Honest pills

A pill should never lie about why it is red

The verification thinking survived into code as the trust and safety card on every listing. Each signal has its own state: a profile can show email verified while phone and identity are still pending. Honest states, not one binary badge.

In the design file the four states were a legend: Active, Pending, Attention and Issue, one pill per signal. In code every pill needed a source of truth and a failure story. A signed-out user stopped being treated as an error, and one blanket ‘something went wrong’ was split into its distinct causes, so a red pill always means one specific thing.

Build 03 · Half the words

Only half the words are mine

Localisation was designed as a variable mode and shipped as one. The same screens run in English and Spanish end to end.

The design file flips every string with one variable mode. The build corrected me: interface copy translates, but listing content lives in the database, so a Spanish page can still speak English wherever the data does. And Spanish runs long enough to truncate cards the English never stressed.

What I learned

Designed end to end, then built end to end, by one person, on Next.js. That is the outcome: a two-sided platform running on staging in two languages, from search to application. No user metrics yet, the launch is still ahead, so what follows is what shipping it taught, not what the market said.

Three things Urbiqo taught me:

• Two-sided trust is its own discipline. Everything that removes friction for tenants, fewer documents, faster checks, adds perceived risk for hosts. Balancing that tension shaped the whole product structure.
• The gap between a founder’s concept and a buildable product is bigger than it looks. The vision was clear. The design work was turning it into conditional verification logic, system states and edge cases.
• The visual layer carries more trust than I gave it credit for. People hand over personal documents here; every colour, interaction and line of copy either builds confidence or erodes it. I would budget more time for that layer next time.

Honestly, though

Status and next steps

Staging went live on 6 July 2026 and the platform runs at staging.urbiqo.com, in English and Spanish. It is in active QA now, the day-to-day is correcting what real screens, states and content expose before launch. The bet: put verifiable trust signals beside the rigid contract requirements and the market opens on both sides. Unproven until launch, but the logic holds. If you can verify reliability without demanding a permanent contract, hosts get confidence and tenants get access.