TL;DR
We built for visibility. Customers demanded action.
Every gap we flagged - orphaned accounts, lingering contractor access, zombie licenses - traced back to the same root cause: vendors had locked SCIM behind enterprise paywalls. We named it the SCIM Tax. We analyzed 721 apps and found it's not just a few bad actors: 42% paywall SCIM, another 57% never built it.
So we pivoted. Built resilient browser automation with 24/7 human-in-the-loop. As one customer put it: "That's crazy... but also pretty elegant."
Our original thesis
When we started Stitchflow nearly three years ago, our thesis was simple: IT teams can't fix what they can't see.
We built the "Stitchflow IT Graph," a sophisticated visibility engine that stitched together data across every tool in a company's stack. It worked. Customers used it daily to eliminate spreadsheet work and uncover problems they didn't know existed. But we quickly realized something crucial was missing.
We were handing them a bucket to bail out the water, but we weren't helping them plug the holes in their boat.
The pattern: the gaps keep coming back
Every time we flagged a critical security or spending gap (offboarded users still active, contractors with lingering access, or "zombie" licenses) it traced back to the same root cause.
Customers couldn't automate provisioning for a significant portion of their critical apps, and had to default to manual user management.
- This wasn't because the apps lacked APIs.
- This wasn't because IT didn't know how to script.
- It was because the vendor had locked the necessary SCIM automation behind a prohibitive paywall.
We saw this with high-value applications like Figma, Adobe, Slack, and Monday.com. The security and automation capabilities existed, but they were held hostage on the "Enterprise Tier" - bundled with features our customers didn't need.
When we dug deeper, we found the problem was even bigger. We analyzed 721 SaaS apps: 42% lock SCIM behind enterprise pricing - that's the ransom. But another 57% have no SCIM at any price - not a ransom, just a gap they never built. Only 9 apps include it on their base tier. That's 98.8% of apps where provisioning is blocked, whether by greed or neglect.
We named it: The SCIM Tax.
Ransom economics: why the SCIM Tax exists
The SCIM Tax isn't a technical constraint; it's a deliberate revenue strategy by app vendors we call Ransom Economics. Vendors bet on your fear of security incidents and compliance gaps to force you into a huge price hike.
- Because companies couldn't justify paying $80,000+ extra just to automate offboarding, they stayed on "Pro" plans.
- This left IT teams stuck manually logging into browser admins to delete users - bailing water every single day just to stay afloat.
- Manual mistakes lead to compliance gaps and wasted licenses.
- Security holes widen - not because of IT negligence, but because of bad vendor pricing.
The pivot: visibility without action wasn't enough
Our turning point came during a call with a customer who looked at our data and said the quiet part out loud:
"Visibility is great, but the gaps keep coming back. How can you help me automate it so it doesn't happen again?"
That single question reframed our roadmap.
They weren't asking for better visibility. They were asking us to close the loop.
IT teams don't need another dashboard. They need a machine that fixes the problems.

Solving the SCIM Tax with resilient browser automation
So, we pivoted. We stopped building solely for "visibility" and started building for "action".
We built secure headless browsers that execute the same provisioning and deprovisioning actions that a human admin would. But with the resilience of an API, and the safety and guardrails of a SCIM integration.
The automation follows a deterministic, pre-validated flow. If anything looks off - a UI change, wrong modal, unexpected state - it stops immediately.
And to solve the hardest part of browser automation - resilience - we added a 24/7 human-in-the-loop team. Whenever there's an MFA prompt, CAPTCHA, or unpredictable UI change, the automation pauses, and a human steps in inside a secure, recorded environment. That's how we give you the flexibility of browser automation with the reliability of an API.
As one customer put it: "That's crazy... but also pretty elegant."
The first time it automatically created and removed accounts in a non-SCIM app with SCIM-level consistency, we knew we'd unlocked Enterprise automation for a Pro-plan price.
We also started measuring what manual provisioning actually costs. Across 27 organizations, it averages ~$12,000 per app per year in IT labor, unused licenses, and compliance gaps. We're the first company to quantify this - and the data is what convinced customers that automation at <$5,000/app/year was an obvious ROI.
Where we are now: defeating the SCIM Tax
Today, Stitchflow isn't just reporting on the mess. We are cleaning it up.
We function as a managed SCIM bridge. Whether an app has an API, no API, or hides SCIM behind a paywall, we treat it the same. Your Identity Provider (Okta or Entra) sends a signal, and Stitchflow executes the change.
As long as vendors use security as a leverage point for upsells, Stitchflow will be the infrastructure that lets you say "No".
We set out to defeat the SCIM Tax - and that's exactly what the market desperately needed.
Frequently asked questions
The SCIM Tax is the hidden cost vendors impose by locking SCIM provisioning behind expensive enterprise plans. Even though the app already supports SCIM, users are forced to upgrade - often 2-4x the base price - just to automate onboarding and offboarding.
Jay has been serving modern IT teams for more than a decade. Prior to Stitchflow, he was the product lead for Okta IGA after Okta acquired his previous ITSM company, atSpoke.


