Methodology
Trust in data starts with showing your work. Here is exactly how the numbers are made.
Data collection
We track sold outcomes only — never asking prices — from three source classes:
- Public sold listings on marketplaces that publish final prices. We store the transaction facts (price, revenue, profit, dates, category) with a link to the source. We do not republish listing content.
- Public deal announcements — founders and acquirers announcing terms publicly.
- Self-reported deals from buyers/sellers via the submission form, email-confirmed and reviewed before publication, marked as self-reported. Evidence-backed self-reports earn higher confidence (verification program: phase 2).
Every row carries a confidence grade: verified (marketplace-verified figures), reported (stated by the source), estimated (derived, e.g. annualized from monthly). Rows without a source link are accepted only as self-reports.
Multiples
×profit = sold price ÷ trailing-12-month profit, ×revenue = sold price ÷ TTM revenue. Multiples outside (0, 100) are excluded as data errors. Where a listing shows monthly figures we annualize and grade the row estimated.
Calculator estimates
Your inputs are matched against sold deals of the same asset type. We use the interquartile range (25th–75th percentile) of comparable multiples, with 5% tail-trimming once samples exceed 20, and require at least 5 comparables before showing any number. Profit multiples are preferred; revenue multiples are the fallback.
Every estimate is shown with the sample it came from: what those comparables sold for, when, and where. Coverage is uneven — profit figures are published far more often on small auction listings than on larger private sales — so when the business you entered is several times bigger than the median comparable, we say so rather than letting the number stand unqualified — in the calculator, on the order form before you pay, and in the delivered report, which shows the sample it was built from. We do not exclude, floor, or reweight a sale because its price is inconvenient; a thin or lopsided sample is disclosed, never smoothed.
Paid reports
Reports start from the same statistical estimate, then an AI analyst adjusts for asset-specific factors with explicit reasoning, verifies what can be verified on the public web (citing sources), assesses the asking price, and produces a risk register and seller-diligence questions. Metrics submitted by the requester are always treated as unverified claims and labeled as such.
Every report carries the sample its range rests on — how many comparables were used, what they sold for, over what dates, on which venues, and how the subject compares in size. Where our comparables are much smaller than the business being valued, or where the typical comparable sold for less than a year of the profit its seller stated, the report says so and the range should be read as a floor.
Before a report is delivered it is checked mechanically: the range must be ordered, the applied multiples must reconcile with the dollar figures on the stated basis, and the caveats must be present. A report that fails those checks is regenerated rather than sent. Reports are generated once and stored — the copy you receive is the copy that stays at your link.
What our comparables actually cover
Read live from /api/stats when this page loads.
Coverage is uneven in a specific, measurable way, so rather than describe it in prose that goes stale we publish it. For each asset type: how many comparables carry a usable profit multiple, what those comparables sold for, and the median profit behind them. A business several times larger than the median here is outside what our transaction data can price; the report will lean on public-web comparables instead, and will say so.
| Asset type | Usable profit comps | They sold for | Median profit |
|---|---|---|---|
| Loading live figures from /api/stats… | |||
Large sales are in the database — they are simply not in this table: a sale only yields a multiple when the listing publishes financials, and the larger the deal the less often it does. Closing that gap is a data-collection problem, not a modelling one.