Lending Agent Presenter

There is a pattern of presentment tool sitting inside furniture, kitchen, solar, and dental showrooms in the UK. Sales rep keys a price, every contracted finance option renders as a row, customer ticks the key-feature acknowledgements, an audit-trail email goes out. The principle is sound and the regulatory architecture is defensible. The implementation, in market, has aged into a forest of authenticated logins, dense wizards, tablet-handover acknowledgements, and dated form ergonomics.

I wanted to design a presentment surface that respects everyone's time. Five fields and a slider for the rep. A magic link for the customer to read on their own phone, on their own time. Four categories of finance option rather than a flat grid of fifteen near-identical tiles. A payment-controls panel that does the same job whether the rep or the customer is touching it. An operator console so the configurer of all of this can see the seam between brand, catalogue, and distribution.

This is a personal side project. It is not a product of any firm I work for. The codebase is mine, the design choices are mine, the demo is mine. It exists to advance my own thinking about retail consumer-credit presentment and to give me something concrete to point people at.

Marketing landing. One sentence, one CTA, one tablet preview. Editorial rather than SaaS. Built so a portfolio visitor can grasp what the product is in five seconds.

Rep tablet. Two-pane layout: the deal goes on the left, the customer's options render on the right and update live. A sticky payment-controls panel sits at the top of the right column with two sliders: a target monthly that the rep can dial to whatever the customer says they want to pay, and an overpayment slider that the rep can use to model the term-shortening effect of paying a little extra each month. Send routes to the customer's phone via magic link, with an in-store fallback for showrooms where the customer would rather just tap on the tablet.

Customer phone. What lands on the customer's own device. The same payment controls. The same four-group catalogue. A styled quote card the customer can save by downloading the PDF or having another copy emailed. A full-screen quote viewer for anyone who wants to read the document on this device. Four CONC 4.2 acknowledgement checkboxes, time-stamped on the customer's device, followed by confirm.

Retailer admin. Dashboard with KPI tiles, sparkline of the last fourteen days, recent quotes table. Filterable list of every quote your team has sent. Per-quote detail page with the full audit timeline. The audit log tells the acknowledgement story end to end without anyone needing to dig.

Operator console. Where the configurer of the platform manages the retailers. Three tabs per retailer: Brand (name, FCA register, colour palette, footer text, with a live customer-phone preview), Catalogue (per-type sections spelling out every finance product, lender, term, APR, illustrative monthly), and Distribution (the signed rep tablet URL with rotate, plus magic-link TTL and email/SMS sender config).

Editorial typography over generic SaaS. Fraunces variable serif as the display face, Geist as the body sans, Geist Mono for tabular figures. Paper-warm background with a faint grain. Headlines and large currency figures gain editorial weight. The result reads less like a developer tool and more like a considered client portal.

Four group cards beat fifteen tiles. A retailer with a single APR across eight monthly terms, three IFC variants, two BNPL deferred-payment options, plus a cash row, ends up with fifteen products in their catalogue. The first version of this rendered as a flat grid of cards and became visual noise. The shipped version groups by product type (Cash, Interest free, Monthly payments, Buy now pay later) and collapses each group into one expandable card, with a pill-row term selector inside. The four-card stack scales cleanly to any catalogue size.

One target-payment slider, both sides. The same control sits on the rep tablet and the customer phone. Drag it, the catalogue dims to show only options that fit the target monthly. Useful for a rep working through a budget conversation in the showroom; equally useful for a customer reading the menu later that evening.

Overpayment modeller with a savings line. Second slider, "pay it off faster". As you drag it up, every expanded option shows an inline strip: cleared in 62 months instead of 96, saving £3,054 in interest. Default starts at zero so the customer pulls into the model rather than being nudged. Reads as helpful, not as pressure.

Per-retailer skin via one CSS variable. The platform ships with three skins (Solaris emerald solar, Hayes & Sons navy kitchens, Bright Lane sky dental). Each overrides --brand-primary on its data-skin attribute and the brand colour reaches the primary CTA, the picked-option ring, the chart accent, and the inline logo wherever it appears.

Magic-link customer ack on their own device. The traditional pattern is a tablet handover at the desk. Customer reads acknowledgements while the rep watches. Replacing it with a magic link that lands on the customer's own phone produces a stronger audit record (timestamped on the customer's device, IP-stamped, asynchronous) and a calmer interaction. CONC 4.2 acknowledgements are still captured verbatim, just on the device the customer actually owns.

Pure finance maths. A small finance-math.ts holds the algebra: annuity formula for monthly and total payable, target-payment reverse via binary search to solve for the deposit that produces a given monthly, overpayment impact via the standard amortisation rearrangement (solve for n given an over-paid monthly). No formatting, no React, no skin-specific logic; the same functions run inside both rep and customer surfaces and inside the operator console's catalogue preview.

Skin system as data, not config sprawl. lib/skins.ts defines name, brand colour, FCA register number, footer text, and default scenario per retailer. lib/catalogue.ts defines the per-skin finance product catalogue. Everything else is CSS variables and Tailwind utilities. Adding a fourth retailer is genuinely two file edits.

In-memory state, no backend. Zustand for demo state (current skin, in-flight quote, customer acknowledgement, walkthrough step), fixtures for the audit log. The operator console is intentionally read-mostly so the productisation seam is obvious: brand, catalogue, and distribution are the things that need a real backend and a versioned deployment story; everything else can stay in-memory indefinitely.

Engineering-spec docs as a parallel deliverable. Separate Astro Starlight site at lending-agent-presenter-docs.vercel.app, 51 pages mirroring the lending-agent docs sidebar exactly: Introduction, Product, Architecture (with the full magic-link HMAC scheme and per-surface state machines), Implementation playbooks for retailers and brokers, Safety, Privacy, Regulatory (with the four CONC 4.2 acknowledgements mapped back to sub-rules), Deploy, Reference. Written so a future build can be handed cold to a developer or an agent and start on day 1.

Working demo. Live on Vercel. Four surfaces are real and runnable end to end with a scripted walkthrough plus a free-explore mode. State is in-memory; the backend, magic-link signing, email delivery, and PDF generation are documented at engineering-spec depth in the parallel docs site rather than implemented. The intent is that a v1 production build is two weeks of focused engineering from the documentation, not a fresh design phase.

If this is interesting for your retailer, broker, or lender business, or you'd like to grab a coffee and talk about it, I'd love to hear from you.