SaaS companies don't really build for power users, and secretly, I think they actually hate them.
I had two conversations this year that made this conspiracy feel highly probable, one with a vendor I already rely on, the other with one I was evaluating.
Vendor A: I use every day. They don't have an open API yet, because they didn't want to spend the money on the data infrastructure it would take. And sure, that stuff is expensive.
(I'm not mad at the person I was talking to. I know this isn't their fault.)
But I literally asked them: is that more expensive than losing customers over it? Or the whole new user base you're leaving on the table by not building it? You don't have to commit to an entire build, just a POC with a small number of "power users" to see if they'd actually use it.
Love the platform but I've had to build my own workflows by taking information from a webhook and vibe coding an app in Cursor to route leads and do things like that. When really, all that information already exists in the tool. It knows what reps these leads should be going to and what should actually be done with them. It was a painful process for me personally, and I suspect if they'd had an API to handle those functions, it would've been way easier.
Vendor B: I was evaluating. They didn't have any of their API docs public yet for a feature they were about to roll out. I joked with them about it, I don't think they found it very funny, about how agents are actually starting to make decisions on what tools I buy, based on how good their API documentation is.
I told them: one of the ways I make decisions on buying tools now is I'll literally have Claude Code or Cursor go read the documentation and compare it against the workflows and apps I've already built, to see if there's real feature parity with what we're using and if the tool will integrate well into how our org builds internal software.
I do that because I don't trust most sales reps to give me accurate information. Most sales enablement programs aren't built for talking to GTM engineers. They're built, again, like the rest of SaaS, to appeal to the bottom 90th percentile of users and buyers. To be fair, I don't fully trust myself to read through all the docs and compare them against a pile of vibe-coded slop apps I've built accurately on my own. Maybe I've offloaded too much of this to the machines. I don't know. But that's just where things are right now.
This isn't abstract for me either. This is literally what we do at AirOps: help people market their product the way I'm describing here, so it gets evaluated more accurately by the agents that are increasingly deciding whether or not someone buys it. So when I saw the documentation was private, I felt more concern for them than annoyance for me. There's no real upside to keeping it private. If anyone has a copy of it, and someone always does, I doubt an API schema is going to actually help a competitor get product parity. Code is a useless commodity anyways.
My guess is they didn't want people running a real feature-parity comparison against them, so they could keep exaggerating things in their own comparison decks without whoever they're competing against in a deal cycle having anything solid to push back with. I don't actually know that for sure. But it reads like trading top-of-funnel potential for negotiating leverage in individual deals, and knowing what I know about how AI search actually works, that trade doesn't seem like it's going to age well.
When I kept pushing on the API specifically, they told me they'd just rolled out their MCP. I don't think we were really on the same page about what's possible with a real API, or what I was actually going to do with one. They kept pointing at the MCP and their existing API features like that closed the loop, when what I was really asking for was the ability to report out and cross-reference data across other systems.
(If you're reading this: I'm not mad at you either, just disappointed.)
This is part of why I don't really get the industry's obsession with MCP right now. Most of what people are building with it is basically a glorified ChatGPT app. It's an inferior form factor for actually using AI. Also, I don't have visibility into what data it's actually pulling from, even within the app, when I just hook a bunch of API endpoints up to Cursor I know exactly what variables it's using to come up with workflows and answers.
Another thing that bothered me about what they told me: they pointed to an AI chat window inside their own UI, where you could ask questions about things like rep performance. It's basically a chat interface for asking about sequence performance and stuff like that, and for the bottom 90th percentile of users, that's probably a pretty cool feature.
The problem is I already have agents hooked into way more systems than just that one tool. Even where it's integrated to some degree with other systems, I've got a bunch of other stuff wired together where I want to cross-reference data from a data warehouse, or the CRM, against a marketing platform, and run some kind of qualitative analysis across all of it. I was never going to be able to do that by chatting with their chat window.
It felt like an attempt to lock me into their UI, and that's disconcerting and self-centered. The ego of the product designers is evident in those sorts of design decisions and I know it's not actively malicious but it's just one of those things where I think "this person must hate me".
Every SaaS platform has some version of this problem to actually solve: you have to sell to the purse holder, but you have to build for the practitioner.
Most SaaS platforms, especially hypergrowth, venture-backed ones, are optimizing for calculating ARR off this month's bookings, not retention, because they know how hard it actually is for a customer to exit a platform once they're in it. Some of that is just the economics of VC-backed SaaS, and it isn't always good for the user.
SaaS 2030
I think GTM engineering is going to go the same way software engineering is going: the top 10% of people are going to end up driving the majority of the outcomes for the business, and the bottom 90th percentile eventually gets pushed out. Me and my nine terminals I've got open are going to get more done than ten people who don't know how to actually use HubSpot or how to route a lead.
The world we're moving toward, whether people want to get on board with it or not: I sincerely believe the whole software industry is headed toward some kind of collapse.
What I think happens is companies end up with two or three people who stay up all night prompting, building all of their internal software.
Over the past year, as vibe coding took off, Lovable got big, Claude Code got big, people started joking "we're just going to vibe code Salesforce." That gets treated as the punchline. But you actually can vibe code Salesforce today. YOLOing slop code just isn't the fundamental problem anymore.
Most human-written code before AI was already slop, copied out of Stack Overflow. I don't really buy the argument that AI is bad at coding. It's already better than most people at that. AI is still weak on the judgment part: product decisions, UX design, deciding what to build in the first place. That's the hard part, and it's getting better every day. If I gave cursor a business problem in decent detail it could easily wire up some APIs and host something on Vercel that just runs and probably would be better than 90% of SaaS. (I do this btw)
Five years is probably too specific a timeline to commit to, and I could easily be wrong about all of this, predicting anything that far out right now feels like a losing bet. But the picture I'm imagining is people vibe coding whatever their business specifically needs, constantly, in real time. (because I'm already doing this, this isn't theoretical)
That doesn't mean every software product disappears. Something like Unipile is a good example, it's the infrastructure layer most LinkedIn automation tools are actually built on top of. It's just not worth rebuilding. Most SaaS isn't that indispensable. Same thing on the data side: a lot of what looks like a B2B data product is really an amalgamation of waterfalls stitched together from providers like Apollo and LeadMagic. You build your own layer on top of that, plus whatever proprietary data you actually own, and call those APIs directly. The underlying tools don't go away. What goes away is anybody logging into them as a platform.
I do log into LeadMagic occasionally, but the whole point is that I don't have to. I provision API keys for my team so they don't have to either. I'll hand one out and say, "here, put this in your CLAUDE.md file, use it for whatever you want." That's why I love the product.
I've designed, built, and now support a couple of internal applications at AirOps for the growth team. Vibe coding them was fast. Supporting them is where the actual work is, and it's a huge pain in the ass. But these are temporary problems in the world of AI. My current workflow when someone flags an issue in Slack is basically: screenshot it, throw it in Cursor, and let it go work on the fix. That loop only gets tighter from here. There's people more technical than me who probably have Cursor and Linear hooked up to slack and are generating PRs automatically from the same types of conversations. I actually know for a fact this is how some people are working.
Why I Hate SaaS Vendors
I honestly hate SaaS. I hate SaaS vendors and their unwillingness to build truly flexible platforms.
Some of it comes down to pricing and unit economics. If you give lower-tier plans too much functionality and too much flexibility, you've given away too much power. I work at a SaaS company myself, so I get the logic, I'm not denying the material reality of it. It's just frustrating as hell to sit on the other side of it as a buyer. The two vendors I mentioned in the beginning aren't exceptions to this, this is just how SaaS works, it's not personal to them at all, it's just how the entire industry works.
I get the infrastructure argument. If you let everyone do everything, you run up your AWS bill. Fine. So charge more money for it. I will happily pay more money for the features and functionality I actually need. All of this stuff already exists in the UI. All you have to do is make an API endpoint for it.
I don't want to log into your platform. I don't want to look at your fucking UI. I want results, that's all I actually care about. But nobody wants to build software like that. They want us to log in and do shit in the UI. A lot of these companies want to call themselves AI native, talk about their agents, all this other bullshit, but I don't want to use your fucking agents. I want to hook it up to Cursor and rip. I want to hook it up to Claude Code and have Claude Code operate the interface. I don't want to operate an interface.
Still not sure what people don't get about this.
Epilogue Pt 1
Something adjacent to all this that doesn't quite fit the main argument, but is worth flagging: what happens when the person who built all your internal software walks?
The code a GTM engineer writes for a business problem is never really customer-facing. If somebody walked off with it, you'd never know. To be clear, I have no plans to do this. But you can turn someone's Cursor access off the day they leave, and if it's already sitting on one of their personal machines, it's just out there. I don't think this is a problem anybody can actually solve, and it's not really something worth going after someone for.
If a GTM engineer moves to one of your competitors and now they've got all your workflows, you're kind of fucked. Let's not kid ourselves, people do this all the time. Unless you're doing some kind of forensic analysis with a lawyer and pulling a subpoena, are you really going to chase a GTM engineer over a marketing workflow that repurposes webinar content? I think not.
If you work at AirOps and you're reading this: I take this stuff seriously, for myself and for the rest of the team. Part of why I set up a company GitHub for the growth team in the first place is so this stuff lives somewhere observable and secure, instead of scattered across everyone's personal machines. Most GTM engineers aren't thinking about that at all, for better or worse. The only reason I am is that the last company I worked at sold into cybersecurity, and I ended up learning way more about security than I ever wanted to.
It's also part of why my thesis on hiring GTM engineers looks the way it does. When I'm evaluating someone, one of the first things I want to see is a GitHub repo. Something real that shows they've actually built a workflow. Operating a tool is different from building one. Cody Schneider has a line about how you're basically the average of the ten agents you work alongside. I think that same logic starts applying to hiring. When you hire a GTM engineer now, you're paying for way more than the person themselves. You're paying for everything they've built and everything they know how to rebuild, whether or not the last company can actually stop it from leaving.
Epilogue Pt 2
AirOps operates in the SEO domain, and there's a big debate about this going on right now: how some changes in the AI era are actually better for the user.
Google doesn't really show people pages anymore in their AI search experience, it's just using the information you published on your website to build its AI overview, so it's not driving traffic to your site while it's taking your information to do it. I see that as a moral quandary even though AI answers are actually better for the user, because I'm getting to what I want faster.
People complain that it's sometimes inaccurate or misrepresents things, and sure, okay. This stuff is as immature as it's ever going to be. We're always overindexing on the next six months of AI and underindexing on the next six years, so I don't really find that a valid concern long term.
As a user, I can just ask Claude something and it'll tell me, and I have my answer. Maybe it went to your website to find that. I never go to your website, I never click on anything, you never make any ad revenue, and Anthropic makes all the money instead. I still think that's better for the user and I vastly prefer that over having to navigate through 10 pages to find what I want.
Most SaaS platforms seem to be going in the opposite direction.