Build vs. Buy Loan Management Software: The Staffing Cost

You have the launch cost. You may not have priced what it costs to keep the infrastructure staffed while the rest of the roadmap ships. That gap is where most build decisions break down. The same gap shows up for the lender who already built, eighteen months into an in-house ledger and now deciding whether to extend it or migrate off it. For loan management software, the real question is whether your team can own the compliance and ledger infrastructure indefinitely, not just on day one.

The Visible Cost and the One You Will Keep Paying

The spreadsheet looks complete. Development phases, integration work, testing cycles, the whole thing mapped to a timeline and a budget number. An engineering VP is walking the planning meeting through a build estimate for a loan management system (the platform that handles ledger math, servicing operations, and compliance for a lending program). The estimate has a launch date, and it feels like a one-time investment.

The initial build is the visible cost. It shows up in the project plan, it carries a deadline, and it ends at launch.

What doesn't appear is the team that will maintain the ledger after that launch date, absorb ongoing regulatory updates, and fix accounting errors when they appear. The lasting cost is staffing those infrastructure lines while still building the lending product. Development has a finish line. Infrastructure staffing doesn't.

They belong to different economic categories. One is finite and settles at launch. The other runs for the life of the lending program, compounding as the portfolio grows, as regulation shifts, and as the next product reaches the roadmap.

A build estimate that covers development but doesn't model the team carrying that infrastructure forward isn't a complete cost comparison. It's a down payment on a cost that shows up later, after the team is already committed to the path.

If You Have Already Built: When to Extend and When to Migrate

‍

The engineering lead reviewing her options isn't facing a migration question yet. She's facing a ledger adequacy question. The second product on the roadmap, a revolving credit line alongside the existing installment product, doesn't care whether the current ledger was built with care or speed. What matters is whether it can carry the next eighteen to twenty-four months of work without accumulating more debt than it's worth fixing.

If a lender is eighteen to twenty-four months into an in-house ledger and product two is now on the roadmap, the question isn't whether migration is possible. It's whether staying on the current ledger for the next eighteen to twenty-four months costs more than moving now.

Most migration discussions measure difficulty, not cost. A migration costs something once. Staying on an inadequate ledger costs something every month the team maintains it alongside the lending product.

