If you look across many SaaS products, you’ll notice something interesting.
Different products often end up building the same infrastructure features:
- scheduling
- email logging
- calendar sync
- contact sync
- activity timelines
These features appear in many types of software:
CRMs
ATS platforms
customer success tools
vertical SaaS products
But in most cases they are not the core value of the product.
They are infrastructure.
And yet many SaaS teams still rebuild them from scratch.
The Repeated Work in SaaS Integrations
Take activity capture as an example.
Many platforms want to automatically log:
- emails
- meetings
- contacts
- tasks
To do this they often need to integrate with systems such as:
- Gmail
- Microsoft Graph / Outlook
- Google Calendar
- Exchange
Connecting to these APIs is only the beginning.
The real work often includes building systems for:
- synchronization
- deduplication
- contact matching
- recurring events
- conflict resolution
Even something that appears simple — like syncing meetings — becomes complicated because providers represent events differently and handle edge cases in different ways.
Over time SaaS teams end up maintaining large integration layers just to support these foundational capabilities.
Existing Approaches
There are tools that try to simplify integrations.
Unified APIs
Unified API providers normalize different APIs behind a single interface.
They make it easier to connect to providers like Gmail or Microsoft Graph.
But they typically stop at data access.
The SaaS platform still needs to build:
- activity capture systems
- scheduling logic
- synchronization engines
- data reconciliation
Integration Platforms
Automation tools such as Zapier or Workato can move data between systems.
They are powerful integration tools, but they generally operate outside the product, rather than enabling built-in capabilities.
A Different Idea: Capability Platforms
An alternative idea is what I call a Capability Platform.
Instead of integrating APIs to build each feature, a SaaS platform maps its own data model to a canonical capability model.
Once the mapping exists, capabilities can operate on top of that model.
Conceptually the difference looks like this:
Traditional model
SaaS platform
↓
Build feature
↓
Integrate provider APIs
versus
Capability platform
SaaS platform
↓
Map data model
↓
Capabilities become available
The key shift is that integration happens at the data model layer, not the feature layer.
Example: Scheduling
Imagine a SaaS platform that wants to support meeting scheduling.
Instead of building scheduling infrastructure itself, it maps its event model to a canonical event schema.
Provider events
↓
Canonical event model
↓
Scheduling APIs
Once mapped, the platform can enable capabilities such as:
- availability queries
- meeting booking
- attendee management
- rescheduling
The scheduling functionality operates on top of the canonical model rather than individual provider APIs.
Booking Into SaaS Calendars
Sometimes the SaaS platform itself is the system of record for meetings.
Examples include:
- CRM platforms
- vertical SaaS systems
- booking systems
In these cases meetings should be booked directly into the platform’s own calendar rather than into Google or Outlook.
A canonical event model allows scheduling capabilities to work regardless of where the underlying calendar lives.
Activity Capture as a Capability
Another common feature is activity capture.
Many SaaS products want to automatically log:
- emails
- meetings
- contact interactions
- communication timelines
Systems like Aurinko’s BrightSync already sync mailbox data such as email, calendars, contacts, and tasks with business systems like CRMs or project management tools.
But the broader idea is that these capabilities could operate on top of shared models rather than requiring every SaaS product to build them independently.
Moving Toward This Model
At Aurinko we’re exploring this idea with canonical capability models such as:
- Aurinko Events — scheduling and booking
- Aurinko Sync (BrightSync) — activity capture and synchronization
Developers map their APIs and data structures to these models.
Once mapped, they gain access to capabilities such as:
- scheduling APIs
- availability queries
- activity capture
- communication sync
It is still early, but some customers are already mapping their systems this way.
A Potential New Layer in the SaaS Stack
Many areas of software infrastructure have moved toward shared capability layers.
Payments → Stripe
Authentication → Auth0
Messaging → Twilio
It’s possible that common SaaS capabilities like scheduling, activity capture, and communication sync could follow a similar pattern.
Instead of every product rebuilding them independently.
The Question
These capabilities already exist in many SaaS products today.
They are necessary, but rarely differentiating.
So the question becomes:
Should every SaaS team keep rebuilding them?
Or could there be room for a Capability Platform layer that turns these features into shared infrastructure?
Originally published at
https://www.aurinko.io/blog/the-case-for-a-capability-platform/
Top comments (0)