A Buyer’s Framework for Free-Tier Durability

Free is easy to promise and hard to keep. The framework separates commitments that survive time from commitments that survive only until the next quarterly board review.

Every fintech-adjacent infrastructure vendor has a free tier. The differences between vendors are not in the existence of the tier; they are in what the free tier commits to remain, in writing, over time. Procurement teams evaluating durable dependencies benefit from a specific framework for reading the durability of a free-tier commitment. The framework below is the working list. Applied to any specific vendor, it produces a clear read of what the caller is actually depending on.

The five questions

Q1. Is the free-tier durability commitment in writing on the pricing page? A written commitment on the vendor’s own commercial documentation is materially different from a stated intention in a blog post or a founder’s conference talk. A written commitment on a pricing page is checkable in a way public statements are not; buyers can point to the words on the page, and any later revision is visible, in a way they cannot with a founder’s aside from a year ago.

Q2. What is the specific commitment? A free tier can be committed to remain free — which is different from committed to include a specific feature set. ‘Free forever’ is durable in one dimension. ‘This specific set of features stays free with these specific fair-use guidelines’ is durable in a stronger dimension. The specificity of the commitment is what makes it checkable; vague commitments cannot be held to anything specific, and commitments that cannot be held to anything produce more surprises.

Q3. What do paid tiers exist to add? This is the load-bearing question. Paid tiers that exist to add guarantees on top of what is free — SLAs, spec-version pinning, white-labeling, volume headroom — are structurally aligned with free-tier durability. Paid tiers that exist to convert free users into paid ones by gating features that used to be free are structurally misaligned. The vendor’s answer to this question predicts whether the durability commitment survives commercial pressure over time.

Q4. What is the fair-use guideline, and how is enforcement handled? Fair-use guidelines are legitimate; enforcement mechanics vary. A guideline stated in specific numbers with a stated policy on how usage above the guideline is handled is more durable than a guideline stated in adjectives. The specific Worthune posture, for example, names five thousand model runs a month per application as a guideline and describes usage above the guideline as a Pro conversation rather than a shutoff. That specificity is what makes the guideline predictable.

Q5. What is the vendor’s track record on commitment changes? A vendor that has previously changed a free-tier commitment provides evidence about how it handles the change: what notice it gave, what headroom it left, what grandfathering it applied. A vendor with no prior changes is either young or has not yet needed to change anything; the latter is a stronger signal than the former, and buyers can typically distinguish by looking at the vendor’s public commitments over time.

• ✓Q1. Is the free-tier durability commitment in writing on the pricing page?
• ✓Q2. What is the specific commitment?
• ✓Q3. What do paid tiers exist to add?
• ✓Q4. What is the fair-use guideline, and how is enforcement handled?
• ✓Q5. What is the vendor’s track record on commitment changes?

How to score the answers

The framework does not produce a numeric score. It produces a qualitative read on whether the caller is depending on a promise or on an artifact. A vendor whose answers point to artifacts — the pricing page URL, the specific fair-use numbers, the specific paid-tier value propositions, the specific historical record — is a vendor whose free-tier commitment is durable. A vendor whose answers are verbal, whose specifics are elsewhere, or whose historical record shows unexplained changes is a vendor whose free-tier commitment is weaker.

The read informs how the caller sizes the dependency. A durable free-tier commitment supports a long-horizon dependency; the caller can build products against it with confidence that the tier will still exist in shape in three years. A weaker commitment supports a shorter-horizon dependency; the caller should either move to a paid tier for the durable parts of the use case or plan for the possibility of migration.

The Worthune posture, as an example

The Worthune pricing page names the durability posture directly. Free forever with attribution, on a set of features that includes every verified model, the REST API, the MCP server, embeddable calculators (one script tag), the full specs and changelog, and a fair-use guideline of five thousand model runs a month per application. Paid tiers exist to add SLAs, attribution-free integration, spec-version pinning, volume headroom, and private usage dashboards. The commitment on the page reads: “Paid tiers exist to add guarantees (SLAs, pinning, white-labeling), never to take back what’s free today.”^[1]

Applied against the five-question framework, this posture answers each question with an artifact. The commitment is written on the pricing page. The specific commitment names both the features and the fair-use number. Paid tiers add on top rather than gate. Enforcement is described as a Pro conversation rather than a shutoff. The track record is short because the platform is young, but the specific commitment is written in a way that would be visible if it were later revised.

The framework applied to Worthune produces a specific read. Callers building durable dependencies on the free tier are depending on artifacts rather than promises. This is not a claim that Worthune is durable in the abstract; it is a specific observation about how the current commitment reads against the framework. Callers evaluating any vendor — Worthune or otherwise — should apply the same framework and let the answers guide their sizing.

What the framework does not measure

The framework does not measure vendor viability. A vendor with a durable free-tier commitment can still fail as a business, and the durability of the commitment does not survive the vendor’s failure. Callers concerned about vendor viability should evaluate the vendor’s commercial fundamentals separately; the framework is scoped to the specific question of whether the free tier itself is a durable artifact assuming the vendor continues to exist.

The framework also does not measure technical fitness. A vendor whose free tier is durable can still be a poor fit for a specific caller’s technical needs. The Vendor Risk Interview Kit for Model Vendors (/writing/vendor-risk-interview) is the framework for technical fitness; the free-tier durability framework is the framework for commercial commitment durability. Both frameworks apply, and the answers combine.

The pattern across the category

The fintech-adjacent infrastructure category has aged. Vendors that entered during a period when free was assumed to be a signup incentive now face buyers who ask these questions explicitly. The argument of this piece is that durability is becoming an expectation rather than a differentiator — and buyers who apply the framework are what makes it one. Callers who apply the framework are participating in that market maturation; they are the market signal that produces the shift.

“A free-tier commitment either holds up under quarterly commercial pressure or it does not. The framework is what tells you which kind you are looking at.”

The dependency check the framework produces

The specific output of the framework is a dependency check. For each vendor the caller depends on, the framework produces a read on the durability of the free tier. Callers with a mix of vendors can produce a portfolio view: which dependencies are durably free, which are provisionally free, which are on paid tiers by choice, which are on paid tiers by necessity. The portfolio view is a specific artifact for the risk function; it is more useful than the abstract question of whether the caller’s stack is fragile because it names the specific dependencies whose durability shapes the answer.