When the migration question is worth taking seriously, it follows a recognizable shape. Data contract design comes first: entity mapping, event schema, and how much history needs to transfer. Then comes a parallel run with daily reconciliation, where both systems process the same events and the team catches drift before it becomes a ledger problem. The third phase is cohort cutover with bank-sponsor briefing (the bank sponsor is the chartered institution that holds the lending program's regulatory relationship). Borrowers move in groups and the audit handoff is documented. The fourth phase is a read-only audit mirror, where the source ledger stays available for the retention window so historical questions resolve against the original system of record.

Staying can be better when the current ledger covers the next eighteen to twenty-four months, or when the tech debt resolves inside one focused quarter. Staying can be better when senior engineering can't absorb a migration while building product two, when the bank-sponsor relationship is too fragile for an audit-trail handoff, or when the current system is genuinely best-of-breed for the product mix.

When none of those conditions apply, extending isn't the obvious safer path. The migration is worth a serious engineering assessment.

Migration difficulty isn't the variable that determines whether to migrate.

What the Compliance Infrastructure Actually Costs to Build

The text goes out on a Tuesday. Thirty days past due, auto-generated, routed through the dialer queue before anyone reviewed it. The borrower received activation orders three weeks earlier. They're on deployment.

No one on the servicing team knew. The activation was never flagged. The loan management system had no process to check the DoD list, and the list had moved. Under the Servicemembers Civil Relief Act (SCRA), which restricts the collection actions a lender can take against an active-duty servicemember, that outbound text arrives in potential violation.

Portfolio monitoring exists to prevent exactly that. The monitoring has to run before the first communication leaves the platform, not after.

The portfolio scanner

A portfolio-wide event scanner has a single job. It checks every active borrower against a set of external status lists on a defined schedule, opens a case automatically on a match, and flags the account for review before outbound contact resumes. It's not a manual queue, not a policy document. It's a running process that has to be operational before the first loan books.

Military activation comes first. An internal service checks every borrower against the DoD active duty list, and when there's a match, a case opens carrying the active-duty branch and deployment start and end dates, before the borrower has contacted the lender. The servicing team learns about the activation from the system, not from a phone call a week after the text was already sent. The scenario at the top of this section is what happens when that process doesn't exist.

Bankruptcy is the second context. Because filings happen in federal courts and require external data access, staying current means integrating with a data provider that monitors court activity. When a borrower files, the case carries the court filing date, the chapter, the disposition codes, and the full case details the team needs to work the account.

When a borrower dies, the compliance question shifts from contact frequency to contact method and recipient. A working implementation includes pre-built compliant communication templates for this event type, including a notification-upon-death template, because who receives what message in those first days is a legal question.

The fourth context is an OFAC or SDN list match. OFAC is the Office of Foreign Assets Control, a Treasury Department office that maintains a list of individuals and entities US financial institutions can't transact with. The SDN list (Specially Designated Nationals) is the primary roster. A match is a legal hold on the account.

Building this infrastructure means securing the external integrations, standing up the case workflow downstream, and keeping all of it current as the external lists update.

None of that is a one-time project.

The pre-send check

Monitoring the portfolio catches status changes. What happens next is a separate problem.

Every outbound communication, whether system-generated or agent-sent, hits a real-time check before it leaves the platform. That check, called `can_interact`, evaluates channel, theme, subject, the borrower's do-not-interact status, loan state, and remaining contact capacity across daily, seven-day, and thirty-day windows. If any parameter disqualifies the communication, it's blocked before delivery.

Communications regulations don't work as flat rules. What's permissible depends on the channel, the borrower's status, the loan state, and the contact count within the relevant window. A borrower at the weekly contact limit under federal rules still gets a message if the system isn't tracking that count in real time across every channel and every agent touchpoint. The Telephone Consumer Protection Act (TCPA) and the Fair Debt Collection Practices Act (FDCPA) both govern outbound collection contacts. Non-compliant communications can carry five-figure penalty exposure per instance in some cases.

That's per message sent to a borrower who shouldn't have received it.

The check runs before delivery. Not as an audit after the fact. Identifying an unauthorized contact in a weekly review doesn't undo the contact.

What migration changes

A lender moving an active loan book doesn't leave SCRA obligations behind with the old system. Compliance obligations transfer with the portfolio. Borrower-status changes, contact limits, and dialer lists have to stay aligned across both systems throughout the migration window and after it closes. A split or in-house stack creates permanent reconciliation risk on those dimensions. Two systems that should agree on a borrower's do-not-interact status or remaining contact capacity can and do diverge.

That reconciliation burden is a line item in any migration estimate, the same way it's a line item in any build estimate. The compliance infrastructure has to be live before the first communication leaves the platform.

The borrower whose status changed last week is already in the portfolio.

Why a $75 Loan Demands the Same Ledger Accuracy as a $75,000 One

Most lenders assume ledger accuracy risk scales with balance. A $75,000 loan requires precision; a $75 consumer installment loan is simple enough that most accounting approaches handle it adequately. Small-dollar consumer lending inverts that.

Peach's architecture was shaped by the economics of small-dollar consumer lending. For a $75 loan on the platform, the lender advances $75 to the borrower and recovers the principal, fees, and interest over time. $75 installment loans produce low net interest income, so they need automation to operate profitably at scale. The second a human has to adjust a due date, fix an autopay setup, or handle a payment dispute, the lender is already losing money. The math leaves no margin for manual recovery.

A single failed payment shows where this breaks. When a payment fails on a small-balance loan, the system has to adjust daily interest accrual for the missed period, update the borrower's statement, record the event for investor reporting, and maintain a log that can be replayed if anything is disputed downstream. Each of those is a real accounting step, not an abstraction, and not optional. If the architecture doesn't handle them automatically and in sequence, a back-office analyst reconstructs the accounting by hand. On a $75 loan, that reconstruction can consume a thousand dollars in staff time.

Event-driven architecture, in practice, follows strict rules about how each event flows through the platform, recording every state change so the ledger state at any point is derivable from the event log. Nothing gets skipped. The design is why a payment failure on a $75 loan closes without anyone opening a spreadsheet, and why retroactive adjustments stay performant rather than collapsing into a manual restatement exercise.

Peach calls this capability Loan Replay, and its clearest case is a rate change that should have applied weeks ago. A manual correction at that point means reconstructing every day of accrual between the original effective date and today, a project whose scope grows with the lag. With Loan Replay, the system applies the corrected terms at the original effective date and replays the entire interim period forward. It reaccrues interest at the corrected rate, reapplies fees, and reapplies repayments against the updated balances, producing revised principal-and-interest splits and a current loan status. The correction is a recalculation, not a project.

Building around strict event rules costs something. The system is slightly less flexible in the product types it supports. A more configurable platform can do custom calculations and support a broader range of product structures, which gives a lender more room if their program sits outside the standard shapes. For lenders with unusual or highly customized product requirements, that flexibility may matter more than strict event enforcement.

For lenders inside those standard shapes (installment loans, revolving lines of credit, credit cards), the inflexibility is the point. The system gets the numbers right and can unwind whatever happened before. Not as a feature claim, but as an architecture commitment.

Strict doesn't mean static. Peach calls this Adaptive Core, and the configuration carries more than 200 variables. Within the standard shapes, a new loan type arrives as a new configuration, not a schema refactor, and it's live without a code deploy. When product two on the roadmap shows up, it's configured, not rebuilt.

A lender whose entire unit economics depend on keeping agents off the phone doesn't need the most flexible platform. They need the one that makes servicing cost predictable. On a thin-margin loan book, ledger strictness keeps the math working.

The Pricing Model Is Part of the Product

The finance lead modeling per-loan servicing cost for a 90-day installment product is likely comparing platforms on the monthly fee column. If one vendor charges less per active loan per month, her spreadsheet shows that vendor as cheaper. Her contract will say something else.

Some platform pricing carries three separate per-account charges. One triggers when the account opens, one runs monthly while the loan is active, and one triggers when the account closes. On a 36-month installment loan, those open and close fees spread across 36 monthly billing periods, making fixed costs a small share of total servicing expense. On a 90-day loan, those same bookend fees spread across three monthly periods. The arithmetic changes shape.

At approximately 50 cents per active loan per month, a six-month loan costs roughly $3 to service under a per-month-only model, from opening to payoff. One working understanding of how some contracts in the market are structured (not a verified rate card for any vendor) places the fixed-cost floor for that same six-month loan at approximately $4 before monthly fees enter the calculation at all. Under that structure, roughly $1 at account opening and roughly $3 when the account closes set the floor. Monthly fees add on top of that minimum. On a 90-day loan, a lender paying that structure runs three monthly fees between two fixed-cost bookends that together exceed the monthly component. The monthly rate, the number that dominates a vendor comparison spreadsheet, is the smallest variable in the math.

That's what the finance lead's spreadsheet misses. The monthly column is accurate. It's just incomplete.

A lender running a high-velocity 90-day product closes and opens a lot of accounts. Each payoff triggers a closing fee. Each new origination triggers an opening fee. Under that working understanding of a three-fee structure, those bookend charges aren't amortized across a long active period. On a 90-day loan, they're a large fraction of total per-account servicing cost across the lifecycle.

A 90-day consumer loan doesn't generate much per-account revenue. At that margin, the fee model governing per-account servicing cost determines whether the product pencils. A fee structure designed around 36-month installment products can make a 90-day book economically marginal at the same origination volume where a per-month-only structure stays profitable.

Several lenders operating in short-term small-dollar lending have moved to Peach.

Those weren't wins on features.

Pricing drove each one, specifically the unit-economics advantage a per-month-only model produces when loan duration is short and account turnover is high. The defensible niche is narrow on purpose. It covers small-dollar short-term lending where per-loan servicing cost is a meaningful share of what the loan earns.

That advantage doesn't hold across all loan types. A 36-month installment loan amortizes open and close fees across enough billing periods that fixed-cost bookends become minor. Per-month-only pricing is most compelling where loan duration is shortest and account turnover is highest.

Fee structure is a product design constraint, not a procurement line item. When the evaluation stops at the monthly fee column, the per-account charges that trigger at origination and at payoff are invisible in the cost model until they show up on the invoice.

When Building Is the Right Answer

Build can be the right answer. The conditions that make it right are specific enough to test against any lender's current situation without interpretation.

Narrow product scope is the first. That means a single loan type, designed for a single market, with no plans to add another. Funded staffing is the second, meaning a team sized not just to build the infrastructure but to maintain and extend it while still shipping the lending product. A stable roadmap is the third, and "stable" has a specific meaning here. The product mix is unlikely to expand into new loan types, new jurisdictions, or new compliance contexts within the planning horizon, not because the plan doesn't call for it yet, but because current evidence points that way. If the honest answer is that expansion is probable but unscheduled, the roadmap isn't stable.

When all three conditions hold simultaneously, the indefinite infrastructure staffing burden described earlier becomes a predictable line item rather than an open exposure. The team is funded to carry it. Scope doesn't compound it. That's where building makes financial sense.

Lending programs outside the US may not be covered; the compliance tooling is built for US loan books. Pre-revenue lenders still proving whether the lending thesis holds may find the infrastructure investment premature before the model is validated. Lenders considering migration from an active portfolio should verify the current platform is genuinely failing the roadmap, not just creating friction because of internal politics. A migration won't resolve that.

A founder with a single installment loan product for one US state, a team sized to maintain it, and no new loan types on the 18-month roadmap is describing conditions where a platform may cost more than it returns. That's a real position some lenders are in right now.

Two Questions That Decide the Build vs Buy Call

The CTO and VP of Finance in that planning session are probably framing this as a cost comparison. Launch cost versus license cost. Year one versus year three.

It doesn't survive contact with the actual question.

When the conditions favoring a build don't hold (narrow product scope, funded staffing, stable roadmap), the decision isn't about what it costs to launch. It's about what it costs to keep the infrastructure running while the company ships everything else on the roadmap.

The build-path test is whether the organization can staff the infrastructure lines indefinitely without slowing the lending product. That means today and as the program grows, as new loan types come online, as compliance obligations accumulate with each jurisdiction the lender enters.

The buy-path question is whether moving those infrastructure lines to a platform frees the team to ship the products the business is actually trying to launch.

Both tests have genuine yes answers. A team building a single installment product for a narrow US market, with engineers to maintain it and no new loan types in the near-term roadmap, may answer yes to the first. That's a real position some lenders are in.

For everyone else, answering yes requires optimism about roadmap stability, staffing headroom, and how compliance overhead scales as the portfolio grows. Optimism makes the math work in a planning session. It doesn't change what shows up later.

This isn't a launch-cost comparison. The constraint is capacity. A leadership team that can answer the build-path question honestly (not under conditions it hopes will hold, but under conditions that actually will) is the team for which building may be the right path. Everyone else is betting the staffing cost stays manageable as the program grows.

‍