StackSwap · Methodology v1.1.0 · Last reviewed 2026-05-18

How we model 100,000 GTM stacks

Every cited statistic on stackswap.ai — "38% of modeled stacks contained both Outreach and HubSpot," "median annual recoverable: $93,240", "81.66% of stacks have at least one detected overlap" — comes from this simulation. Synthetic stacks, real engine, reproducible code. Here's exactly how it works.

Editorial firewall

How we keep recommendations honest while running on affiliate revenue:

1. Facts are separate from recommendations. Tool facts — price/seat, integrations, contract minimums, data coverage — live in data/tools.json and are sourced and verified independently of any commercial relationship. The facts do not change based on who pays us.
2. Equal-depth coverage for non-affiliates. When we compare or rank tools, non-affiliate competitors get the same word count, the same data depth, and the same fact verification as affiliate partners. ZoomInfo, Outreach, Gong, and Salesforce appear at full depth across our comparison and ranking pages despite having no commercial relationship with us.
3. Affiliate signal only breaks ties. When the recommendation engine returns a ranked list for a buyer profile, fit is the primary score — cost-effectiveness, integration depth, stack compatibility, AI-readiness. Affiliate status can break ties between equivalent-fit tools but never moves an unfit tool above a fit one.
4. We turn down partners. See Carveouts below for tools and categories we have actively declined to recommend or take money to promote. The list is reviewed quarterly.
5. Affiliate links are labeled inline. Every partner link carries a sponsored label and a disclosure on the page where it appears, at no extra cost to the buyer.

If you ever see a recommendation that looks affiliate-weighted rather than fit-weighted, email nick@stackswap.ai with the page URL. We treat that as a trust bug and triage it the same day.

Tool fact corpus

Per-tool facts — price/seat, integrations, contract structure, data coverage — live in data/tools.json. Where they come from and how they stay current:

• Public sources by default. Vendor pricing pages, public documentation, earnings calls (for public companies), Reddit threads, support-ticket discussions, and G2/Capterra review excerpts cited inline. We do not bulk-scrape review sites.
• Vendor fact sheets for affiliate partners. Partners can submit structured fact sheets covering pricing, integration matrices, and contract terms. The submission format is published as a public JSON Schema spec: GTM Decision Schema v1.0.0 (draft 2020-12). Vendor-submitted facts are tagged submitted_by: vendor with a verification date and an attestation. Non-partners are represented from public sources only and are not penalized in recommendations for not paying.
• Conflict resolution: surface both. When vendor-claimed pricing or features conflict with user-reported reality (Reddit discussions, support tickets, our own scan data), we surface both with attribution. We do not silently take the vendor's word.
• Verification cadence. Current state: pricing and feature facts are verified ad-hoc when we write or update content about a tool, and at minimum quarterly. Target state: automated monthly pricing verification with per-tool “last verified” stamps. Material vendor changes (new pricing model, acquisition, product retirement) trigger ad-hoc updates within 7 days of public disclosure.
• Flag stale data. If you see a pricing or feature claim on a per-tool page that you know is outdated, email nick@stackswap.ai with the page URL and the correction. We update within 7 days of verified flags.

Carveouts

Tools and categories we have actively declined to recommend or take money to promote. Reviewed quarterly — if something moves off this list, we explain why in the methodology change log.

• Hyperbound — listed in our tool directory for completeness, but not promoted in ranked lists or spokes. They do not run an affiliate program, and we do not write promotional content for tools where we cannot be transparent about compensation. Revisit ~Q4 2026.
• Tools whose core motion is deceptive email capture — exit-intent popups, fake lead-magnet bait, drip sequences without explicit opt-in. We will happily cover tools that send email with the recipient's well-disclosed consent. We will not promote tools whose growth depends on dark patterns, even when affiliate economics are offered.
• The “cold-email-at-scale” spam category — we will write about specific tools in this space (buyers need to understand the landscape, and legitimate use cases exist), but we do not take promotional money to recommend “send 10x more cold emails” plays.
• Review-site arbitrage plays — affiliate networks built on inflated review counts or astroturfed comparisons. If we cannot independently verify a tool's claims against public sources, we do not take their money.

If you are a vendor who thinks we have represented you unfairly, or a buyer who thinks a tool we recommend belongs on this list instead, email nick@stackswap.ai with specifics. Every flag gets a real answer, not a form reply.

The pipeline

Three steps, all deterministic from a fixed seed:

