Estimating a Private Competitor's Revenue From Public Signals

This guide is for strategy and talent-intelligence analysts who have to put a dollar figure on a private competitor that files nothing. It runs three independent estimation methods, reconciles them into one number, and tells you how wide the band around that number should be. The output is a single revenue estimate you can defend line by line in a strategy review, with each input traced to a source and each multiplier justified.

Most research playbooks stop at headcount or size a whole market's total addressable market. Neither hands leadership a dollar figure for one rival with an honest error band. That is the gap this document fills.

What "defensible" means for a private revenue estimate

A defensible estimate is a single number bracketed by a stated confidence band, where every input traces to a named source and every multiplier is justified. It is not a guess dressed as precision.

The reason you need a band at all is that no public-signal method is exact. The cleanest documented figure comes from the analogous field of Amazon sales estimation: a triangulated estimator lands within plus or minus 30% of actual sales when used correctly. Treat that as your starting band for any single method, then narrow it only when independent methods converge.

The other anchored number is the reconciliation rule. If two methods roughly agree, trust the result. If they disagree by more than 2x, investigate before acting. That 2x threshold is the real quality gate of this entire procedure. A single method inside plus or minus 30% still misses badly on outliers, so agreement across methods is what turns a guess into evidence.

There is no published formula for exactly how the band tightens as methods converge, so do not invent one. State convergence qualitatively: "three methods agreed within 1.4x, so I narrowed the band from plus or minus 30% toward plus or minus 20%." That is honest. A tighter number implied by a formula you cannot cite is not.

Why sector classification decides the estimate before you start

The single largest driver of your estimate is not headcount - it is which sector you assign the target to. Revenue per employee, the ratio at the heart of the dominant method, ranges from under $35,000 to $1.76 million across sectors. That is a 50x spread.

Revenue per employee, or RPE, is annual revenue divided by full-time-equivalent staff. The load-bearing public source is Aswath Damodaran's NYU Stern "Employee Metrics by Sector" dataset, updated January 2026 and built from public-company filings across more than 90 industries. The broad US market average is $111,000 per employee, but that average hides the variation that matters.

Only three of the 90-plus sectors average more than $1 million per employee. Labor-intensive industries such as restaurants, general retail and hospitals sit at the low end, below $35,000 in some cases. Software sits high because a small team can serve a large customer base.

The practical consequence: a 20% error in headcount changes your estimate by 20%, but misclassifying a brokerage as a general-retail business changes it by roughly 40x. Get the sector right first, and get the stage right second, because RPE rises with scale within a sector.

For private software specifically, the median RPE is $141,125 as of 2026, up from $129,724 the year before, per a survey of more than 1,000 companies. But do not stop at the median. Size matters, and so does funding status.

Two things fall out of this table. First, ARR per employee climbs as a company scales - a $20M-$50M firm generates roughly 66% more per head than a $1M-$3M firm. If a rival's revenue per employee does not improve as it grows, its operating model may not be scaling efficiently, which is itself a finding. Second, bootstrapped firms run about 16% above equity-backed peers at the $5M-$10M band. Funding status is a hidden multiplier. Applying an equity-backed benchmark to a bootstrapped rival will understate its revenue.

The four public signals that convert to revenue

Four independent signal families turn into a revenue figure, and each carries its own assumption. You will use at least two, because independence is what makes reconciliation meaningful.

• Headcount times RPE. The dominant method. It needs a clean full-time-equivalent count and a sector-appropriate RPE.
• Web traffic times conversion times average order value. For commerce. The global ecommerce conversion average is 1.9 to 2%, with Shopify stores typically at 2.5 to 3%, and the average order value stands at $168.64. Both are assumptions you must state.
• Review velocity as a sales proxy. Assumes a consistent percentage of buyers leave reviews, so review count over time tracks sales over time.
• The payroll multiple. A back-of-envelope: annual revenue equals employees times industry average salary times 2.5. Fast, coarse, useful as a sanity check.

The reason to prefer the RPE method as your primary is that it needs only one clean input: headcount. That is also its weakness, because headcount is the most corruptible input you will touch.

The procedure, start to finish

Run these eight steps in order. The whole job takes a working day for one analyst plus a couple of hours of senior review. Times are per stage.

A note on order. Some sources lead with comparable-public scaling because a named peer is a real anchor, and treat the industry-average RPE as the fallback. Others lead with RPE because it needs only headcount. Both agree the two must be cross-checked, never used alone. Lead with whichever gives you the cleaner input for your target, but never skip the second.

On step 2: getting headcount you can trust

This is the step that determines whether the whole estimate is sound. Headcount corruption propagates through everything downstream. Pull LinkedIn plus one database estimate, and if the two roughly agree - say LinkedIn shows "51-200" and a database estimates 175 - you have reasonable confidence. Where you can, split the count by department, because a department mix tells you whether the company is sales-led or engineering-led, which affects both the RPE reference and the comparable peer you pick.

The friction here is separating real employees from contractors and leavers who never updated their profiles. Refolk removes that friction directly. I can return current employees only, or isolate the people who list the company but carry "contractor" or "consultant" in their title, so the contingent workers come out of the count before they inflate it.

On step 5: demand-side signals for SaaS versus commerce

For a commerce target, traffic times conversion times average order value is the classic build. Use $168.64 as the order-value anchor and model three conversion scenarios rather than one rate, because visibility is not sales. For a SaaS target, there is no checkout to observe, so build from pricing tiers times an estimated seat or customer count, and read the job-posting mix as a growth signal. A rival hiring heavily into a mid-tier sales motion tells you something a homepage does not.

Reconciling three numbers into one

