Why do SaaS vendors hate their power users?
SaaS companies say they build for power users. They don't. Two conversations this year made that feel like an open secret instead of a hunch.
Vendor A, a tool I use every day: no open API, because they didn't want to spend on the data infrastructure it would take. I asked them directly: is that more expensive than losing customers over it, or the user base you're leaving on the table by not building it? You don't have to commit to a full build, just a POC with a handful of power users to see if they'd actually use it. Instead I built my own workaround, pulling data off a webhook and vibe-coding an app to route leads, doing manually with Cursor what the platform already knew how to do internally. It just never exposed it.
Vendor B, a tool I was evaluating: no public API docs for a feature they were about to ship. I told them agents are starting to decide what tools get bought based on how good the documentation is. They pointed me at their brand new MCP like that closed the loop. It doesn't. Most MCP implementations I've seen are a glorified chat window bolted onto a UI I still have to log into. When I wire APIs directly into Cursor or Claude Code, I know exactly what data is feeding the workflow. A chat window inside someone else's app tells me nothing about what it's actually pulling or why.
Every SaaS platform has the same unsolved problem: you sell to the purse holder, but you have to build for the practitioner. Most platforms optimize for the bottom 90% of users and buyers because the retention math says they can get away with it. The top 10% just build around the gap.
So we do. Two things I've actually shipped because a vendor wouldn't:
No vendor sells "watch every target account for a job posting that matches our ICP and draft the outreach automatically." Sales Nav tells you someone got hired somewhere new. Nobody tells you a company is hiring for a role that signals budget or pain right now. So I built a bot that watches target companies for postings like that, drafts the outreach, and drops it in Slack for a rep to approve. Reps just click yes.
Nothing in our stack could tell us whether outbound actually influenced a deal. So I built a portal that pulled every outbound tool and the CRM into one place, matched campaign recipients to deal contacts by email address, and required a human to approve or deny each match before it counted toward attribution. Fast, auditable, and it didn't touch the approved historical numbers while we figured it out.
Neither of those needed a vendor's permission or roadmap. They needed an API key and somewhere to host the result.
When I'm evaluating a GTM engineer now, the first thing I want to see is a GitHub repo. Not because the code needs to be impressive. Because it tells me whether someone treats their operational knowledge as something worth building and versioning, or just something they complain about in Slack until the next tool comes along and does the same thing to them.
If you've ever vibe-coded around a vendor's missing endpoint instead of waiting on their roadmap, you already know which side of this you're on.