1. Generate. A seeded RNG (Mulberry32) picks an archetype weighted by realistic operator distribution, samples team headcount within that archetype's range, picks an industry, then assembles a tool list from the archetype's core tools, common additions (probabilistic), optional additions (probabilistic), and legacy drift (probabilistic). Every tool name is validated against TOOL_LIST at script start.
2. Score. Each generated stack is passed to scanStack(input) — the same pure function that powers /stackscan. No HTTP, no DB. Output: current spend, optimized spend, per-tool verdicts, modeled recovery, overlap pairs detected, AI readiness scores, and tier pricing.
3. Aggregate. Across all 100,000 runs we compute: tool prevalence (% of stacks containing each tool), overlap-pair prevalence + recovery distributions (median, p25/p75/p95), team-size-bucketed recovery medians, and headline summary stats. The result writes to data/stack-simulation/aggregates.json — committed in the repo, ~25KB. Raw per-stack CSV (~18MB) writes to simulations/ which is gitignored.

The 12 archetypes

Weights sum to 1.0. Distribution reflects estimated operator population prevalence — not even-split. Tools assigned to each archetype are sourced from realistic patterns we observe in the GTM operator community.

What the engine produces

From the current run (SIM_SEED=42 npm run simulate:100k):

• 81.66% of modeled stacks contained at least one detected overlap pair.
• Median monthly recoverable per stack: $7,770 (annual: $93,240).
• Distribution: p25 $280/mo · p75 $21,321/mo · p95 $119,236/mo.
• Median current monthly stack spend: $20,700.
• Median overlap-pair count per stack: 2.

How the AI-native score works

The AI-native score (0–100) estimates how ready a stack is to participate in AI and automation workflows — agent orchestration, data piping, programmatic triggers. It is a capability model, scored from each tool's documented integration surface (public API, automation hooks, data access, native AI) — not a measure of how heavily a given team actually uses those capabilities. It is deterministic: the same stack always scores the same. Source: lib/ai-readiness.ts.

Each tool gets four sub-scores (0–100), combined with fixed weights:

Within each dimension a tool lands on a tier, so the numbers fall out of capability rather than being hand-set per tool: a legacy tool (one we carry an AI-native swap for) scores low across the board (~20–30), a tool with a strong public API scores 90 on the API axis, and an AI-native tool scores 95 on the AI axis.

Worked example. A legacy tool scores about 26: API 25, automation 30, data 25, AI-native 20, blended as 25·0.3 + 30·0.3 + 25·0.2 + 20·0.2. An AI-native tool scores about 85 (API 85, automation 80, data 82, AI-native 95). The stack score is just the average of its tools' scores — which is why replacing two legacy tools with AI-native ones can swing the headline 30+ points: you pull ~26s out of the average and drop ~85s in.

The projected score on a StackScan report is that same average recomputed after the recommended swaps are applied — legacy tools removed, replacements added. Four classification bands:

Honest limitation. This scores capability, not adoption. A tool with a great API still scores 90 on that axis even if your team has never connected it — the score tells you what is possible with the stack, not what you have wired up. Read it as a ceiling on AI and automation leverage, not a usage report.

Top citable findings

• 81.66% of modeled stacks contained at least one overlap pair flagged by the engine.
• Median annual recoverable across 100k modeled stacks: $93,240.
• 29.97% of modeled stacks contained both HubSpot Marketing Hub and Salesforce; median modeled annual recovery from consolidating: $1,800.
• 23.79% of modeled stacks contained both Clari and Gong; median modeled annual recovery from consolidating: $1,200.
• 20.49% of modeled stacks contained both Apollo.io and ZoomInfo; median modeled annual recovery from consolidating: $2,400.
• 18.74% of modeled stacks contained both Outreach and Salesloft; median modeled annual recovery from consolidating: $1,200.
• 17.75% of modeled stacks contained both Apollo.io and Outreach; median modeled annual recovery from consolidating: $1,200.

Tool prevalence and engine verdicts

Top 20 tools by prevalence across 100,000 modeled stacks. Replace rate = % of stacks containing that tool where the engine flagged a replacement candidate (e.g. Apollo for Outreach). Remove rate = % where another tool already in the stack made it redundant.

Most prevalent redundant pairs

The 15 overlap pairs that show up most often across the modeled population. Recovery values are deterministic per pair (see limitations) — consider them modeled annual upper bounds for the consolidation move.

Highest-value consolidation opportunities

Top 10 overlap pairs by modeled annual recovery, ranked by dollars. Less prevalent than the list above, but higher-impact when present.

Recoverable spend by team size

Median modeled monthly waste scales sharply with headcount. The biggest single jump is 6–15 to 16–25 — the inflection point where stack drift starts costing real money. Useful framing for “when to audit your stack” conversations.

Independent validation

Modeled stacks are how StackSwap measures the patterns. The State of GTM Engineering 2026 (OneGTM, n=228) is how the operators in those stacks describe themselves. The numbers below are theirs — included here to show that the things our engine scores for (overlap, consolidation, AI-readiness, fit-for-stage) match what the audience actually says they need.

Honest limitations

1. Synthetic, not empirical. These are modeled stacks, not real customer scans. We're explicit about that everywhere the data is cited. Pre-revenue means no customer base; we'd rather model honestly than fabricate a customer count.
2. Slack at 100% prevalence. Every archetype includes Slack as a core tool, so it shows up in 100% of stacks — that's an over-representation we know about. Doesn't affect overlap-pair statistics but inflates Slack's prevalence number.
3. Operator-judged weights. The 12 archetype weights are estimated from operator pattern recognition, not external market research. We could be off by 5-10 percentage points on any given archetype's real-world prevalence.
4. Deterministic recovery values. Each overlap pair has a fixed modeled annual recovery from the OVERLAPS table (e.g. Apollo+ZoomInfo = $2,400/yr modeled recovery, every detection). The p25-p75 tightness in our distributions reflects this engine determinism, not bug.
5. No business-context override. The engine flags overlap based on capability redundancy. In practice some teams run both tools for legitimate reasons (regulated industry, post-acquisition transition, specific motion). The modeled recovery is the upper bound, not the recommended action.

Reproducibility contract

Same seed (SIM_SEED=42) + same archetype templates + same engine version = bit-identical aggregates.json. Anyone can verify the cited statistics by running the script themselves. The methodology_version field bumps when:

• The scoring engine logic changes (new overlap pairs, updated cost modeling, etc.)
• Archetype templates are added, removed, or rebalanced
• Aggregation logic changes (new metrics, different percentile cutoffs)

When the version bumps, all content pages automatically pick up the new numbers on next deploy — the citation helpers in lib/stack-simulation/citations.ts always read the latest aggregates.

How to cite this dataset

Journalists and researchers are welcome to cite these statistics. Below are ready-to-paste citation formats. Please link back to this page so readers can verify the methodology.

Short citation (inline)

Source: StackSwap, "100,000 GTM Stack Simulation" (methodology v1.1.0, https://stackswap.ai/methodology).

Long citation (academic / report style)

StackSwap. (2026). 100,000 GTM Stack Simulation: Modeled tool prevalence, overlap, and recoverable spend across 12 operator archetypes (methodology v1.1.0, seed 42). Retrieved from https://stackswap.ai/methodology.

Example sentences (for journalists / writers)

• “According to a 100,000-stack simulation by StackSwap, 81.66% of B2B SaaS GTM stacks contain at least one redundant tool pair.”
• “StackSwap's modeled dataset of 100,000 synthetic GTM stacks puts the median annual recoverable spend at $93,240 per company.”
• “A modeled analysis of 100,000 GTM configurations found that [Tool A] and [Tool B] appear together in [X]% of stacks — see stackswap.ai/methodology for the full table.”

Pre-built citation helpers for every overlap pair and tool are available in lib/stack-simulation/citations.ts — citationForOverlapPair() and citationForToolPrevalence() return formatted sentences for any tool or pair in the dataset.

Source

• Simulator script: scripts/simulate-stacks-100k.ts
• Scoring engine: lib/scanStack.ts (same function powers /stackscan)
• Citation helpers: lib/stack-simulation/citations.ts
• Output dataset: data/stack-simulation/aggregates.json (committed)
• Tool universe: data/tools.json

Related

• Methodology change log (versioned record of edits to this page, the simulation engine, and the GTM Decision Schema)
• GTM Decision Schema v1.0.0 (JSON Schema spec for vendor fact sheets)
• 90-day consolidation runbook (uses these statistics)
• Are you wasting money on Outreach? (cites Outreach prevalence + overlap stats)
• Are you wasting money on Apollo? (cites Apollo + ZoomInfo overlap)
• All tool overlap pairs (per-pair pages)
• GTM tools directory (every tool reviewed)

Canonical URL: https://stackswap.ai/methodology
Generated at: 2026-06-02T01:48:55.367Z