Reconciliation is a divergence test, not an averaging exercise. Lay the three estimates side by side. If they agree within roughly 2x, take a weighted midpoint and narrow the band toward plus or minus 20%. If any pair diverges by more than 2x, stop and investigate before you average anything.

kind: matrix
title: What to do with two estimates
caption: The action depends on whether the methods agree and whether your inputs are current.
x: Methods diverge >2x :: Methods agree within 2x
y: Inputs stale or single-sourced :: Inputs current and cross-sourced
quadrant: Investigate headcount and RPE reference first :: Publish with a wide band and a data caveat
quadrant: Do not average - one input is wrong :: Take a weighted midpoint, narrow the band

Weighting is a judgement call, and you should state it. Give more weight to the method with the cleanest input. If your headcount is cross-sourced and current, weight Method A. If your comparable peer is a genuine same-stage match, weight Method B. If your conversion assumptions are shaky, weight Method C down. The point of writing the weights down is that a reviewer can challenge them, which is exactly what a defensible estimate invites.

Triangulation buys real accuracy because the signals fail independently. Headcount error comes from contractor inflation. Traffic error comes from conversion. Review error comes from review-gating. These are uncorrelated, so when three methods built on unrelated inputs agree, that agreement is genuine evidence rather than three copies of the same mistake.

How this goes wrong: the failure modes

Every failure mode below has produced a wrong estimate that looked defensible. Each has a false-positive signature and a specific check. This is the section to read twice.

Contractor-inflated headcount. A firm with 800 staff and 200 contractors may read as 1,000 online. RPE then understates the firm's true efficiency and overstates its revenue. The distortion is growing: contingent workers rose 15 to 20% in 2024. The check is to strip contractors, cross-source the count, and flag any firm that runs on contractors instead of employees, because that structure breaks the RPE assumption outright.

Stale profiles. LinkedIn's count can overstate active headcount by including people who have left. The false positive is apparent growth that is really un-updated leavers. Check a 6-to-12-month headcount trend across two sources, and isolate recent leavers directly before you trust any growth signal.

Wrong RPE reference. Using the $111,000 all-industry average for a high-RPE sector like brokerage, which sits at $1.3 million, produces a roughly 10x error. Anchor to a named same-stage peer, not the cross-industry mean. This is the most common way a competent analyst produces a confidently wrong number.

Traffic that does not convert. A high-traffic site with a poor checkout inflates a traffic-times-conversion estimate. Visibility is not sales unless conversion holds, and conversion moves with reviews, images, delivery promise and price. Model conservative, expected and optimistic scenarios; never publish a single rate.

Review-gating. If a seller solicits reviews aggressively or suppresses them, the constant-review-rate assumption breaks and sales are over- or under-stated. Validate the rank or best-seller-rank trend alongside review counts, not reviews alone.

Single-method false confidence. One method inside plus or minus 30% still misses badly on outliers. Require two independent methods to agree within 2x before you trust either.

Stage mismatch in comparable scaling. Scaling an early-stage target off a mature public peer's RPE overstates revenue, because RPE rises with scale. Match growth stage, not just sector.

The geography weighting most analysts skip

Sales headcount is a signal, but its meaning depends on the market. The same team size implies very different penetration in a deep market versus a thin one. This is where a private rival's true footprint hides.

In Refolk's index of professional profiles, the United States returns 3,120 people with an Account Executive title and a SaaS skill, versus 61 in Germany - a roughly 51x depth gap in that sales-headcount signal. Top US employers on that signal include Salesforce, Elastic and Ironclad; in Germany they include SAP, Palo Alto Networks and Meltwater.

Read this as a relative-depth signal, not an absolute count - it reflects index coverage, not true installed sales headcount. But the weighting logic holds. A rival's German sales team of 10 implies far deeper market penetration than the same team of 10 in the US, because the German pool is so much shallower. When you break a rival's revenue down by geography, weight the thin-market teams up. Refolk lets you map that footprint directly by pulling the rival's Account Executives country by country.

Before you call it done

Run this checklist before the estimate leaves your desk. Each item is a specific verification, not a topic to think about.

Here is the trace format that survives a strategy review. Copy it and fill one row per input.

Target: [company], [sector], [stage], [geography]
---
Input | Value | Source | Source type | Confidence
Headcount | 175 FTE | LinkedIn + database | database estimate | medium (two-source agree)
Contractors stripped | 22 | employer-listed titles | RPE estimate | medium
Sector RPE | $141,125 | SaaS Capital 2026 | filed benchmark | high
Method A result | $24.9M | headcount x RPE | derived | medium
Method B result | $21.0M | peer headcount ratio | derived | medium
Method C result | $27.5M | seats x pricing tiers | derived | low
---
Reconciliation: three methods within 1.3x; weighted midpoint = $24M
Confidence band: $20M-$28M (approx plus/minus 17%, narrowed from +/-30% on convergence)
Outlier check: no holding-company or automation structure found

Keeping the estimate current

An estimate has a shelf life because its inputs drift. Headcount moves, contingent-worker share rises, benchmark tables update annually, and the target's stage changes as it scales. Set a refresh cadence rather than treating the number as fixed.

Re-pull headcount every quarter and re-check the trend across two sources, since that is where stale-profile inflation creeps in. Refresh the RPE benchmark whenever the underlying tables update - the NYU Stern set refreshes annually in January, and the private SaaS survey publishes yearly. When the target crosses an ARR band, move its RPE reference up, because a firm that grows from $3M to $25M in revenue should show materially higher revenue per employee, and holding the old benchmark will understate it.

The mechanism to watch, more than any single number, is the gap between your three methods over time. If they were within 1.3x last quarter and now diverge past 2x, something moved in the business - a hiring surge, a pivot, a contractor build-out - and that divergence is a lead worth chasing before it shows up anywhere public.