Property finance

Greenfield Bridging

Lending CRM & investor portal

A bespoke CRM running the entire life of a short-term secured property loan: a broker's enquiry, underwriting and the case build, document packs, investor funding, going live, daily interest accrual, and redemption. Three audiences use it: the lender's own team, the brokers who introduce business, and the investors who fund it through the Funding Desk portal.

Our role: Product engineering · Financial systems · Document automation · Test & release engineering
Platforms: Web · Broker portal · Investor portal
Stack: Next.jsReactNode.jsExpressMongoDBAnt DesignRedux ToolkitAWS S3Socket.IOPlaywrightJest

The problem

Problem.

Money software has a different failure mode from most software: a subtly wrong number doesn't crash anything, it just quietly becomes what the borrower owes. Bridging finance compounds that, interest can be rolled or retained, regulated or unregulated, posted daily, weekly or monthly, against periods anchored to the day of the month the loan first charged, with partial payments landing mid-period and a default rate that takes over the moment a term ends. Every one of those interacts with the others, and the same loan has to reconcile from the borrower's side and the investor's side at once.

What we built

Solutions.

Not a feature list, the pieces that had to exist for the product to do what it claims.

Enquiry to redemption, as one pipeline

Configurable case statuses with full history, from first broker enquiry through solicitors, live, over-term and redeemed, including the outcomes nobody enjoys recording, like turned-down cases on both sides.

A case ledger with nominal codes

Single running-balance ledger per case with debits, credits and nominal codes, plus a bulk importer for bringing an existing loan book across.

The periodic interest run

An operator posts interest across every live and over-term case at once, with a preview report before committing, because the moment to catch a bad run is before it hits the ledger.

Investor allocation, including splits

Deals offered to investors with accept, reject and money-received tracking, and multi-investor allocation splitting one case across several funders with per-investor state and readiness validation.

A gate before a deal can be offered

Allocation is blocked until the write-up, title plan and other required documents are uploaded and explicitly cleared for the investor panel. The system refuses to let a deal go out half-dressed.

Documents generated, not typed

ESIS and facility letters produced from Word templates, redemption statements from a spreadsheet template, and a multi-page application PDF rendered from templates through headless Chrome.

Broker portal with record locking

Brokers submit enquiries, complete application forms, and see their own pipeline and commission statements, with locking on application records so two people can't edit the same form into an inconsistent state.

Typed document management

Seventeen named document slots (client ID, proof of address, credit and AML searches, valuation, legal charge, report on title, completion statement, exit confirmation) with per-case checklists, S3 storage behind presigned URLs, and a recycle bin rather than a hard delete.

Permissions and an audit log that reads like English

Around three dozen permission codes across five groups, and a change history that records creates, updates, deletes, logins and postings as readable per-field lines across some thirty entity types.

They treated our interest maths with the seriousness money software actually demands. The ledger reconciles from the borrower's side and the investor's side and tells the same story both ways, which is exactly what a bridging book needs and rarely gets.

Operations Director, Greenfield Bridging

Under the hood

The parts that were genuinely hard.

The interest engine

Interest compounds daily rather than monthly, the day's interest is added to the balance so tomorrow computes on it. Accrual windows are anchored to the day of month the loan first charged, with explicit handling for the months where that day doesn't survive the wrap. Partial payments reduce the balance on the exact day and force the daily rate to be recomputed for the remainder. Past term end, the default rate takes over. Retained interest posts as a matched debit and credit pair, deliberately timestamped minutes apart so ledger ordering stays deterministic.

Two directions that have to agree

The investor's return is built on capital lent (the net loan plus every fee flagged as added to it, across thirteen fee types), then split into a fixed component and a share of the variable. It's recomputed on demand with investor-specific parameters rather than stored, which means the same underlying maths has to reconcile from the borrower's side and the funder's side and produce a consistent story.

Idempotency, because runs get repeated

Before posting, the run checks for an existing interest entry on the same date, and re-derives balance continuity from the latest non-interest ledger entry. Someone will eventually click post twice; the ledger shouldn't care.

A forecast written to mirror production

Investor forecasting is a separate implementation deliberately built to track the production accrual logic, so projections and reality don't drift apart into two different opinions about the same loan.

Tests as a release gate

Jest against an in-memory database on the backend, and Playwright end-to-end runs against a dedicated server with seeded fixtures gating production deploys. For software that decides what people owe, this is the minimum, not a flourish.

Previous projectInterviewaAI interviewing platform Next projectAi13Voice AI product site & live demo

Got something like Greenfield Bridging in mind?

Tell us where your business is stuck. We'll show you what an AI-native team can ship, and how fast.

Start a project contact@whyphyinfotech.com