← Back to all posts

RBF: The Collateral Is Your Code

The collateral for a revenue-based financing loan is your telemetry. The terms are engineering outcomes: margin is your architecture, revenue quality is your data model, the repayment schedule is your usage curve. Build revenue legibility like a system and the company gets financed like a system.

revenue-based-financingrbfstartupssaasaifinancingsoftware-engineeringgross-marginusage-based-pricingdata-qualitytelemetryunderwritingnon-dilutiveengineering-economics

The collateral for a revenue-based financing (RBF) loan is not an asset. It is your telemetry — the data your software produces about the revenue it generates. The lender underwrites a revenue stream, read through your APIs, your metering, your books: everything it knows, your code told it; everything it cannot trust, your code hid. That makes RBF the financing instrument most legible to software engineers, and the one whose terms are engineering outcomes — margin, usage, data quality. The cost of capital is a performance metric, set by the codebase.

The thesis: the company that builds its revenue legibility like a system gets financed like a system — the code you write sets the price of your money.

The mechanics

The terms are a protocol. A lender advances capital sized against your recurring revenue — commonly several months of it. You repay a fixed percentage of monthly revenue, typically 5–8%, until cumulative repayments reach the advance plus a multiple (typically 1.5–2.5x) or the term limit passes, whichever comes first; in most structures the balance is forgiven at the limit. No equity, no board seat, no fixed payment that can sink a bad month. Lenders may still take a lien at the small end — telemetry is the underwriting collateral, not the only legal one. Reported volume: $9.8B in 2025 (Lighter Capital, Capchase, Pipe, Wayflyer, Founderpath, Recur Club).

Equity Venture debt RBF
Cost dilution + board interest + warrants % of revenue to cap
Collateral none company assets your telemetry
What the builder controls roadmap + burn unit economics margin, usage, data quality

The arithmetic nobody does

The cap is the price, and duration sets the rate. A $1M advance at a 1.8x cap costs $800,000 — roughly 40% a year over 24 months, half that over 48. Sellers quote the percentage of revenue, never the rate, because the rate depends on growth, the one number the lender cannot know. And the arithmetic cuts against fast growth: repayment is a share of revenue, so the cap is hit fastest when revenue grows fastest. At $100k MRR, 6% repayment, 1.8x cap: 10% monthly growth caps out in ~3 years (~25% annualized); 3% growth takes 6+ years (~half). The rate was never in the contract; it was in the roadmap. The fastest-growing product is the one where equity would have been cheapest — the instrument is cheapest, in rate terms, for the companies that need capital least.

Where engineering decides the terms

The term sheet is written in your code, in four places.

Gross margin is an architecture decision. For an AI product, margin is set in the serving layer — routing, batching, caching, prompt compression. Every point of margin recovered is a point the repayment cannot consume.

Revenue quality is a data problem. Recurring vs one-off, churn — outputs of your metering, billing, and analytics. "Is this revenue recurring?" is an instrumentation decision. Clean revenue data is the company's credit file.

Usage-based pricing is fragile revenue. Readable in real time, cancelable in real time — a config change, a model switch, an agent contract lapse. Contracted MRR survives board meetings; usage revenue survives until the next API call.

The repayment schedule is your usage curve. Every revenue-generating agent call is a drip into the repayment — free-tier usage is not collateral.

The lender is a software system

The counterparty is a system, not a banker: live revenue feeds, ML credit models over churn, automated checks; diligence is an API integration. Its model asks what your analytics stack asks — is this usage real? — and in the AI age real and manufactured usage look alike: agent-driven signups, inflated usage, subsidized pilots, card stacking. Revenue-quality detection is an adversarial ML problem; lenders who skip it underwrite the AI economy's subprime.

The fit test

Perfect fit: a high-margin API product with clean metering — 80% gross margin, a year of revenue history. Take $1–3M, buy growth, repay from the usage growth creates.

Wrong fit: the compute and training layer — capex with delayed revenue, nothing to underwrite.

Tricky fit: below ~60–70% gross margin or pass-through revenue — repayment eats real cash flow and the lender cannot trust the stream.

What the honest critics say

Three objections survive. The cap can cost more than the equity you saved — 1.8x on a fast-growing product can exceed the dilution of a modest round. Revenue is the tax base and the north star — RBF takes a cut of the metric you optimize, hardest in the quarter when it repays fastest. And revenue can be manufactured, more easily in the AI age — revenue quality (recurring, diversified, contract-backed, human-signed) becomes the new credit score.

The test

Six questions, asked the way an engineer reviews a design:

  • What is the annualized cost of the cap at your actual growth rate? (If you cannot answer, you are signing a rate you do not know.)
  • What is gross margin per feature, and who owns it?
  • Is revenue recurring or usage-based, and does your metering make the difference visible?
  • Is the capital for growth rather than R&D capex?
  • Does the cap cost less, in real dollars, than the equity you would give up?
  • Will the revenue still be there, and still real, in month 24 — and would your own data prove it?

The first question is the one sellers never ask; the last is the one the AI age added. If the only thing generating the revenue is the same machinery that reports it, the lender is underwriting a mirror.

RBF prices what you have built, not what you might build. The collateral is your code, the repayment is your usage, and the cost of the loan is whatever you failed to compute about your own growth. Do the arithmetic before the lender does.

References: