Every guide tells you to build the model bottom up, then leaves the two hardest inputs blank. Here is the method with real company counts, real revenue distributions and real exit prices filled in.
Every founder gets asked how big the market is. Almost every answer is a guess wearing a suit. The standard advice is to build TAM, SAM and SOM from the bottom up, which is correct, and then the advice stops precisely where the difficulty starts. You are told to multiply customer count by revenue per customer. Nobody tells you where either number comes from.
We looked at what currently ranks for this question. The top-ranking guides are structurally competent and evidentially empty. One of them walks through a full worked example for compliance software sold to independent coffee shops, complete with a $12 billion TAM, an $84 million SAM and a $2.88 million SOM. Every one of those numbers is invented for the example. The customer count is unsourced, the annual spend figure is unsourced, and the capture rate is asserted. It is a well-written demonstration of arithmetic, not of a market.
This page takes the opposite approach. Every number below comes from a live query against real companies, real revenue and real transaction prices, run on August 31, 2026, and every table says where it came from and what it cannot tell you. The method is the same four steps everyone teaches. The difference is that the blanks are filled in.
A top-down TAM is produced by taking a published industry figure and narrowing it. The problem is not the arithmetic, it is that the starting figure was assembled for a different purpose. Industry reports bundle together enterprise licences and self-serve subscriptions, services revenue and software revenue, geographies you will never enter and buyer sizes you cannot support. Narrowing a number that was wrong in kind does not make it right in degree.
The failure shows up in the most-cited startup post-mortem research. CB Insights found that no market need is the single most common reason startups fail, cited in 42% of post-mortems. Those companies did not skip market sizing. Most of them had a slide. The slide was simply describing a market that existed in a report rather than one that existed in people's budgets.
There is a second, quieter failure. A top-down number cannot be wrong in a way you would notice. If you claim a $12 billion category and the truth is $8 billion, nothing in your business changes and no test catches it. A bottom-up number built from a countable population fails loudly: you go looking for the 35,000 businesses and find 4,000, or you find them and discover they buy through a franchisor. That is the entire value of building from the bottom. It is falsifiable.
If you want the broader failure context first, our breakdown of startup failure statistics and the companion piece on why startups fail both cover how often the market, rather than the product, is the thing that was misjudged.
Read any bottom-up market-sizing guide closely and you will find the same sentence: multiply your target customer count by your average revenue per customer. Then read the worked example and watch where the revenue figure comes from. It comes from the author's imagination, or from the founder's own intended price page, which is the same thing with extra steps.
Your intended price is not evidence. It is a hypothesis, and it is usually the most optimistic hypothesis in the model, because founders price for the customer they want rather than the customer they will get. The honest input is what comparable products actually earn today. That number exists, it is just rarely published, because most people writing about market sizing do not have a revenue corpus to query.
Here is the distribution across the revenue-reporting startups in our revenue intelligence corpus. This is the shape that your bottom-up model is implicitly making a claim about, whether or not you have looked at it.
| Percentile | Monthly recurring revenue | What it means for your model |
|---|---|---|
| 25th | $29 | A quarter of products that charge anything earn under $29 a month |
| 50th (median) | $145 | The honest default ARPU anchor for a new entrant |
| 75th | $894 | A good year-two outcome, not a year-one plan |
| 90th | $5,107 | Ceiling scenario. Use for upside cases only |
| 99th | $58,404 | The companies that produce every category average |
| Mean | $4,298 | Roughly 30x the median. Never use this number |
Three thresholds matter more than the percentiles themselves. Of the 3,700+ startups reporting revenue, 23.6% ever clear $1,000 MRR, 6.1% clear $10,000 MRR, and 25 companies clear $1M ARR. That last figure is 0.66%. When a plan projects $1M ARR in year three, it is projecting an outcome that fewer than one in a hundred comparable companies reach, which may still be the right plan but should be stated as the ambitious claim it is rather than as a base case.
Revenue per customer also varies far more by category than most models assume. The spread below is more than 7x from top to bottom, which means the same customer count produces wildly different market sizes depending on what you are selling.
| Category | Companies reporting revenue | Median MRR | 90th percentile MRR | Share over $1K MRR |
|---|---|---|---|---|
| Sales | 38 | $640 | $14,463 | 42.1% |
| Marketing | 213 | $276 | $10,495 | 28.6% |
| Education | 175 | $208 | $4,000 | 26.3% |
| Artificial Intelligence | 941 | $203 | $5,005 | 25.3% |
| SaaS (general) | 353 | $156 | $6,398 | 25.8% |
| Mobile Apps | 305 | $143 | $3,847 | 22.3% |
| Design Tools | 77 | $124 | $3,197 | 18.2% |
| Health & Fitness | 190 | $101 | $2,453 | 20.5% |
| Fintech | 98 | $83 | $1,183 | 13.3% |
Sales tooling earns roughly 7.7x what fintech earns at the median, which is a statement about who holds the budget rather than about which product is better. Our fuller SaaS revenue benchmarks by category break this down further, and the state of indie SaaS revenue covers how the distribution has moved.
The framework is unchanged from what everyone teaches. What follows is each step paired with the data source that answers it, so that the output is a number you could be wrong about in public rather than a number that cannot be checked.
The most common counting error is to count businesses rather than buyers. There may be hundreds of thousands of independent restaurants in a country, and it is irrelevant if the ones you can reach do not buy software at all. What you want is a population of businesses with demonstrated commercial infrastructure.
Our Stripe Index exists for exactly this. It holds 30,000+ companies that appear on Stripe's public directory, which means each one has taken payment for something. That is a much harder qualification than existing. The directory sorts into 83 active categories, and the counts per category are the closest thing to a defensible bottom-up buyer population that we know how to assemble. You can browse the same underlying set of companies using Stripe directly.
Two caveats to state up front, because they bound the method. First, this is a directory of companies that opted into visibility, so it undercounts. Second, it is skewed toward businesses that sell online, so a category that transacts mostly offline will look smaller here than it is. Both push in the same direction: treat these counts as a floor on the buyer population, never as a total.
This is the step that most guides skip entirely, and it is the one that changes decisions. Two categories with the same number of companies can be completely different markets depending on how many of those companies are already served by small, modern software rather than by enterprise suites, spreadsheets or nothing at all.
| Category | Companies | Small-software companies | Density | Read |
|---|---|---|---|---|
| Ecommerce Platforms | 3,452 | 29 | 0.8% | Huge buyer pool, almost no small tooling |
| Scheduling & Booking | 2,096 | 104 | 5.0% | Large and partially served |
| Consulting | 1,496 | 13 | 0.9% | Service-heavy, tooling-light |
| Education & e-Learning | 1,278 | 127 | 9.9% | Healthy density, real competition |
| Home Services & Trades | 963 | 4 | 0.4% | Lowest density with real commercial volume |
| AI Tools & Apps | 955 | 331 | 34.7% | Saturated with small entrants |
| Nonprofit & Fundraising | 647 | 1 | 0.2% | Nearly empty, but budget-constrained |
| Invoicing & Billing | 495 | 67 | 13.5% | Small but crowded |
| Workflow Automation | 422 | 46 | 10.9% | Crowded, and 137 companies are AI-native |
Read the first and last rows together. Ecommerce Platforms has 3.6 times as many companies as AI Tools and roughly one fortieth of the small-software density. If you sized both markets by company count alone you would pick the wrong one. This density metric is the core idea behind our work on SaaS market saturation, and the same lens drives boring industries begging for micro SaaS and low competition SaaS ideas.
Take the median for your category from the benchmark table above, not the mean and not your price page. Then apply two adjustments, both downward by default.
The first is segment. If you are selling to the smaller end of a category, your realised revenue per customer will land below the category median, because the median includes products that sell to teams. The second is time. Revenue per customer at the start of a business is lower than the steady state, because early customers arrive on introductory pricing and early products lack the seats and add-ons that lift the number later. A model that applies steady-state ARPU to year one is overstating year one.
If you want to pressure-test a specific price point rather than a category median, our guide on SaaS pricing strategies and the help page on how to price a micro SaaS both cover how to test willingness to pay before you commit the number to a model.
The lazy version of this step is to write 1% of SAM. It is lazy because it is not derived from anything, and it is usually wrong in both directions at once: too high for a founder with no distribution, too low for a founder who owns a channel.
Build it from reachable customers instead. How many of the buyer population can you actually put your product in front of in twelve months, through the specific channels you have, and what conversion rate have you observed rather than assumed? Multiply those. Then check the result against the revenue distribution: if the plan implies you are in the top quartile of comparable companies by month twelve, you have not built a conservative case.
This is also where competition enters honestly. An existing competitor is not a reason to abandon a market, it is evidence the market pays. What competition changes is your capture rate, not your market size. Our piece on the state of micro SaaS competition covers how to judge contestability, and how to do competitor analysis for SaaS walks the practical version.
Run the four steps on the lowest-density category in the table, using only figures published on this page.
Step 1, count. Home Services and Trades holds 963 companies with live payment processing in our directory. Because a public directory undercounts and this category transacts heavily offline, treat 963 as a floor rather than the population. The honest statement is: at least 960+ reachable, payment-taking businesses, almost certainly many multiples more.
Step 2, density. Four of those companies classify as small software, a density of roughly 0.4%. This is the lowest of any category in our directory that has real commercial volume. Interpret that carefully: it means small software is nearly absent, not that software is absent. Large field-service suites serve this market and serve it in a way the operators complain about, which is a different and better opening.
Step 3, ARPU. There is no direct home-services row in our revenue benchmarks, so use the general SaaS median of $156 MRR as the anchor and note the substitution rather than hiding it. Trades buyers are businesses rather than consumers, which argues for the higher end, so a defensible band is $150 to $300 MRR with $156 as the base case.
Step 4, capture. Suppose your distribution is one trade association newsletter and direct outreach, and you can credibly reach 400 operators in year one at a 5% conversion. That is 20 customers. At $156 MRR that is $3,120 MRR by month twelve, which places you above the 75th percentile of everything we measure. The market is not the constraint here. Distribution is.
Run the same steps on AI Tools and Apps and the shape inverts. The category holds 955 companies, of which 331 classify as small software and 153 are AI-native, giving a density near 34.7%. Median MRR for artificial intelligence products in our revenue data is $203 across 941 revenue-reporting companies, which is healthy, and 25.3% of them clear $1,000 MRR.
So the market pays better and is far more crowded. The capture rate is where the difference lands. In a category with 331 small competitors, the marginal cost of attention is high and your realistic conversion on cold reach is a fraction of what it would be in a category with four. Same framework, opposite conclusion, and neither conclusion was visible from company count alone.
For the wider picture on where AI-native products are clustering, see AI SaaS ideas and vertical AI SaaS ideas.
Low density is a signal, not a verdict. Some categories are empty because nobody has built there yet, and some are empty because the market has already answered and the answer was no. The difference is visible in the buyer population.
Compare two low-density rows. Home Services and Trades has 963 payment-taking companies at 0.4% density. Nonprofit and Fundraising has 647 companies at 0.2% density. On density alone they look similar. They are not: nonprofit budgets are structurally constrained in a way trade businesses are not, so the same emptiness means opportunity in one and a warning in the other. Emptiness plus evident budget is opportunity. Emptiness plus absent budget is a graveyard.
The practical test is to look for what the market buys instead. If a category has no small software but heavy spend on manual labour, agencies or enterprise suites, the budget exists and is simply going elsewhere. If a category has no small software and no spend of any kind, you have found a preference, not a gap.
There is a third kind of emptiness, which is a market that is structurally hard rather than merely unserved. These leave a recognisable trace in the complaint record:
"This has been the toughest part, so any advice on trust-building is appreciated. How to build trust before liquidity. Balancing supply and demand early." – r/EntrepreneurRideAlong
"Payouts were paused. Single point of failure. If you rebuild, architect payment resilience as a core feature and have backups ready." – r/microsaas
Marketplaces are the classic example. The category can look wide open while the reason it is open is a cold-start problem that has defeated everyone who tried. Emptiness is a question, and the complaint record usually contains the answer if you read enough of it.
Sometimes there is no comparable product to count, because you are early. Demand can still be measured, just not in dollars. It can be measured in documented complaints, which is the approach behind our entire pain points database: 1M+ data points drawn from review platforms, app stores and public forums.
Feature requests are the sharpest form of this, because a request is a complaint with a specification attached. Across the 40,000+ feature gap records we hold from review platforms, the concentration is striking.
| Requested capability | Requests | Share rated high demand |
|---|---|---|
| Reporting | 2,899 | 69.5% |
| User experience | 2,477 | 37.1% |
| Integration | 1,671 | 51.6% |
| Analytics | 1,393 | 54.6% |
| Data management | 660 | 55.3% |
| Financial management | 376 | 58.8% |
Reporting is both the most requested capability and the most intensely requested, at 69.5% high demand. That is a market signal available before a single competitor exists in your specific niche. People describing the gap in their own words:
"Monitoring performance metrics, comparing channel effectiveness, and generating client reports was an absolute nightmare of scattered data." – r/automation
"I cut weekly ad reporting from 4 min to 30 sec. Every week your manager or client asks how CPC and CPA are trending across Google, Meta, LinkedIn, Reddit. Then you open 12 tabs, export CSVs, and wrestle VLOOKUPs." – r/remotejobs
"I have been really overwhelmed with how many notifications are flying in from all sides. Slack, Gmail, Jira, Asana, Teams. It is like I am jumping between 5 tabs just to catch up, and somehow I still miss stuff." – r/managers
Each of those is a workaround description, which is the most valuable kind of demand evidence because it quantifies the pain in units the speaker chose. Twelve tabs. Four minutes a week. Five tabs and still missing things.
The sharpest version states the missing product outright, which is a market of one person telling you the specification:
"Refinancing is confusing. Rates, terms, fees. It is hard to know if it is really beneficial for me. Wish there was an app that could analyze my mortgage and tell me if refinancing now saves me money without all the jargon." – r/consumerfinance
"I need something that feels like a product customizer, but with minimum order quantity and volume pricing baked in. Getting all of that working together usually means mixing several apps with some custom code." – r/wix
"After looking at over 100,000 job descriptions I found specific phrases that reliably indicate a company is actively evaluating solutions." – r/salesdevelopment
That last one is a demand signal about demand signals, and it is worth noting for a structural reason: the person built their own detection method by hand because no product supplied it. Manual construction of a data pipeline is the enterprise equivalent of a spreadsheet workaround, and it counts.
"I am trying to validate an idea I had recently. I want to scrape the internet, review sites, app stores, social media, to find what users think of your solution." – r/EntrepreneurRideAlong
Our guides on business pain points and finding SaaS ideas from real user pain points cover how to convert these into candidate products.
Market size is meaningless without willingness to pay, and willingness to pay is observable in language. Across the 99,000+ negative app reviews we hold, 12.70% mention subscriptions, charges, refunds or paywalls, which is the single largest complaint theme, ahead of stability at 6.42% and usability at 2.34%. People argue about money more than they argue about bugs.
The most useful reviews are the ones that state a price structure preference unprompted:
"Just another app that forces poor people to subscribe after 2 meds added. I would pay a one off price, no subscription for full access. Subscriptions target people who struggle with memory and organisation." – App Store review
"I used the free version for years. They decided to make it a paid service without giving any warning, now my inventory is locked up with no way to retrieve it. I would pay except they are 2 different apps." – App Store review
"This rating is for the free version. The ads are so intrusive as to render it useless. Not sure why I would pay for an app by people who thought this was a good idea." – App Store review
Three people volunteering the exact conditions under which they would hand over money. That is a pricing input, and it is more reliable than a survey answer because nobody was asking.
"We need a hands-free experience for my team and cannot afford additional staff. It is not easy to configure, so we need to hire an AI specialist just for configuration and maintenance purposes." – r/automation
That last one is the strongest form: a business describing a budget it is already spending on a workaround. A market where buyers are hiring people to compensate for missing software has a demonstrated budget line, which is exactly what you want your ARPU anchor to displace.
Two more, showing the range of what a paying customer will tolerate before they go looking:
"Wish there was a way to change temperature readings for the US. I hate having to always go from the app to the internet to get my current temperature." – App Store review
"Honestly I never write reviews, but they messed up my insurance and will not take any credit. I keep having to go back and forth with the team." – App Store review
The second is the more valuable of the two for sizing purposes. A person who never writes reviews wrote one, which is a severity marker you cannot get from a survey, and the phrase back and forth is a repeated-cost description rather than a one-time complaint.
Freelance demand is one of the cleanest proxies for software demand, because every recurring freelance task is a manual process somebody pays for on a schedule. If a task appears repeatedly as paid work, the budget for solving it exists today.
The pattern across the freelance job pain points we track is almost monotonous, and that is the point. The recurring themes are time-consuming manual rendering, error-prone lead generation, inefficient appointment scheduling, manual product listing management, time-consuming presentation design, error-prone bookkeeping and reconciliation, inefficient inventory management, and manual proofreading. Nearly every entry contains either the phrase manual or the phrase error-prone.
"I am trying mailing local gyms, beauty shops and clinics, but I do not know where else I can get customers. How does one get such clients at the beginning?" – r/freelancers
"I kept getting rejected from AI transcription work until I realized this mistake. A lot of people quit gigs thinking it is skill when really it is rubric rules." – r/remotework
"Is there any app or website that posts temporary weekend jobs? I need something with flexible hours but variable availability, and the usual part-time jobs will not hire me." – r/sidehustle
Read those as population evidence rather than product evidence. Each one describes a person already spending time in a market, which is what you are trying to count, and none of them describes a person ready to pay, which is what you still have to establish.
One caveat we state every time this data appears: the budget and hourly-rate columns in that dataset are effectively unpopulated, so we never quote dollar figures from freelance listings. Use frequency as the signal and nothing else. Our piece on validating SaaS demand with Upwork jobs and the state of freelance demand both work this angle properly.
There is one more countable demand signal that almost nobody uses in market sizing: recorded switching between products. We hold 29,000+ competitive pairs derived from review text, each capturing that a reviewer moved to or from a named product.
| Incumbent | Mentions of switching away | Mentions of switching to | Ratio |
|---|---|---|---|
| HubSpot | 1,326 | 611 | 2.2 : 1 |
| QuickBooks | 1,137 | 579 | 2.0 : 1 |
| Salesforce | 948 | 401 | 2.4 : 1 |
| Asana | 907 | 446 | 2.0 : 1 |
| Mailchimp | 735 | 362 | 2.0 : 1 |
| Zendesk | 714 | 332 | 2.2 : 1 |
A market where customers are visibly in motion is easier to enter than a static one of the same size, because you are competing for people who have already decided to leave rather than for people who have to be dislodged. Read these ratios as evidence of churn pressure in a category, not as market share.
"Competitors ripping off products. Like literally using my product images as if it is their own." – r/dropshipping
"I have heard how great this can be and want to try it out. Is there a realistic expectation of how much I should plan on spending for marketing and ad campaigns each month?" – r/dropshipping
Both quotes describe the same underlying condition from opposite ends: a market with low differentiation and rising customer acquisition cost. When you see that pair in a category, adjust your capture rate down rather than your market size, because the room is still the same size and it has become more expensive to cross.
A market size claim implies an achievable company. The cheapest way to test whether that implication is plausible is to look at what companies in adjacent markets actually change hands for. Our acquisition listings database holds 650+ live listings with asking prices and trailing revenue attached.
| Category | Listings | Median asking price | Avg revenue multiple | Avg profit multiple |
|---|---|---|---|---|
| SaaS | 291 | $197,400 | 2.6x | 10.6x |
| Mobile | 86 | $102,500 | 2.6x | 5.1x |
| Agency | 68 | $292,500 | 1.4x | 3.0x |
| Ecommerce | 56 | $97,500 | 1.2x | 5.5x |
| Shopify App | 29 | $250,000 | 3.4x | 4.4x |
| AI | 28 | $192,500 | 2.9x | 5.4x |
The median SaaS business on the market asks under $200,000. That is the actual centre of gravity of the software economy, and it sits a long way from the framing in most market-sizing advice. If your model implies a business worth twenty times the median asking price in your category, the model needs a reason, and the reason should be written down. Our SaaS valuation multiples and profit multiples by SaaS category go deeper, and using acquisition listings as market validation explains the workflow.
Funding patterns will not tell you whether a market is good, but they will tell you where competition for attention is about to intensify. Across the 17,000+ funded companies we track, momentum scores separate the categories cleanly.
| Category | Companies | Avg momentum | Avg investment attractiveness |
|---|---|---|---|
| B2B SaaS | 4,235 | 5.1 | 6.1 |
| Consumer | 2,864 | 4.3 | 5.0 |
| Fintech | 2,265 | 5.3 | 6.4 |
| Healthcare | 2,008 | 5.0 | 6.4 |
| AI infrastructure | 1,754 | 5.4 | 6.6 |
| Developer tools | 1,369 | 5.4 | 6.6 |
Consumer sits lowest on both measures, which is a useful corrective if your market-size model assumes consumer scale economics. For where capital is currently flowing see what VCs are funding, startup funding trends and the funded startups database.
Almost all published market-sizing advice is written for one audience: founders preparing to raise venture capital. That advice optimises for a specific constraint, namely that a fund needs outcomes large enough to return it, which forces a preference for enormous categories. Y Combinator's own library is consistent on the point that founders should build these estimates from the ground up rather than from reports.
If you are not raising, that constraint does not apply to you, and importing it will make you reject good markets. The bootstrapper version of the question is narrower and easier to answer: does the reachable slice, at honest ARPU, clear my number? A market supporting 300 customers at $80 per month is $288,000 a year. No fund will look at it. It is also a better outcome than the overwhelming majority of venture-backed attempts, and it sits above the 90th percentile of everything in our revenue corpus.
Our writing on getting to the first $1K MRR and solo developer revenue examples takes the bootstrapper framing seriously, and how fast SaaS startups actually grow gives the timeline honestly.
Using the mean instead of the median. In our corpus that single choice inflates revenue per customer by roughly 30x.
Counting businesses instead of buyers. Existence is not a qualification. Payment infrastructure is.
Sizing by company count and ignoring density. The category with the most companies in our directory has one of the lowest small-software densities. Count alone would send you the wrong way.
Using your own price page as the ARPU input. It is a hypothesis, and the most optimistic one in the model.
Writing 1% of SAM as the capture rate. Derive it from reachable channels, then sanity-check it against the revenue distribution.
Treating an empty category as automatically good. Empty plus visible budget is opportunity. Empty with no spend of any kind is a preference the market has already expressed.
Publishing a number with no date. Competitor counts and prevailing prices move. Every figure on this page carries the date it was queried, and yours should too.
Fill this in with your own numbers. Every row names the source you should pull it from rather than leaving it to invention.
| Input | Where to get it | Default if unknown |
|---|---|---|
| Buyer population | Count of payment-taking companies in your category | Treat any directory count as a floor |
| Software density | Small-software share of that category | Assume higher than it looks |
| Revenue per customer | Median MRR of comparable products | $145, the all-category median |
| Reachable customers, year one | Your actual channels, counted | Do not default this. Count it |
| Conversion rate | Observed, from a real campaign | Do not default this either |
| Plausibility check | Revenue percentile the plan implies | Above the 75th percentile means ambitious |
| Upper bound | Median asking price in your category | $197,400 for SaaS |
Size a market without assembling the data yourself. BigIdeasDB holds 1M+ documented complaints, 30,000+ payment-taking companies, revenue for 3,700+ startups and 650+ live acquisition listings in one place, so the counting steps above take minutes rather than weeks.
Check a market against the data →Every figure on this page was queried on August 31, 2026. Here is what each source is, and what it cannot tell you.
| Source | Scale | Evidence type | Limitation |
|---|---|---|---|
| Stripe Index | 30,000+ companies, 83 categories | Verified payment activity | Opt-in directory, so it undercounts. Skewed toward online sellers. Small-software classification is model-assisted |
| Revenue intelligence | 8,600+ startups, 3,700+ reporting revenue | Self-published revenue | Founders opt in to reporting, so absence is not zero and the sample skews toward products willing to disclose |
| Acquisition listings | 650+ live listings | Asking prices with trailing revenue | Asks, not closes. Real transaction prices are lower, so multiples are an upper bound |
| Funded company database | 17,000+ companies | Model-scored public signals | Scores are comparative not absolute. Funding amounts are not reliably populated and are never cited |
| Review-platform pain points | 39,000+ records | Written complaints with severity | Reviewers skew toward the unhappy. Volume reflects category popularity as much as category pain |
| Feature gap records | 40,000+ requests | Explicit unmet requests | Demand intensity is model-assigned from review text, not verified purchase intent |
| Competitive switch pairs | 29,000+ pairs | Stated migrations in reviews | Mentions, not contracts. Directional churn pressure only, never market share |
| App store reviews | 99,000+ negative reviews | Consumer complaint language | Consumer behaviour does not transfer cleanly to business buyers |
| Forum pain points | 2,300+ records across 180+ communities | Unprompted first-person accounts | Community composition is not a representative sample of any market |
| Freelance demand | Job pain points by category | Paid manual work as a demand proxy | Budget and rate fields are unpopulated, so no dollar figures are ever quoted from it |
It cannot tell you whether you will win. Market size is a statement about the size of a room, not about your ability to cross it. Every category in the density table has companies succeeding and failing in it simultaneously.
It cannot price your product. It can bound the price, by showing what comparable products sustain, but the specific number comes from tests with real buyers.
It cannot see markets that transact invisibly. Our counts come from companies with public payment profiles and public review histories. A market conducted entirely through relationships, procurement portals or offline invoicing will be systematically undercounted here, and in several cases that undercounting is exactly where the opportunity hides.
And it is a snapshot. Every table on this page is dated August 31, 2026 for that reason. Re-run the counts before you rely on them, particularly in categories where a funded entrant has recently arrived.
If you want the next step after sizing, our guide to validating a startup idea covers the evidence ladder, idea validation collects the whole cluster, and the idea validation tool runs the checks against the same data used on this page. For the research workflow itself see the SaaS market research guide, how to use AI for market research and how to research market size for SaaS.
Build it bottom up in four steps. Count the companies in your segment that already take money for something, because a buyer who already pays for software is the only kind you can count. Measure how many of them are served by small software rather than by enterprise suites or spreadsheets. Multiply the reachable count by a revenue per customer figure taken from what comparable products actually earn, not from your own price page. Then apply a capture rate you can defend from your distribution, not a round 1%. Top-down industry reports are a sanity check on the result, never the source of it.
TAM is the total annual revenue if every possible customer bought. SAM is the slice your product, pricing and geography can actually serve. SOM is what you can win in one to three years with the team and distribution you actually have. The gap that matters is between SAM and SOM, because that is where execution lives. In our revenue data across 3,700+ revenue-reporting startups the median sits at $145 MRR, so a SOM built on thousands of customers paying $99 is describing an outcome roughly 1 in 150 startups reach.
Far smaller than most decks assume. Of the 3,700+ revenue-reporting startups we track, 23.6% ever clear $1,000 MRR, 6.1% clear $10,000 MRR, and 25 of them clear $1M ARR. That last group is 0.66%. A three-year plan that lands you inside the top quartile of everything we measure is not conservative, it is ambitious. Size your SOM against the number of customers your distribution can actually reach in a year, then check whether the resulting revenue would place you in the top 25% of comparable companies. If it would not, the market may be fine and the plan is the problem.
Bottom-up, with top-down used only as a sanity check. Top-down numbers come from industry reports that bundle in segments you cannot sell to, price points you will never charge and geographies you will not enter. Bottom-up ties the number to a countable population and a revenue figure you can source. The practical problem is that most guides tell you to go bottom-up and then leave the two hardest inputs blank: how many real buyers exist, and what they actually pay. This page fills both from live company and revenue data.
Do not use your intended price. Use what comparable products earn today. Median MRR in our corpus varies by more than 7x across categories, from roughly $640 in sales tooling down to $83 in fintech, and the mean is 30x the median because a handful of large companies drag it upward. Take the median for your category, not the average, and treat the 90th percentile as the ceiling scenario rather than the plan. If you cannot find a comparable, that is itself a finding about the market.
No, and the relationship is often inverted for small teams. A large category can be crowded to the point where distribution is unaffordable, and a small category can be wide open. The signal we trust more than size is software density: how many companies in a category are already served by small software. Home Services and Trades has 960+ companies taking payment in our Stripe Index and only four we classify as small software, a density of roughly 0.4%. Ecommerce Platforms has 3,400+ companies and 0.8% density. AI Tools sits at nearly 35%. Same directory, three completely different competitive realities.
Venture investors need an outcome large enough to return a fund, which usually means a category where a credible path to hundreds of millions in revenue exists. That is a real constraint, but it applies to venture-funded companies, and most software businesses are not that. If you are bootstrapping, the correct question is not whether the market is big but whether the reachable slice clears your personal number. A market that supports 300 customers at $80 per month will never raise a Series A and will comfortably replace a salary.
Whenever an input moves rather than on a calendar. The three that move fastest are competitor count in your category, prevailing price points, and the arrival of a well-funded entrant. Our own snapshot dates are printed on every table on this page for exactly that reason. A market-size number without a date attached is not a number, it is a memory.
Related reading: how to validate business niche viability, how to find a profitable niche, SaaS metrics benchmarks, buying versus building, finding acquisition targets and micro SaaS ideas.
BigIdeasDB Research. (2026). How to Calculate Market Size for a Startup, Using Real Numbers. BigIdeasDB. Retrieved from https://bigideasdb.com/how-to-calculate-market-size-for-a-startup