Last October I wrote a LinkedIn post about platform vendors that ran longer than I'd intended and got more reaction than I'd expected. The core argument: there are two kinds of platform companies in martech right now, and you almost never see them labeled correctly when you're choosing a martech vendor. One kind is building infrastructure you can stake a five-year strategy on. The other kind is using your portal as a free R&D lab and will sunset the feature you depended on the moment it stops being interesting to them.
This post is the longer version of that argument, with the selection criteria I wish someone had handed me when I was running marketing ops a decade ago. It's the companion piece to the post on the Red Stapler feature problem — bloat is the symptom, vendor archetype is the cause.
Every platform vendor in martech is a mix of both archetypes, but the dominant orientation matters more than the mix. Scott Brinker's annual Chiefmartec martech landscape tracks the long-arc behavior of these vendors better than any analyst quadrant I've seen.
An Ecosystem Builder treats their platform as infrastructure. They invest in the boring durable layer: APIs that don't break, a data model that holds across releases, partners they actually integrate with, documentation that's complete enough for a new engineer to onboard without a call. They ship fewer features per quarter, but the features they ship are load-bearing. They deprecate things slowly and with notice. They write migration guides.
The Ecosystem Builder's incentives are aligned with yours over a 5-10 year horizon. They want you to build on them, succeed, and renew at a higher tier because your business grew on top of them. They will sometimes pass on shipping the fashionable feature this quarter because it doesn't fit the long-term architecture. That restraint is, paradoxically, the strongest signal you can get.
A Free R&D Lab treats their platform as a distribution channel for experiments. They ship a torrent of features each quarter, most of them shallow, many of them launched in beta and never moved out of beta. They use the customer base as a forced testing ground for ideas the product team wants to validate, and they aren't accountable for whether those ideas work in production. When a feature underperforms internally, it gets quietly deprecated — sometimes with notice, often without — and the customers who built on it are on their own.
The Free R&D Lab's incentives are aligned with their roadmap and their press cycle, not with your durability. You'll know you're dealing with one when the second-to-last feature you adopted just got removed and the replacement requires you to rebuild your workflow from scratch.
Here's the painful part: every vendor sells the Ecosystem Builder story. The slides look identical. The customer logos overlap. The analyst quadrant doesn't distinguish between them. You will not be able to tell which archetype you're buying from the demo, the RFP response, or the reference calls (which are pre-screened).
The distinction only becomes visible 18-24 months in. By that point you've migrated. The switching cost is higher than the rebuild cost would be. You're trapped in a relationship whose actual shape didn't match the one you bought.
This is the structural reason choosing a martech vendor is so hard. The information you need to decide isn't available at the moment you have to decide.
Since you can't trust the sales cycle, you have to work backward from the public record. The following signals are imperfect but they're a lot better than the marketing pitch.
The most useful single artifact a vendor publishes is the historical release notes — far more useful than the curated reports you'll find in Gartner's marketing leadership research, which tend to capture the snapshot rather than the trajectory. Pull three years of them. Look for two patterns:
Ecosystem Builders invest in their APIs because they know you're going to build on top. The APIs are versioned, documented, and stable. The partner directory has hundreds of working integrations and a non-trivial certification process. The community has third-party tools that have been around for years.
Free R&D Labs publish APIs that are technically functional but loosely versioned, sparsely documented, and frequently broken by underlying changes. The partner directory is a marketing page. Third-party tools come and go in 12-month cycles. The signal you want is durability of the surrounding economy, not the slickness of the vendor's own product.
Look up the head of product on LinkedIn. If they've been in the role for three-plus years and have shipped through at least one full strategy cycle, that's a stability signal. If the role has turned over three times in five years, the product strategy is whiplashing. Whiplashing strategy is the single most reliable predictor of Free R&D Lab behavior — each new product leader needs to put their mark on the roadmap, which means new flagship features get launched and old ones get orphaned every 18 months.
On vendor calls, ask: "When was the last time you deprecated a customer-facing feature, and how did you communicate it?" Ecosystem Builders answer this fluently — they have a process, a timeline, a migration path. Free R&D Labs get awkward, claim they "almost never deprecate," and then change the subject. The awkwardness is the answer.
Reference calls are pre-screened. Talk to companies that left the platform — you can find them on Reddit, in community forums, in old case studies that have since been pulled. The reasons people leave are far more diagnostic than the reasons people stay.
If you're picking a martech vendor for a function you expect to depend on for 5+ years — a CRM, an ESP, a marketing automation platform, your CDP — weight the following criteria heavily. They're the ones that pay off over the long arc and that almost nobody scores during a typical RFP.
Has the vendor changed how they model the core objects (contact, account, deal, event) in the last three years? If yes, ask what migration looked like. If the migration was painful, your next migration will be painful too. Stable data models compound. Mutable ones bleed you.
Can you reconstruct, for any contact, the full history of what was sent, when, by which workflow, and what changed? This is the same question a real HubSpot email collision audit answers — and if your vendor's data model can't support it, audits become forensic exercises instead of routine ones. If you can't, you don't have an auditable system — you have a black box that happens to also send email. Ecosystem Builders make audit trails first-class. Free R&D Labs treat them as a compliance afterthought.
Even if you don't think you're a developer org, you will need to extend the platform at some point. The quality of the developer experience — sandbox accounts, real test data, a CLI, version control, the ability to run a diff between two configs — predicts how much pain you'll feel during every future change. This is a deeply boring criterion that pays the loudest dividends.
Walk through your current operational dependencies on the vendor's platform. For each one, ask: "If they sunsetted this feature tomorrow with 90 days notice, could I rebuild it on top of what remains?" If the answer is no for more than a handful of features, you're already too deep with a vendor whose archetype hasn't been tested.
I'll be careful here, because I have working relationships with several of the platforms in this space and the archetypes shift over time. A vendor that was an Ecosystem Builder five years ago can drift into Free R&D Lab behavior under new leadership. A vendor that started as an R&D lab can mature into infrastructure.
The exercise to do is not "which bucket is HubSpot in" or "which bucket is Salesforce in." It's "which direction has my vendor been drifting in the last two years?" The trajectory matters more than the snapshot. A vendor drifting toward ecosystem behavior is a safer long-term bet than one drifting toward R&D lab behavior, regardless of where they sit today. The same lens applies to the question of why most HubSpot implementations underperform — trajectory of the platform is half the answer.
Yes, and this is actually common at large platforms. The core product (CRM, marketing automation) tends to behave like infrastructure because the customer dependency is too deep to risk. The newer adjacent products (AI agents, conversation intelligence, CDPs) often behave like R&D labs because the vendor is still figuring out the category. Buy the core. Be skeptical of the adjacencies.
Smaller doesn't automatically mean Ecosystem Builder. Plenty of small vendors are R&D shops chasing the next round. The size question is orthogonal to the archetype question. What matters is the vendor's behavior around stability, deprecation, and developer experience — not their headcount.
"Walk me through the last feature you deprecated, the timeline you gave customers, and what migration looked like." The answer is more diagnostic than any other question I've ever asked in a vendor evaluation. If they can't answer cleanly, they either never deprecate (bloat is coming) or they deprecate badly (you're next).
We're a small focused product. Our archetype check is whether we're treating customers as partners in the long arc of email orchestration or as a free testbed for whatever AI feature is trending. We publish a product updates page with the actual ship history, including deprecations. You can read it back three years and judge whether we're walking the talk.
When you sign a martech contract, you're not buying features. You're betting that the vendor's archetype will hold for the life of your dependency on them. The features in the demo are real today. They're not necessarily real in three years. The archetype is what determines whether the bet pays off.
This is why I push back on vendor evaluations that score on feature matrices. The feature matrix is the snapshot. The archetype is the trajectory. The trajectory is what you're buying.
If you want to test whether Seventh Sense fits the Ecosystem Builder pattern you're looking for, the free trial is the fastest way to see how we operate — how the product is built, how the documentation is structured, how the integration with HubSpot actually behaves under load. That's the only signal that ever really matters.