The Bullshit Test

Two numbers tell you more about a mortgage company than any demo.

One of our newer originators had his first $30,000 commission month in June.

Eight months into the business, he had the biggest payday of his life.

He earned it.

And then the recruiters started calling.

They found him the way they find everybody now.

The data is public.

Every loan gets recorded, so all somebody has to do is link it back to his NMLS number, and within a week of his first big month, there was a list of people who knew exactly what he did and wanted to tell him he was a star with a signing bonus, promises of better technology, and a company that would finally appreciate him.

Some of you are probably hearing all of this right now.

Princeton is the only company he has ever worked for.

It is the only workflow he has ever run.

So when the offers came in, he had no way to know whether what he had was good or just normal.

So he went looking for a baseline.

He compared the easy things first: the pricing, economics, and product lists.

One company had good pricing and good economics.

So he tracked down a top producer who had left that company and asked her what it was like to work inside it. She told him the economics were as good as advertised, that you could win any deal you wanted, but that the technology and the daily workflow were so far behind that she left anyway.

So he looked at another company with better technology, but the pricing he did not think he could sell.

In the end, he came to the conclusion everyone does:

Pricing and compensation have to work first.

Nobody stays somewhere they cannot make money.

After that, the only thing to look at is how the company runs, but that is the part that is hardest to see from the outside.

This newsletter is about what I would do if I were interviewing companies today:

What I would make them show me, the two numbers I would make them produce, and what those answers say about where the company is headed.

The new-hire call

For years, hiring an experienced operations person made me nervous. An underwriter or a closer who had done the job somewhere else knew what the work felt like at other companies, which made every one of them an outside audit. And I was not sure we would pass.

So what I would do is run an intro call with each of them in the first couple of weeks and ask straight out what their old company did better than we did. I wanted the honest answer, and I braced for it, because back then it usually came with a list of things like hard stops all over our system, forms nobody could explain, and workflows that took more explaining than they should have.

Most mortgage companies operated the same way then, and we were no exception. We were in the middle of the pack, and the new people could tell.

I do not do that anymore.

Because now they come to me.

The last underwriter and closer we brought on were only a couple of weeks in when they told me, unprompted, that it was easier to get their work done here than at their former companies. And not because we hire nicer people or push them harder. But because the system they are working inside is actually different now.

How we turned things around

Most bad systems are not designed badly on purpose. They accumulate, one frustrating workaround at a time, over years. But how that happens is less important than what is currently happening because whatever your operation is producing right now, it is producing repeatedly, and that repetition is the system doing exactly what it is built to do.

If it’s a great system, then what it does is great.

But if it’s a bad system that’s a big problem.

But it’s not a people problem:

And to make matters worse, recurring, company-wide problems rarely get fixed by retraining one person. Deming estimated that roughly 94% of what goes wrong in an operation belongs to the system, not the people in it.

I can confirm this because for a long time, training was our answer to everything.

If the loan was a mess, we would train the processor.

If disclosures were going out wrong, we would train the team.

If somebody could not get our system to work, we trained them more.

Naturally, the same problems kept coming back. Until I realized that when competent people keep struggling with the same routine step, the problem probably isn’t them. It’s the system.

So I made a rule.

From now on, any new workflow must be usable day-to-day without a training class or manual.

Testing this was simple. We simply handed it to a few people with no instructions to see if they could complete a loan. When they couldn’t, we fixed the problem until either they could or we developed a new system and tried again.

It used to take an experienced operations person a month to get up to speed.

Now it takes a week.

UNLEASHED WISDOM: Your system is designed to deliver the results you are getting. Not the results you want. The ones you are getting.

So when you are interviewing, one of the things you want to find out as soon as you can is what companies do when a loan goes sideways. How do they react to that one loan going under? Do they make people go through another training class? Do they add more checkpoints and a hard stop? Do they make it stop at another desk?

But don’t just look for one example:

One loan is an event. The distribution is the system. Sometimes a file really is an exception, a weak hire, or a vendor that went down, and that gets handled as what it is. But when the same result keeps appearing, the move is to stop treating each one as unrelated and look at what keeps producing it. And the only way to do that is to run what I simply call The Bullshit Test.

The Bullshit Test

You can run it on any company recruiting you with a great pitch. But for practice, you can also run it on your company or, with a few modifications, on yourself.

The test encompasses two parts.

Part 1 tests the workflow.

Part 2 tests the data you extract while testing the workflow.

