Skip to content
The Software Atlas

How this was built

Methodology

Every number in the Atlas carries a value, a year, a unit, a source id and a confidence level. This page says what each of those means, how the derived figures were derived, and where the data runs out. Nothing here is decoration: if a chart looks empty, this page explains why the honest answer was to leave it empty.

Confidence levels

Three levels, applied to every data point in the Atlas and shown on every tooltip, every data table and every metric on a profile page.

ReportedReported
Taken from a company filing or official release.
EstimatedEstimated
An analyst or press estimate; definitions vary between firms.
ModeledModeled
Derived in this project; the method is stated on the data point.

The rule that keeps the three apart: a figure may only ship as reported if it appears, as printed, in a filing or official release that was fetched during this project. A ratio computed from two filed figures is modeled, not reported, even though both inputs are filed — the arithmetic is ours. Every modeled point carries a note stating the method, and that note is what the confidence badge shows on hover.

Marks in the charts follow the same three-way split: solid for reported, hatched for estimated, dashed outline for modeled. Where a value was interpolated between two reported years — the treemap does this as the year scrubber moves — the interpolated value is flagged as modeled, because no one measured that year.

✓ and ◇: what was actually checked

The research phase tagged every figure with one of two verification marks, and the data phase acted on them:

  • ✓ verified — the source was located and fetched during this project. The URL is in the source registry below.
  • ◇ not re-verified — the figure was a well-known filing value recalled during research but not re-fetched. A ◇ figure could only ship as reported after the verification pass confirmed it against the filing and logged it. Anything that failed that test ships as estimated with a low/high range, or was dropped.

The rule. verified: true means the cited URL was retrieved in this project and the figure was seen in retrieved content — page body, filing, API response, or a search engine's verbatim extract of that page. A source whose substance sits behind a paywall or a login that was never passed is verified: false, with its URL kept.

The other half of that rule is less obvious: a 403 on a later automated re-check does not unverify a source that was read earlier. Blocking is a property of the fetcher, not of the page — during review, a host that refused one fetcher returned the same page in full to another. The flag answers “was this figure ever seen in this project”, not “does an automated re-fetch succeed today”.

Of 192 sources in the registry, 156 clear that bar and 36 do not — for two different reasons. 9 are books, papers and case law cited from the literature: those carry no URL, by design. The other 27 are real, URL-bearing pages whose substance nobody here has read, because the body is paywalled or the host blocks automated fetchers. Their links are kept so you can try them yourself, and every figure resting on one of them ships as estimated. Neither group ever backs a reported data point, and the registry below lists the two apart, so a link sitting under a ◇ badge explains itself.

The full record of what was checked, what was corrected and what was rejected is in docs/verification-log.md in the repository.

Market sizing: bands, not point estimates

Analyst firms differ by two to three times on the same software category because they draw the boundary differently — whether CRM includes marketing automation, whether contact-centre software counts as service or as telephony. Gartner's IaaS figure and Synergy's cloud-infrastructure figure differ by more than two times for what sounds like the same market. So every market in the Atlas records its definition before it records a size, and the size itself is usually a band.

The method. Start from the combined revenue of the leading vendors in the category, divide by an assumed combined share for those vendors, and round out to an order-of-magnitude band. The band ships as a single modeled data point whose low and high span the whole band. The midpoint exists only so a treemap rectangle can be allocated an area; the span is the claim, the midpoint is not.

Size bands used in the Atlas, with the number of markets in each.
BandAnnual spendMarkets
XSunder $5B8
S$5–20B17
M$20–60B18
L$60–150B8
XLabove $150B4

Exactly one market — cloud infrastructure — carries a published, verified size series rather than a band, because Synergy Research puts quarterly figures in public press releases. Where a verified analyst figure exists for a category it replaces the band; otherwise the band stands, and the treemap hatches the rectangle so the reader can see at a glance which rectangles are measured and which are modelled.

HHI and top-three share, and why they diverge

HHI — the Herfindahl-Hirschman Index — is the sum of every firm's squared market share, with shares expressed in percentage points. A monopoly scores 10,000; a market split evenly between ten firms scores 1,000. The US DOJ/FTC 2023 Merger Guidelines treat a market above 1,800 as highly concentrated.

Top-three share is simply the sum of the three largest shares. It answers a different question: how much of the market the leading group holds, regardless of how it is divided among them.

Every HHI in the Atlas is modeled and carries this note: Modeled: sum of squared published percentage shares, with the residual 'Other' treated as a fully fragmented tail contributing zero, which makes this a lower bound. Because the unreported tail contributes zero, each figure is a lower bound on true concentration.

