AI Underwriting Test Plan for Private Lenders: Manual Inputs Before Integrations

Underwriting that depends on one person's judgment is hard to speed up and even harder to hand off. At this private lender, deals were judged by hand, borrower folders were organized by borrower name with no market labels, and comp data went stale quickly.

The client is an executive at a private real estate lender that writes fix-and-flip, bridge and rental loans. We had already built a Claude underwriting sequence. The open question was how to test it without pointing it at a messy tangle of systems on day one. If you lead lending for investors, our page for mortgage loan officers and private lenders covers the wider work.

The situation

The call was a build review. We walked through the Claude underwriting sequence, and the lender's team confirmed two things: the outputs they wanted to see, and the scoring logic that should sit behind them. That is the part of an AI build people tend to skip, and it matters. A model cannot be tested against a standard nobody has written down.

With the target agreed, the next decision was the order of testing. We chose to start with manual spreadsheet inputs for the rehab scope on each deal and to hold off on every automated integration until the scoring held up.

What was broken

Five things stood between the lender and a trustworthy test:

• Underwriting relied on manual judgment, so there was no written scoring standard to test against.
• Borrower folders in the shared cloud drive were organized by borrower name with no market labels, so nobody could easily pull examples for a given market.
• Comp data went stale quickly. The executive said static comps were not good enough and asked for dynamic market reads.
• Property age and builder history, which the lender's team said materially affect underwriting decisions, were not being captured anywhere.
• The CRM was disorganized, with many systems that did not talk to each other.

What we built

We set the test up so that each problem above had one specific counter-move.

• Manual first. The test deals go through the underwriting sequence with rehab scope numbers entered by hand from a spreadsheet. Any bad result traces back to scoring logic, not to a broken connection.
• Real deals with known answers. The executive agreed to share 10 rehab scopes with completed appraisals so we could run test deals over the weekend.
• Market-indexed data. A team member was asked to send the loan tape indexed by market and borrower data, so examples can be pulled across several markets instead of hunted for by borrower name.
• Two new inputs. We took on research into property age and builder history for each market so those factors can be part of the scoring.
• Fresh comps. We took on setting up weekly auto-updating market knowledge bases for comp data, so the comps are refreshed on a schedule instead of sitting still.
• A read-only look at the CRM. We took on a read-only audit of its structure with a list of improvement suggestions, and asked for admin access so a connection test can come later, once the scoring is trusted.

What changed

No test result was reported on this call, so we are not quoting accuracy. What changed was the setup. Before, the lender had judgment-based underwriting and files that could not be searched by market. After the call, it had agreed outputs, confirmed scoring logic, a defined set of test deals with appraisals attached, a request out for market-indexed loan data and a weekly comp refresh on the build list.

Just as important, the integrations were put in the right order. The CRM connection is a later step, and the first round of results will show whether the scoring is right before any plumbing is added.

What to take from this

If you want to test AI underwriting on your own loans, copy the sequence. Pick deals that already have a completed appraisal, so you know the answer before the model gives its own. Keep the first round manual so errors have one possible source. Label your files by market before you try to compare anything across markets. And treat your CRM as read-only until the scoring has earned trust.

Frequently asked questions

Why test an AI underwriting sequence with manual inputs first?

Manual inputs remove the integration layer from the test. If a deal scores badly, you know the cause is the scoring logic or the data you entered, not a failed sync. In this build the connections to other systems were deliberately left for after the first test deals.

What kind of deals make a good first test set?

Deals that already closed or were appraised. This lender agreed to share 10 rehab scopes with completed appraisals, which gives the test a real figure to compare the output against. Pick deals across your markets so the scoring is not tuned to only one.

Why do comps need to update weekly for underwriting?

Because comp data goes stale quickly. The executive on this project said static comps were not enough and asked for dynamic market reads, so we planned knowledge bases per market that refresh automatically each week rather than relying on a one-time pull.

Should an AI tool get write access to my CRM from the start?

No. We planned a read-only audit of the lender's CRM with improvement suggestions, and requested admin access only for a later connection test. Read-only first lets you see the structure and fix the mess before anything automated touches live records.

If your underwriting still lives in one person's head or in folders nobody can search, book a 30-minute AI follow-up and reporting audit. We look at where your deal data sits and what a first test would need.