PART 1: THE WORKFLOW

Before you believe anything any mortgage company tells you, whether yours or the one recruiting you, you need to be able to drive the workflow yourself.

The B.S. Test cannot work with a guided demo run by a salesperson. You need to run a real workflow you operate, using a sandbox, or a scrubbed file, or a training loan, and watch where the loan stops and who has to touch it to move it. Watch for every place the loan stops and waits for a person to notice it, review it, or release it.

Here’s what you are for:

People should be handling judgment, exceptions, and real risk decisions, not moving every routine file from one step to the next. When the originator clicks, does the loan move on its own, where does it stop, and who has to touch it?

What to look for at the Front of the loan

• Disclosures. When the originator hits send, do the disclosures go to the borrower straight from the system, or does a disclosure desk have to open the file, review it, and release them? On the normal path, nobody but the originator should have to send them. A disclosure desk is a routine human handoff the system has not removed.

• Intent to proceed. The borrower signs. Does the loan advance on its own, or does someone have to download the document and enter a date to unlock the next step?

• Appraisal and title. Once intent to proceed posts, the appraisal order, the borrower’s payment request, and the title order should all trigger on their own. No appraisal desk, no processor opening the file, nobody having to remember the sequence. A person steps in only when something falls outside the normal path.

• Lock. When the originator requests the lock, it should confirm and the locked loan estimate should reach the borrower within fifteen minutes, with nobody on a lock desk reviewing, confirming, or releasing it. A person touches the file only when the lock falls outside the normal path.

What to look for in the Middle

• Conditional approval. When underwriting issues the approval, does the borrower get it the same day, straight from the system, with the conditions written in plain language they can act on? Or does a processor copy the conditions into an email, rewrite them, and send them by hand every time?

• Early Closing Disclosure. Once the trigger is met, the early CD should generate and go to the borrower on its own. No closer and no disclosure-desk employee should open the file, prepare it, review it, or release it. People touch only the exceptions. Then ask how many days before closing it goes out and how close it lands to the final CD.

• CD balancing. How much of the balancing is done before a closer ever opens the file? Does the system compare the expected fees against what the settlement agent sends, flag the variances, and leave people to work only the exceptions?

• Change of circumstance. When a fee moves out of tolerance, does the change trigger itself and the re-disclosure go out, or does someone have to notice it and rebuild it by hand?

• Document indexing and extraction. When the borrower sends a document, does the system file it, rename it to a standard format, recognize what it is, and extract the relevant data, or does a person sort, label, and key it in by hand?

What to look for Post-closing

• Do stacking orders build themselves for each investor?

• Do post-closing conditions pull in from the investor and match to the right documents automatically?

• Does the UCD transmit to Fannie and Freddie on its own, and does MERS register automatically at closing?

What to look for underneath all of it

• Can anyone see where every loan actually is, right now, without asking someone to build a report?

Most of that list is not an AI problem. It is a workflow-design problem, and the design is the hard part, not the tools.

Encompass is the system of record. It holds all the fields, documents, milestones, conditions, and dates. A clean build of it matters. But a clean build is not an operating model. It stores the loan. It does not decide what should happen to the loan next.

At Princeton, we built an orchestration and execution layer on top of Encompass that watches the state of every file and works out what should happen next, as well as whether the previous step happened, whether the loan can advance, which results are routine and which are exceptions, and who needs to see the exceptions. Once that’s done, it takes over and sends the document, places the order, posts the date, routes the task, confirms that the expected thing happened, and flags it when it did not.

The newer capability worth naming is document reading. A pay stub, a bank statement, an investor condition buried in a PDF. Traditional automation works best with structured inputs, known rules, and predictable triggers; it struggles with varied, messy documents. AI is materially better at interpreting them and turning what they say into data the orchestration layer can use. It does not replace that layer. It widens what the layer can understand. Most of the rest has been possible for years.

This is the sequence the system is built to run. A contract comes in on a Saturday. The originator updates the file, and disclosures are out in about ten minutes. The borrower signs. Intent to proceed posts on its own, and within about five minutes the appraisal is ordered, the title is ordered, and the payment link is in the borrower’s inbox. Monday morning the loan is in the underwriting queue with the appraisal paid and ordered, the title ordered, and disclosures done.