Why the two measures disagree. Cloud infrastructure is the one market here with a published share series, and it shows the divergence cleanly:

Modeled HHI and top-three share for cloud infrastructure, by year.
YearHHI (modeled)Top-three shareNamed vendors
20171,36653%4
20191,47057%5
20211,62563%4
20221,73967%3
20241,48563%3
20251,42163%3
20261,40963%3

Top-three share rose steadily. HHI peaked and then fell. Both are correct, and they disagree because the leader lost share to the second and third players rather than to the tail: the market became more oligopolistic and less dominated by one firm at the same time. That is the reason the share chart plots both lines, and the reason any single concentration statistic quoted on its own should be distrusted.

One rounding caveat is worth stating: summing Synergy's rounded published shares for 2026 gives a top three of 63%, while Synergy-derived coverage reports 67% on the full definition. The Atlas shows what it can compute from the published per-vendor shares and footnotes the gap rather than silently picking the friendlier number.

The moat rubric

Every company is scored 0–5 on seven axes. The scores are Modeled judgments made in this project, not measurements and not reported figures. The rubric below exists so that you can disagree with a specific number rather than with a vague claim about durability: each company's profile shows its scores next to a one-sentence rationale.

Network effects

0
The product works exactly as well for the first user as for the millionth; no user creates value for another.
1
Users occasionally benefit from others through shared templates or forums, but the product stands alone without them.
2
A same-side community (content, integrations, public examples) makes the product meaningfully better once populated.
3
Cross-side effects exist within a customer: more colleagues on the product raise its value to each of them.
4
Cross-company effects operate, so adoption at one organisation pulls in its suppliers, customers or collaborators.
5
A market-wide two-sided network makes the leading position self-reinforcing and a subscale rival structurally worse for its users.

Switching costs

0
A customer can leave inside a day with no data, workflow or contractual cost.
1
Leaving costs a short export and some retraining; substitutes are drop-in.
2
Accumulated configuration, history and user habit make a move a multi-week project.
3
The product holds the system of record for a business process, so migration is a funded project with real risk.
4
Deep customisation, bespoke integrations and certified administrators make replacement a multi-year programme.
5
The product is embedded in regulated or revenue-critical processes, and replacement risk is treated as existential by the buyer.

Scale economies

0
Unit costs are flat or rising with volume; each new customer costs roughly what the last one did.
1
Modest fixed-cost leverage on R&D, but delivery costs scale nearly linearly.
2
Gross margin improves visibly with volume as R&D and support amortise over more customers.
3
Large fixed investments (data centres, model training, compliance) amortise over a base a subscale rival cannot match.
4
Scale buys materially better input prices or utilisation, so the leader can price below a challenger's cost.
5
Minimum efficient scale is so high that only a handful of firms worldwide can operate at competitive cost.

Data advantage

0
The product generates no proprietary data, or the data has no bearing on product quality.
1
Usage data informs the roadmap but does not make the product itself better for the customer.
2
Aggregate usage data improves defaults, benchmarks or recommendations in a way rivals would need time to match.
3
A proprietary corpus materially improves output quality, and the corpus grows with usage.
4
The data asset is both hard to assemble and legally or practically exclusive, and it compounds with deployment.
5
The feedback loop is the product: quality gains from data are the main reason customers choose the leader over a technically similar rival.

Brand

0
Buyers cannot name the vendor and choose on price or feature checklist alone.
1
The name is recognised inside its niche but carries no pricing power.
2
The brand shortens the sales cycle and appears on shortlists without marketing spend.
3
The brand is the safe institutional choice, so choosing it needs less internal justification than choosing a rival.
4
The brand supports a visible price premium over functionally comparable products.
5
The brand is the category noun, and buyers describe the job using the vendor's name.

Ecosystem

0
No third party builds on, resells or specialises in the product.
1
A handful of integrations exist, mostly built by the vendor itself.
2
An integration marketplace and a small partner community extend the product beyond the vendor's roadmap.
3
A paid developer and consulting economy exists around the product, with certifications and staffing.
4
Third parties run substantial standalone businesses on the platform, and their customers become the platform's customers.
5
The ecosystem is a labour market and a curriculum: skills are taught, hired for and career-defining, which locks in the next generation of buyers.

Regulatory

