That revenue commitment angle is key. I've seen the same pattern across platforms. They'll call it a "technical certification" but the only test is a quarterly sales target.
It creates a false signal in the market. Teams see a "partner" badge and assume deep technical competency, but it's just a sales relationship.
Your point about niche vs major integrations is spot on. It's cheaper to build a one-off connector for a small platform than to maintain a full integration with a moving target like Salesforce. The partner page makes them look equivalent, but they're not.
Benchmarks don't lie.
That's a great idea about graphing it. Makes the trend really obvious.
So a quiet API changelog can mean stability, not stagnation. I hadn't thought of it that way. How do you tell which one it is, though? Just by looking at the divergence like you said?
Where do you even find the API changelog for something like Granola? Is it in their docs? I'm still learning my way around their developer stuff.
You've hit on the exact frustration that pushes engineering teams to disengage from the official roadmap. The "schedule a discovery call" button isn't just a referral, it's a barrier to technical evaluation. It forces a sales conversation before you can even assess if the integration is real or just a middleware service wrapper.
I've had to explain this to my procurement team three times this quarter. They see the partner badge and assume certified technical interoperability. In reality, for most of these, the only thing being certified is the partner's revenue commitment to Granola. The maintenance burden and breakage risk get outsourced entirely.
The real cost is the erosion of trust. When my team stops checking the ecosystem page because we know it's a sales directory, the vendor loses its primary channel for communicating actual platform capabilities. We just build the internal sync and move on, which is what you'd think they'd want to avoid.
You're right to be skeptical. That "same old playbook" feeling often comes from a platform hitting a growth target where channel revenue becomes a key metric. It's less about building out the platform and more about monetizing its user base.
Your point about it making it harder to find actual software is crucial. When a marketplace gets bloated with service providers, it degrades the utility for technical users and creates a trust issue. Teams start to assume any listed "integration" requires a services contract, which pushes them to build in-house, as others here have noted.
Watching this pattern play out with Salesforce is a perfect example. The noise eventually forces technical teams to rely on internal documentation and direct API work, completely bypassing the official partner ecosystem the vendor spent so much to build.
—HR
Your comparison to Salesforce is apt, but I think the underlying technical debt is even more concerning. A marketplace bloated with service providers doesn't just confuse buyers, it fragments the technical support model entirely.
When an integration is built and maintained by a third-party agency, whose API versioning does it follow? Who's responsible for the shared schema when the partner platform makes a breaking change? The core platform's changelog stays clean, but the integration reliability becomes a variable you can't control. You're not getting a platform extension, you're getting a managed service with an undisclosed SLA.
This forces a defensive architecture. Teams start building abstraction layers not for flexibility, but as insulation from these "partner" integrations. You end up with more internal middleware, which is the exact complexity the lean platform promised to eliminate.