Mortgage Lending CRM

Product Designer · Design Expert, AI & Product Design · Lima, Peru (remote) · Full-time · June 2024 – present

A mortgage-backed lending fintech: a person puts up a property they already own as collateral and borrows against it. The company runs on advisors — sales, risk and collections — and before this project it ran on spreadsheets, WhatsApp and a loan file that moved between people by hand. I designed and shipped the CRM that replaced all of that. I own the front end, I lead a QA analyst and two developers, and I built the AI layer that sits inside the product. Sixty advisors use it every day, and the time from application to disbursement went from 30 days to 10.

At a glance

• Role: Product Designer and Design Expert for AI and product design. I design the product, own the front end, and lead a QA analyst and two developers.

• Scope: one CRM, three roles inside it — sales, risk and collections — plus the AI layer that runs across all three.

• Constraints: real money against a real property. Every step carries a legal and a credit consequence, and the people using the tool are not power users — they are advisors, and advisors churn.

• Outcome: 30 days to 10 from application to disbursement. Advisor ramp-up from months to day one. The project was acquired by another company to run with their own advisor force in Mexico.

The three roles

One file passes through three roles who disagree by design, and each of them needs a different view of the same truth.

• Sales: wants the loan approved. Owns the file while the borrower is still deciding whether to wait — the window the thirty-day lag was destroying. Opens the CRM to a queue that is already ordered rather than a table to triage.

• Risk: wants the reasons the loan should not be approved. Reads the same file with the flags worth reading surfaced first, so the work is judgement rather than a list to grind through.

• Collections: inherits whatever the other two decided, months later, when the borrower stops paying. Gets the accounts most likely to recover first, and needs the history sales and risk generated to understand what it is holding.

Most of this project was not screen work. It was deciding who sees what, at which point, and what they are allowed to do about it.

The problem

Thirty days between a person asking for a loan and the money arriving. Almost none of that was underwriting. It was the file sitting in an inbox, the document requested twice, the risk analyst waiting on a sales advisor who was in a meeting, the status nobody could see without asking somebody. In lending that lag is the product: a borrower who waits thirty days has usually gone elsewhere by day twelve.

The second problem was quieter and more expensive. An advisor took months to become useful. Mortgage lending has its own vocabulary, sequence and rules, and the previous tooling assumed you already knew them. Every new hire was months of salary before a first sale.

How I worked

• Discovery with the business, not a backlog: I run the sessions with sales, risk and collections directly, framed as jobs to be done rather than feature requests, and close each one with a written hypothesis and the metric that would tell us it worked.

• Prototypes before tickets: I build working prototypes with AI tooling during discovery, so a business area can click the idea instead of reading a spec. It is far cheaper to be wrong in a prototype than in a sprint.

• The data model before the interface: I review the schema with the backend team over the actual GraphQL queries and mutations before anything is built, so the interface and the data agree before either exists.

• Delivery is part of the design: I deliver the work built, review front-end tickets before they enter development, and stay with the feature through backend integration into production and functional and regression QA.