0
No licence, certification or regulatory clearance is needed to compete.
1
Generic security attestations are expected but obtainable by any funded entrant.
2
Sector certifications take a funded entrant a year or more to obtain.
3
Accreditation, audit history or regulator-facing filings create a multi-year barrier for new entrants.
4
The vendor is named in or certified under regulation, so buyers in the sector face additional risk using an alternative.
5
Regulation effectively enumerates the qualifying vendors, and the incumbent set changes only when the rules do.

The simulator model

Illustrative toy model — not a prediction of any real market. Nothing it outputs is observed in the world, and nothing it outputs is a forecast.

The simulator is a seeded agent-based toy. It starts with five firms holding equal share and a quality score drawn uniformly from 0.8 to 1.2 by a mulberry32 generator, so a given seed always reproduces the same run. Each tick applies five rules:

  1. Attraction. A firm's pull is its quality multiplied by one plus four times the network-strength dial times its current share. The constant 4 is what makes share compound into more share; at a network strength of zero the term vanishes and only quality matters.
  2. Churn. Each firm loses 15% of its share per tick, scaled down by the effective switching cost. At a switching cost of 1 nobody leaves; at 0 the full 15% is up for grabs.
  3. The pool. All churn plus 0.05 of new demand is redistributed across firms in proportion to the softmax of their attraction scores.
  4. Entrants. The entrants-per-tick dial adds new firms at 0.005 share with quality drawn uniformly from 0.7 to 1.4.
  5. Platform shifts. With the shift probability each tick, every incumbent's quality is multiplied by 0.6, one entrant arrives with quality 1.6, and the effective switching cost is halved for the next five ticks. Firms below 0.001 share are pruned and the remainder renormalised; HHI and top-three share are recorded.

Ticks are not years and firms are not companies. There are no prices, no costs, no product categories, no regulators, no capital constraints and no acquisitions. A tick is one round of redistribution and nothing more. Five firms with a quality score are not an industry, and the model has no calibration against any real market in this dataset.

It reports the same two concentration measures as the rest of the Atlas: HHI, the sum of squared percentage-point shares on a 0–10,000 scale, against the 1,800 “highly concentrated” threshold from the US DOJ/FTC 2023 Merger Guidelines, and top-three share in percentage points. Seeing the two diverge here is the same phenomenon documented above for cloud infrastructure.

A known limitation: entrant flow dominates concentration

With the entrants dial at one or more per tick, the softmax spreads new demand almost uniformly across a growing firm population, so the market fragments whatever the other dials say. Mean final HHI is roughly 189 at maximum network strength and switching cost with one entrant per tick, against roughly 164 with both dials at zero — a difference too small to read. At zero entrants the same comparison is roughly 2,525 against 2,020, and the network-strength dial does what the narrative claims it does.

This is a property of the model as specified, not a bug in the implementation, and it is why the default is zero entrants. It is also a fair warning about toy models in general: the parameter that dominates the output is not always the one the argument is about.

Known limitations

  • Share by year barely exists in public. 7 of 55 markets carry a share series. For every other market the data sits in paywalled analyst reports, and reconstructing it from vendor revenue divided by an estimated market size would produce a figure with the appearance of measurement and none of the substance. Those charts show “no reliable public share data” instead. The blank is itself a finding: very little of this industry is actually measured in public.
  • Market sizes are ranges. Analyst definitions differ by two to three times for the same category, so most sizes here are modeled bands rather than point estimates. Comparing two rectangles in the treemap tells you about orders of magnitude, not about percentages.
  • Private AI revenue is run-rate, not revenue. Press-reported “annualised run rate” is the latest month multiplied by twelve. It is not GAAP revenue and it overstates trailing revenue during hyper-growth. Every such figure here is labelled estimated and sourced to the reporting outlet, never to the company.
  • There is no market-cap series. Share price is not in SEC XBRL and no reachable source would have let one be built without fabrication, so the bubble chart never offers market capitalisation as a size metric. It offers gross margin (57 companies) and revenue (69 companies) — the two the dataset can actually support.
  • Gross margin is derived, not filed. Every margin figure is modeled as one minus cost of revenue divided by revenue, both as filed. Five companies were dropped for lack of a clean total-cost-of-revenue tag, and two IBM years were skipped because a spin-off put the two inputs on different bases. AWS has no segment-level margin, so consolidated Amazon margin is used and labelled as such.
  • Some revenue is not software. Revenue is the company total as filed. For 16 companies that total is mostly something else: Amazon includes retail, Nvidia and Apple include hardware, Google and Meta include advertising, Accenture is services. The bubble chart names them under the plot, in the tooltip and in the table. Segment revenue isn't swapped in, because the company, not the segment, is what the chart compares.
  • Revenue in a currency other than dollars is not shown. SAP reports in euros and the unit vocabulary here has no euro member. Converting without a verified period-matched exchange rate would be fabrication, so SAP ships with no revenue series and is a full participant everywhere else. An absent series is better than a quietly wrong axis.
  • Moat scores, signal strengths, flow weights and horizons are judgments. They are modeled, published with their rubric, and meant to be argued with. The emerging-market horizons are the softest numbers in the Atlas: naming the year a category will have an independent vendor above $1B of revenue is a guess with a rubric attached.
  • The emerging set leans towards AI. 12 of the 19 candidate markets are framed around AI. The first research cut was almost all AI, so 7 candidates driven by regulation or falling costs (e-invoicing, health-data APIs, grid flexibility, digital identity, embedded finance, operational resilience, post-quantum cryptography) were added to balance it. Of the 59 signals recorded, 15 are platform shifts, 13 leading indicators, 12 regulation and 6 unbundling.

