Look across the SaaS landscape and you’ll notice a strange pattern.
CRM platforms build scheduling.
Support tools build email sync.
Sales tools build activity capture.
Project Management platforms build calendar integrations.
And yet, none of these features are the core value of those products.
They are infrastructure.
Still, every SaaS company rebuilds them.
Over and over again.
The Repeated Work Behind Modern SaaS
Most SaaS platforms eventually end up implementing the same set of capabilities:
- calendar scheduling
- availability computation
- email logging
- calendar synchronization
- contact synchronization
- activity timelines
These features are rarely the primary reason a product exists. But they are expected by users.
A CRM without email logging feels incomplete.
A sales tool without scheduling feels outdated.
A support platform without contact sync quickly becomes frustrating.
So teams build them.
And building them is expensive.
It involves:
- OAuth flows for multiple providers
- complex API integrations
- ongoing maintenance as APIs change
- edge cases across providers
- synchronization conflicts
- background processing infrastructure
In many SaaS companies, a significant portion of engineering effort goes toward maintaining this kind of integration infrastructure.
Yet every company is solving essentially the same problems.
Existing Solutions Don’t Fully Solve This
Several categories of tools try to address the integration problem.
But they stop short of solving the real issue.
iPaaS platforms
Tools like Zapier or Workato help automate workflows between systems.
They are excellent for moving data between applications.
But they do not provide product capabilities.
They help connect systems, not power product features.
Unified APIs
Platforms like Merge or Apideck normalize external APIs behind a common interface.
They make it easier to integrate with many external services.
But they primarily help consume external data, not add product capabilities to a platform.
Embedded integrations
Many SaaS products provide integration frameworks for their customers.
But this still leaves the platform responsible for building and maintaining the underlying feature logic.
In all of these approaches, the SaaS product still owns the complexity of the feature itself.
What If the Missing Piece Is a New Layer?
Instead of building these capabilities repeatedly, imagine a different model.
A Capability Platform.
A platform that provides reusable product capabilities through canonical data models.
Rather than integrating APIs for individual features, a SaaS platform would map its own data model to a shared capability schema.
Once mapped, the platform could instantly unlock features built on top of that schema.
In other words:
Instead of integrating features, platforms integrate data models.
A Simple Example
Below is a conceptual diagram of what this might look like.
At the center of the platform are two abstract capability models.
Aurinko Events
A unified scheduling model.
If a SaaS platform maps its internal objects to this model — such as users, calendars, appointments — it could gain scheduling capabilities automatically.
Capabilities might include:
- meeting booking APIs
- calendar scheduling
- availability computation
- appointment coordination
A CRM that maps its meeting objects to the Aurinko Events schema could instantly support scheduling without building its own scheduling infrastructure.
Aurinko Sync
A unified activity model.
If a platform maps contacts, emails, tasks, and meetings to this model, it gains access to activity capture capabilities.
Capabilities might include:
- email logging
- calendar synchronization
- contact synchronization
- tasks synchronization
- activity timeline generation
For example, a CRM mapping its contacts and activities to the Aurinko Sync schema could automatically sync with Gmail, Outlook, and calendar providers.
A Shift in How SaaS Integrations Work
Traditionally, SaaS products build features and then integrate external APIs to power them:
SaaS Platform → Builds Feature → Integrates APIs
A capability platform flips this model:
SaaS Platform → Maps Data Model → Gains Capabilities
The integration moves from feature logic to data structure.
Once a platform conforms to the shared schema, it inherits the capabilities built on top of it.
A Helpful Analogy: Stripe
Stripe didn’t just expose payment APIs.
It introduced a canonical payment model.
Once a company integrates Stripe:
- payments work
- subscriptions work
- invoicing works
- billing works
Developers don’t rebuild payment infrastructure.
They integrate the platform and gain the ecosystem.
A capability platform could apply the same idea to common business primitives:
- events
- activities
- contacts
- communications
Why This Is Hard
If this idea is so appealing, why doesn’t it already exist?
Because the problem is deceptively complex.
Different platforms have:
- different data models
- different permission systems
- different event semantics
- different write behaviors
- different multi-tenant architectures
Mapping these systems into canonical schemas requires solving difficult problems around:
- synchronization
- conflict resolution
- data ownership
- event consistency
Building such a platform would require deep infrastructure.
But the payoff could be significant.
The Potential Outcome
If capability platforms emerged, the SaaS landscape could change significantly.
Products would become thinner.
Instead of building large amounts of infrastructure for common capabilities, teams could focus entirely on their domain.
Scheduling, activity capture, communication sync, and other cross-platform capabilities would become shared infrastructure.
SaaS platforms would no longer rebuild the same integration-heavy features repeatedly.
They would simply plug into them.
The Open Question
The capabilities discussed here already exist in almost every SaaS product.
They are necessary, but rarely differentiating.
So the question becomes:
Should every SaaS company continue rebuilding them?
Or is there room for a new platform layer — a Capability Platform — that turns these features into shared infrastructure?
The idea is still exploratory.
But we are already moving in this direction with Aurinko’s Dynamic API.
Aurinko has begun defining canonical capability models such as Aurinko Events and Aurinko Sync (BrightSync). These models act as shared schemas for scheduling and activity data. Instead of integrating individual features, platforms map their own APIs and data structures to these models.
Once mapped, they can access standardized, pre-built capabilities powered by those models.
For example, platforms mapping to Aurinko Events gain access to scheduling and availability capabilities, while platforms mapping to Aurinko Sync (BrightSync) can enable features like email logging, calendar synchronization, and contact sync.
This approach is still evolving, but it represents a practical step toward the broader vision of a Capability Platform — where SaaS products integrate once at the data model layer and unlock entire categories of functionality.