Recrew.ai — Designing an AI Recruitment Tool That Recruiters Actually Trust 🤝

Recruiters had seen AI hiring tools before. Most got piloted, questioned in a team meeting, and quietly dropped. The technology at Recrew was solid — 99.9% parsing accuracy, semantic matching, any resume format. The problem was making it feel like something a recruiter could defend, not something they'd abandon after two weeks.

Role & Team

Role:

Product & UX Designer

Scope:

Research, UX, UI - full product from JD creation to candidate review

Team:

Small founding team

Timeline:

22 weeks

Context block

Recrew.ai parses job descriptions, extracts requirements, ingests resumes in any format, and matches candidates automatically. Hours of manual screening, in seconds.

Over 22 weeks, I designed the end-to-end product: JD parsing, resume parsing, candidate matching, accuracy dashboards, ATS integration, and bias prompts.

Problem

BNPL for SaaS was new enough that the people I was designing for hadn't done this before. Finance heads and procurement managers at mid-sized companies were skeptical, not because the concept was bad, but because they'd been burned by financial products that buried the important information.

Hidden fees. EMI amounts that didn't match what they'd been quoted. Debit dates that appeared in their bank statement before they'd ever confirmed them. The distrust wasn't about the product. It was about every financial product they'd signed up for before this one.

On the seller side, the problem was different. SaaS vendors wanted to offer BNPL to close deals they were losing to budget cycles, but they didn't want to understand credit risk, lender relationships, or reconciliation logic. They wanted a clean integration that looked reliable and required zero operational involvement from them.

The admin portal existed because none of this could work without humans in the loop — underwriters reviewing applications, ops teams approving disbursals, fraud teams flagging risk. They needed workflows, not dashboards.

Approach

I built the seller portal first. Not because it was easiest, it wasn't, but because the buyer portal couldn't be tested with real payment plans unless vendors had created them. Sequence mattered.

For the seller onboarding, I mapped every decision a vendor needed to make before going live: what payment tenures to offer (8, 10, 12 months), what credit limits to set, how to handle partial checkouts, what the buyer-facing checkout would look like. I designed this as a step-by-step setup flow, not a settings page. The goal was to get a vendor from signup to live checkout integration in one session without needing to talk to anyone at SaaSPay.

The buyer portal was where the trust problem lived. I started by looking at what existing BNPL products got wrong, and the pattern was consistent: they made commitment easy and obligation unclear. Confirmation screens that showed monthly amount but not total. Schedules that required downloading a PDF to read. Auto-debit that was buried under three layers of settings.

I designed the buyer portal around a single principle: the full obligation has to be visible before the buyer confirms anything. Every instalment, every date, every fee, all on one screen at the moment of commitment.

Challenges and trade-offs

The hardest decision was what happens when a SaaS subscription renews mid-repayment plan.

A buyer on a 10-month plan for Figma at month 7: Figma renews their subscription. Do they get a new BNPL plan? Does the existing plan extend? Does the monthly amount change?

My first design created a new plan alongside the existing one. The buyer portal showed two active plans with two separate timelines and two monthly amounts. I user-tested it. Nobody understood what they owed. Multiple people thought they were being double-charged.

I scrapped it. The second version showed a single monthly obligation number, combining all active plans, with a breakdown available one tap away. The complexity was real, but the buyer didn't need to feel it. They needed to know one thing: what's leaving my account this month?

Solution

The seller dashboard gave vendors a real-time view of pending disbursals, active buyer plans, invoice logs, and reconciliation status — all without exposing any of the credit logic that happened between them and the NBFC. They could see what they were owed and when. That was enough.

The buyer dashboard led with the repayment calendar and the upcoming debit amount. Auto-debit could be paused, rescheduled, or cancelled from the same screen — not buried in settings. Contextual nudges appeared at the right moments: an upcoming due date reminder 5 days before, an early repayment discount when a buyer had sufficient credit, a credit limit increase prompt when repayment history was strong.

The nudge design was deliberate. The <3% default rate in the first six months wasn't just about underwriting — it was about never letting a buyer get surprised by a debit they'd forgotten was coming.

The admin portal was the least visible and the most complex. Underwriting queues where ops could review applications with credit data surfaced from the NBFC. Fraud flags with severity levels and recommended actions. Role-based access so that an underwriter saw underwriting views and a disbursal approver saw disbursal views — not each other's work. Audit logs for compliance. I designed every workflow around task completion: what does this person need to finish their job today?

Results & Impact

The first MVP shipped and went live with a pilot SaaS seller. Default rate in the first six months was under 3% — the nudge system and transparent repayment experience contributed directly to that number.

The design system I built was the first design infrastructure SaaSPay had. The next designer who joined didn't start from scratch — they extended what was already there.

I don't have conversion metrics tied specifically to design decisions, and SaaSPay's broader fintech traction is tied to factors well outside the product experience. What I can say: a product that had no designed interface when I joined had three working portals, a consistent visual language, and a default rate that held through the pilot.