The first time I saw it clearly was with a lender who had been on a bundled platform for three years. Fixed-rate installment loans, clean operation, and no complaints. The week they added a construction product to their portfolio, the platform did not break, but the pricing did. That is when I understood the problem was not the software. It was the pricing model on which the software was built.
A bundled platform charges one fixed cost for every feature the vendor packages together. The lender pays that cost whether they service one loan product or six.
Modular loan servicing pricing works differently. The lender pays a base subscription for core servicing, then adds discrete modules only when a new loan product requires them. Escrow for impound-bearing loans, draws for construction, and ACH for scheduled payment debit. Each module activates against a specific operational need. Nothing more.
The difference between those two structures is what every multi-product lender is paying for right now, whether they have measured it or not.
Bundled pricing penalizes multi-product lenders by charging them for modules their current loan types do not require, then locking that cost in regardless of operational fit. The structure treats every lender as if its product mix were identical, which it is not.
The penalty shows up in three specific ways. First, the lender pays for modules that do not serve any loan product currently in the portfolio. A consumer installment lender with no escrow exposure still pays for the escrow logic the vendor packaged into the suite.
Second, the model creates a cost cliff the moment a lender adds a structurally different product. The new product pushes them into the next pricing tier even when they only need one new module to service it.
Third, bundle pricing assumes uniformity across loan types. That assumption breaks the moment a lender’s product mix expands.
The OCC’s Loan Portfolio Management booklet identifies loan product mix as a distinct strategic objective in portfolio planning, and the Comptroller’s Handbook addresses the risks of construction, consumer, and commercial lending in separate, dedicated booklets because the operational profiles of each differ materially.
A platform that serves all of them at a single fixed price is charging each lender for capabilities the others require. What I kept seeing was the same outcome. Pricing scaled faster than the operation did.
Modular pricing solves the structural mismatch between a lender’s actual operations and what their servicing platform charges them. It does this by separating the base servicing layer from product-specific capabilities, so the cost the lender pays maps to the products they actually run.
When I built Bryt, I started from a question every lender I had worked with kept asking. Why am I paying for capabilities I do not use? The answer was the pricing model itself.
So I built Bryt’s pricing on a different principle. The base subscription covers core servicing:
Every loan product needs those functions regardless of type. From there, the lender adds modules only when a loan product in their portfolio requires that module’s functionality.
The point of the design is restraint. The platform does not assume what the lender needs. It waits for the lender’s product decisions and then activates the capabilities those decisions require. A pricing model should follow the operation, not precede it.
Modular pricing benefits multi-product lenders by letting them activate only the modules each loan type requires, so the cost of adding a new product is contained to the modules that product needs. The existing portfolio’s pricing stays flat.
Take a private lender running fix-and-flip and construction loans side by side. The construction product needs draw disbursement, retainage tracking, and inspection-tied funding. The fix-and-flip product does not. The lender activates the Draws module against the construction portfolio, and the fix-and-flip servicing cost stays exactly where it was. Adding a structurally different product did not pull the existing one into a higher tier.
A second scenario: A CDFI servicing a consumer installment portfolio decides to add a small business term loan product. Business borrowers carry financial data that the consumer product never needed, things like revenue, debt service coverage, and entity structure. The CDFI activates Custom User Fields against the business portfolio. The consumer servicing cost does not change.
Neither lender is paying for capabilities outside their operation, nor are they absorbing a portfolio-wide cost increase to add one new product. Each module is doing one job for one product. That is the operational logic the pricing model is built around.
Multi-product lending is expanding. More lenders are diversifying their product range. More regulatory complexity per product type. More pressure to keep servicing costs proportional to portfolio size rather than fixed against it.
A pricing structure that scales with the lender’s product decisions, rather than imposing a fixed cost regardless of them, is an operational design choice.
Cutter Hill Capital services four structurally different loan products on this model: fix-and-flip, construction, commercial bridge, and buy-and-hold. That is what proportional pricing looks like in practice.
If you are servicing more than one structurally distinct loan product on a bundled platform, the cost of that mismatch is measurable.