Ask a CISO how many SaaS apps their company uses and they'll give you a number with some confidence, usually pulled from an SSO log or a network discovery tool. Ask the same person how many internal tools nontechnical employees have built themselves in the last six months, and you'll get a shrug. Nobody's counting, because until recently there wasn't much to count.
That's changed. And the honest answer to "how many do we have" is: more than you think, and you don't know where most of them are.
Why the usual tracking methods miss these
SaaS discovery tools work by watching network traffic or SSO logs for known vendor domains. That catches Salesforce, Notion, and Figma. It does nothing for a one-off HTML file someone deployed to a free static host under a random subdomain, because there's no vendor to detect. The "vendor" is a person on your finance team who spent Tuesday afternoon in Claude.
Expense report audits, the other classic shadow IT detection method, are useless here too. Most of these tools cost nothing to build and nothing to host on a free tier. There's no line item to flag.
A rough way to find out
You won't get an exact count without real infrastructure for it, but you can get closer than "zero," which is where most companies start.
Start by asking around in a few functions that build a lot of these tools without ever going near engineering — ops, revenue, finance, and customer success are the usual suspects. Not "have you built anything," which people underreport because they don't think a spreadsheet-replacement counts as software. Ask "is there anything you or your team uses regularly that isn't one of our official systems." You'll be surprised how often the answer is yes, followed by a Slack link.
Check whatever free-tier hosting platforms your company's card has ever paid for, even a few dollars once. Vercel, Netlify, Render, Railway: a surprising number of internal tools live on the free tier of one of these, deployed by someone who just wanted it to work, not thinking about who else might stumble across the URL.
And check for database connection strings or API keys that show up in places outside your normal secrets management, pasted into a chat history, sitting in a .env file on someone's laptop, hardcoded into a repo that isn't part of your usual deploy process.
What you'll probably find
A few tools that are genuinely useful and should be adopted properly instead of quietly patched together. A few more that are fine but shouldn't be sitting on a public URL. And at least one that's reading from a real data source with credentials nobody in security signed off on, not because anyone was careless, but because there was never a secure default to reach for instead.
That last part is the fix. Give people a place to publish that's secure by default, login required, access controlled, no raw credentials anywhere near the browser, and the next round of this audit finds a lot less to worry about.