Updating the data

All data lives in typed TypeScript files under data/ and is parsed by Zod at import time, so a malformed figure fails the build rather than reaching a chart. The loop for changing anything is:

  1. Fetch the source and record it in data/sources.ts with verified: true and its URL. A URL that was not actually fetched may not be added.
  2. Add or edit the data point with its value, year, unit, source id and confidence. A modeled point must carry a note stating the method; a point with a range must satisfy low ≤ value ≤ high.
  3. Log the check — figure, source, what was found, whether it was accepted — in docs/verification-log.md.
  4. Run npm run validate-data, which re-checks referential integrity, the confidence rules and the range rules, then npm run build. Minimum collection volumes are enforced only by npm run validate-data:strict; npm swallows a --strict flag appended to the plain script, so that form runs the lenient checks without saying so.

Disclosure

This Atlas was produced by Claude, an AI model built by Anthropic. Anthropic appears in this dataset as a market participant — in the foundation-model era, in the emerging-market radar and in the competitive events — and that is a conflict of interest worth stating plainly rather than burying.

Three things were done to limit the bias it creates:

  • Every Anthropic figure comes from third-party reporting, never from Anthropic's own materials.
  • Anthropic is scored against the same moat rubric, on the same 0–5 scale, as its competitors, and its scores are visible next to theirs in the comparison tray.
  • The bear case on foundation-model economics — that inference is a real marginal cost and that model labs may not capture the value they create — is stated explicitly in the narrative rather than argued away.

You should still read anything this Atlas says about foundation models with that conflict in mind. The sources are listed below so you can check the claims against them directly.

Sources (192)

The complete registry. Every figure in the Atlas points at one of these ids, every tooltip names the source behind the number it is showing, and every citation chip in the story links straight to its entry here.

Fetched and verified in this project (156)

Cited from the literature (9)

Books, papers and case law. These carry no URL, by design, and never back a reported data point.

  • B01◇ cited from the literatureBook · Secondary · 2003

    From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (M. Campbell-Kelly)

    MIT Press

  • B03◇ cited from the literatureAcademic · Primary · 2002

    Software Unbundling: A Personal Perspective (W. S. Humphrey), IEEE Annals of the History of Computing 24(1)

    IEEE

  • B04◇ cited from the literatureBook · Secondary · 2016

    7 Powers: The Foundations of Business Strategy (H. Helmer)

    Deep Strategy

  • B05◇ cited from the literatureBook · Secondary · 1997

    The Innovator's Dilemma (1997) and The Innovator's Solution (2003), C. M. Christensen

    Harvard Business School Press

  • B06◇ cited from the literatureLegal · Primary · 2001

    United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001)

    US Court of Appeals, D.C. Circuit

  • B07◇ cited from the literatureAcademic · Primary · 2011

    Platform Envelopment (T. Eisenmann, G. Parker, M. Van Alstyne), Strategic Management Journal 32(12)

    Strategic Management Journal

  • B08◇ cited from the literatureAcademic · Secondary · 2015

    Aggregation Theory (B. Thompson)

    Stratechery

  • B09◇ cited from the literatureLegal · Primary · 2023

    Merger Guidelines (2023)

    US Department of Justice and Federal Trade Commission

  • B10◇ cited from the literatureAcademic · Secondary · 2024

    Welcome to LLMflation: LLM inference cost is going down fast (G. Appenzeller)

    Andreessen Horowitz

Retrieved but unread (27)

Real pages, and the links below are real — but their bodies are paywalled or their hosts block automated fetching, so nobody in this project has read the figure inside. The URL is kept so you can try it yourself; every figure resting on one of these ships as estimated, never as reported.