Gateway Private Money: software for a paper-heavy lending business

The problem: money that moves faster than a bank does

A real estate borrower with a time-boxed opportunity — an auction property, a rehab that has to start before the season turns, a commercial building where the seller wants a short close — does not have thirty to sixty days to wait on a bank underwriting committee. Traditional mortgage lending is built around a long, standardized, heavily documented process that produces cheap money slowly. That trade is correct for a thirty-year owner-occupied loan. It is useless when the deal expires in three weeks.

Private money lending exists to fill that gap. A private lender underwrites primarily against the asset rather than the borrower's full financial biography, charges more for the speed and the risk, and closes in days or weeks instead of months. Gateway Private Money does exactly this: short-term real estate finance for residential and commercial borrowers in California, positioned as fast, alternative funding for people who need a decision rather than a queue position.

The business problem underneath that pitch is operational, not financial. Speed is the product. Anything that adds a day to the process — a borrower who doesn't know what documents to send, a term sheet that has to be assembled by hand, a file that sits in an inbox because nobody owns the next step — eats directly into the only thing that differentiates the lender. And private lending is, historically, one of the most paper-heavy corners of an already paper-heavy industry.

What was actually built

The work here was a mix of software and strategy rather than a single product ship. On the software side, the shape is what I would describe generically as deal pipeline and borrower intake tooling, sitting behind a borrower-facing site.

The borrower-facing site does the qualifying work that would otherwise happen on the phone. It states what the lender does, what property types and loan sizes are in scope, roughly what terms look like, and what a borrower needs to have ready. That is not decoration. A site that answers the obvious questions filters out the applications that were never going to fund, and the applications that do arrive arrive better prepared.

Behind it sits intake: a structured borrower application that collects the property, the loan purpose, the requested amount and term, the position of the loan, the borrower's entity structure, and the supporting documents. The point of structuring intake is not the form — it is that everything downstream has real fields to work with instead of an email thread.

From intake, a deal moves through a pipeline. In private lending the stages are recognizable: new inquiry, qualified, under review, term sheet issued, in diligence, docs out, funded, serviced, paid off — with a dead branch at every stage. Making that pipeline explicit in software rather than implicit in someone's head is most of the value. It answers, at any moment, how many live deals exist, what each one is waiting on, and who owes the next action.

The third piece is document handling. Every deal accumulates a file: purchase contract, title work, appraisal or valuation, insurance binder, entity documents, payoff statements, signed disclosures, the note and deed of trust. Collecting these against a per-deal checklist — rather than as attachments scattered across an inbox — is what makes a fast close survivable.

Why the "paper-heavy industry" framing matters

It is tempting to treat lending software as a CRM with different labels. It is not, for three reasons.

The document is the deal. In most software, records are the truth and documents are attachments. In lending, the executed documents are the loan; the database record is a convenience view of them. That inverts the usual design instinct. Versioning, ordering, retention, and knowing exactly which document was signed matter more than a clean schema.

Underwriting is a workflow with judgment inside it. You cannot fully automate the decision, and pretending otherwise produces software people route around. The right target is to automate everything surrounding the judgment — assembling the file, computing the obvious ratios, surfacing what is missing, tracking what has been requested — and then present a human with a complete package and let them decide.

Compliance constrains the shape. Lending is regulated, disclosures are mandatory, and records have retention obligations. Compliance work is not a feature you bolt on at the end; it determines what the system must record and how long it must keep it. Building the audit trail from the start is cheaper than reconstructing it later — the same argument I make in more depth for other regulated domains.

How the tooling is put together

The engineering here is deliberately unremarkable, and that is a choice. A small lending operation is not served by a bespoke platform it cannot maintain. It is served by a thin layer of custom software over tools that already exist, so the custom surface is small enough for one person to own.

That means: a fast static borrower-facing site, a structured intake path that writes into a pipeline rather than an inbox, a per-deal document checklist with clear ownership of each item, and notifications that fire on state changes and stalls rather than on a schedule nobody reads. Where a CRM or off-the-shelf loan-origination tool already does something adequately, the right move is to integrate rather than rebuild — the custom work is in the connective tissue and in the specific stages this business actually uses.

The strategy half of the engagement was deciding where that line sat: which parts of the process deserved software at all, which were fine as a checklist, and which would be actively worse if automated. In a business this size, "we decided not to build that" is frequently the highest-leverage output.

The hard part: a checklist that stays true

The failure mode of every document checklist is drift. Someone adds a requirement for one unusual deal and it silently becomes permanent. A requirement that no longer applies stays on the list because removing it feels risky. Six months in, the checklist has thirty items, half of which are marked "N/A" on every file, and the team stops trusting it — which is worse than not having one, because now the omissions are invisible.

The way to keep a checklist honest is to make the requirement list a function of the deal rather than a fixed template: loan position, property type, entity versus individual borrower, and purpose each pull in their own items. Then "N/A" mostly disappears, and an item that is still open genuinely means something is missing. It also makes the checklist itself reviewable — you can look at the rules once a quarter and ask whether each one still earns its place, instead of auditing every past file.

The same logic applies to notifications. Alerts on a timer get muted. Alerts on a state transition, or on a deal that has not moved in longer than its stage normally takes, keep their meaning.

What this project reinforced

Three things carried forward into later work.

Speed is an operational property, not a technical one. Nothing in this stack is fast in the benchmark sense. What makes the business fast is that no deal waits on someone remembering to do something. The software's job was to remove waiting, not to reduce latency.

Structured intake pays for itself immediately. The single highest-return piece of software in a process-heavy business is almost always the form at the front of it, because every ambiguity you resolve at intake is an ambiguity you don't chase down later under time pressure.

Match the software to the operator. Gateway is not a fintech with an engineering team. Building it something it would need me forever to maintain would have been a bad outcome, however impressive the architecture. Small, boring, and legible beat clever here — and that judgment is most of what a single experienced developer brings to a business like this, versus an agency incentivized to build more.

Related: Brivio Property Management is the same pattern applied to another operations-heavy California real estate business, and freelance developer vs. agency covers the trade-off directly.