Now, the same contract where the routine steps wait for people. Disclosures do not go out until Monday because nobody is at the desk on the weekend. The borrower signs Monday night. Somebody looks at it on Tuesday and sends it to the appraisal desk, which orders it that afternoon. The borrower pays the next day. Title waits for a processor to open the file. That loan reaches underwriting on Thursday. Same contract. Monday morning in one shop, Thursday in the other, and the whole gap sits at the front of the loan before anyone has looked at anything hard.

PART 2: THE DATA

This is the part where you take all the data extracted from testing the workflow and hold it up to the light with two numbers you ask for (with clear definitions).

The first number you ask for is clear-to-close timing. Specifically, you are looking for how many of their funded loans from the most recent full month landed in each bucket:

• 0 days before closing

• 1 to 3 days

• 4 to 6 days

• 7 to 10 days

• 11 or more days

Then, to make sure you understand everything accurately, ask for clear definitions of what they mean by phrases like: calendar or business days; the actual closing date or the originally scheduled one; the total funded-loan count; and how they treat a closing that the borrower moved.

Clear to close means the credit and underwriting conditions are cleared, and the file is ready for the closing itself. Clear to close ten days out, and everyone has room if something moves. Clear to close the morning of, and there was no room left at all.

Here is ours. The chart shows every loan we funded in June, by calendar days from clear to close to the closing date.

June 2026 funded loans.

65.7% were clear to close four or more days out, the bar we hold ourselves to. The median was five days. 19.2% were eleven or more days out.

Remember, you cannot base this on just one loan. One loan is an event. The distribution is the system. So you are looking for a pattern. Calendar days against the actual closing date, funded loans only, and a straight answer on how a borrower-moved closing was counted. A company that can give you the buckets with those definitions is measuring the outcome.

The second number you need to ask for is the cost. Specifically, you are looking for what the loan costs the company, fully loaded, to fund.

What does it cost the company to fulfill your loan? Not to originate it, to fulfill it: open it, disclose it, underwrite it, close it, and handle post-closing. Ours, fully loaded with technology, benefits, overtime, payroll taxes, and management, is about $534 a funded loan, and underwriting is the largest component of it. I am not going to hand you an industry number to put next to it, because the honest comparisons are hard and the dishonest ones are easy, and I would rather not sell you a number I cannot stand behind.

Our actual April 2026 fulfillment figures.

Ask your company about theirs, and ask what is in it. Which functions are included? Are management, technology, benefits, payroll taxes, and overtime loaded in, or stripped out to make it look lean? Is sales compensation excluded? Corporate overhead? Is it per funded loan or per application? A company that cannot answer cannot tell you whether its next improvement actually lowered the cost or just moved the work somewhere else.

How It All Comes Together

Workflows drive productivity, and productivity drives cost, and cost sets how much room a lender has in rates and compensation.

Routine handoffs take labor. Labor, with the management and technology around it, is a fulfillment cost, and it has to be recovered somewhere: in the rate, in your compensation, in the company’s margin, or in some split. Lower costs create more room. But where that room goes is a decision, not a promise. So cost is not the only thing moving your rate; execution, hedging, product, and loan-level adjustments all sit in there too. Operating cost is the piece that a company sets by design.

This was the problem that my rookie kept running into.

One company had good pricing and economics, but could not make the daily work good.

Another had better technology, but with rates that he did not think he could sell because higher operating costs make it harder to be good on pricing, compensation, and fulfillment at the same time.

Since I told you and him to ask companies for this number, I figured it was only fair that I show you mine (the near-in loans and all).

Grading Princeton by an easier standard than the one I am handing you would be its own kind of bullshit. And the second you stop looking at your own data, you start believing your own pitch.

My underwriters and closers own how hard they work. I own whether the system lets that work matter. That’s why, when something goes wrong here, the first thing I look at is the design, not the name on the file.

All I am telling you to do is watch whether the company across the table does the same.

Where my Rookie ended up

My rookie is still here.

But it had very little to do with me.

When he eventually got around to calling me, he had already, in a way, figured all this out.

So he was just calling me to be honest with me and explain why he was staying.

He did not know about handoffs or Deming. He just went and found someone who had lived inside one of those companies and asked.

He was as green as they come. But his skepticism was not.

He did not have the Bullshit Test yet, but he had the most important thing underneath it.

The instinct is not to take a company’s word for it and that a pitch is built to be seen and a system is built to be lived in. Because while one of them is recruiting you, the other one is going to be your Tuesday, every Tuesday, for as long as you stay there.

So you might as well take it for a test drive before you drive it off the lot.

Rich Weidel
CEO, Princeton Mortgage