Case studiesHitch: Non-QM Origination Platform
Hitch: Non-QM Origination Platform
A real estate equity and mortgage origination platform built end to end, connecting brokers, investors, underwriters and administrators in one workflow. Deals move through automated underwriting rules and document signing without leaving the system, with each party seeing only what their role permits.
Visit live site
1 / 5The problem
A mortgage deal is not one workflow. It is four parties with conflicting needs looking at the same file.
A broker submits and tracks their own pipeline and must never see another broker's. An investor evaluates placements and needs deal economics without the borrower's full personal file. An underwriter needs everything. An administrator needs to see across all of it and configure the rules everyone else operates under.
Most systems solve this by giving everyone the same interface and hiding fields, which pushes the security boundary into the presentation layer, exactly where it is easiest to get wrong. In lending, a permissions mistake is not a bug. It is a disclosure.
The second problem sits alongside it. Non-QM lending exists because the borrowers do not fit standard criteria, which means the underwriting rules are the product. They change, they vary by lender, and they cannot be hard-coded.
What we built
A web platform with a dedicated portal for each party, plus an admin control centre where the rules and the roles are configured.
Deals move through the system as a workflow rather than a document handoff. Applications enter, underwriting rules evaluate them, documents are signed in place through integrated signing APIs, identity and KYC checks run against the parties involved, and placements move to investors. Payment processing and CRM integration close the loop so the deal does not have to leave the platform to complete.
Technical decisions
Role-based access enforced at the data layer, not the interface.
Every query resolves against the requesting role before it returns anything. A broker's request for a deal list cannot return another broker's deals, because the constraint lives where the data does rather than in the component rendering it. This was the single largest design decision in the build and the one with the least room for error.
Underwriting as a rule engine rather than application code.
Lending criteria change, and shipping a release for every criteria change would have made the platform slower than the business it serves. Modelling the rules as configurable data meant an administrator can adjust criteria without an engineering cycle, and every evaluation stays auditable.
Deal progression as a state machine.
With four parties acting on the same file, order matters and race conditions are expensive. Modelling a deal as explicit states with defined transitions meant the system could reject an invalid action rather than allowing two parties to move a deal in opposite directions.
Document security tied to deal state and role together.
Access to a document depends on both who is asking and where the deal has reached. Combining the two conditions avoided the common failure where a document stays reachable after the party's involvement has ended.
The underwriting risk models, valuation formulas and investor data metrics are the client's and are not described here.
The result
The full ecosystem was engineered, deployed, and handed over to the client's team. Hitch runs it as their non-QM origination platform.