B2B SaaS companies are increasingly looking to transition from being a point solution to becoming a platform other companies build on.
SugarCRM is one of many platform companies, including the likes of HubSpot and Salesforce, who have secured their place in the highly saturated customer relationship management (CRM) space.
However, their journey has been quite different from most. Sugar solidified their position early on by being an open source platform, which meant enabling 3rd parties to build on top of their app has always been a core part of their DNA.
We sat down with Matt Marum, Director of ISV Alliances at Sugar, to dig into some of the challenges they’ve faced along the way, as well as the tactical strategies they’ve used to scale their integration ecosystem that can be applied to any company, open source or not.
Watch the interview here.
Open sourcing - is it worth it?
Open source projects are becoming more prevalent as a go to market strategy for SaaS companies today. Getting developers to become advocates for your project, while not easy, can provide a lot of traction if executed properly.
Early on, SugarCRM benefited greatly from the brand awareness that being open source brought them, through their vibrant and organic developer community.
This community still pays dividends today, as it has become a resource for the Sugar team, especially when it comes to looking for subject matter experts in different verticals - but more on that later.
However, it’s not all roses.
“Over time it didn’t support the needs of the business at a certain point of growth. Every successful project gets forked and competitors use your own IP against you,” says Matt.
Additionally, while it did drive awareness for Sugar, it was primarily with the IT/developer communities, who often share the view that projects should stay free.
This meant that a lot of the awareness didn’t necessarily convert into revenue, which as we all know is the oxygen companies live and die by.
Within the scope of integrations, having open source roots did provide them the luxury of not having to really build an API. The code itself was malleable and as a result, they had people build their API and simply commit it back to them.
All that said, unless you are already open sourced, it’s probably not worth the effort to shift your company’s strategic direction to becoming open sourced.
Instead, focus on what you can control (within the context of integrations) - that is, to build a strategy for scaling your integration offerings with your customers’ other apps.
Methods of enabling integrations
While many early stage startups unfortunately backlog their customers’ integration requests, until the damage to their pipeline/retention becomes too severe to ignore, we are seeing trends where companies taking an integration-first approach have experienced outsized product adoption and growth.
Regardless of approaches, what’s consistent among all of these earlier stage companies is that they generally build integrations internally.
On the other hand, for companies who have reached the scale of Sugar, integration work gets distributed across different implementation methods:
- Build internally (with or without an integration platform)
- 3rd party owned (through a public API)
- Partner led (through a partnerships initiative)
Let’s start by going over the challenges and strategies that come with building in-house, as most startups will find themselves in this phase.
Challenges scaling integrations
Building internally
For companies that don’t take an API first approach, the first 50 integrations or so are almost always designed and owned internally.
While much more work is required to get these integrations out (especially without an embedded platform), there are advantages to this approach.
First of all, it forces your team to be deep in the weeds of learning more about your customers’ overarching workflows. This is extremely valuable in helping determine not only what integrations to build, but how to design deeper integrations that enable your product to drive significantly more value (and make it harder to ‘rip out’).
Additionally, as integrations are also often used by tangential users to your core ICP, this process enables you to understand and uncover new use cases that your product can build towards and better support over time.
Ultimately, no 3rd party or partner will ever understand your product to the extent that you do, so your first integrations will allow you to set standards for what a seamless integration should look like.
Prioritization
One of the difficulties of build integrations internally is always going to be prioritization. As Matt shares “There are too many dang apps out there, you can’t build them all. You’re always going to be in a place where you’re saying no more than yes.”
This emphasizes the importance of thinking ahead when you build out your integrations, particularly for apps within the same category.
Much of it will be boilerplate from a business logic perspective - for example, a Salesforce integration should look very similar to a Salesforce integration, and similarly, a Jira integration will behave similarly to an Asana integration.
At Sugar, they’ve used an embedded iPaaS to help further optimize this effort, as workflow designs can be replicated across integrations, resulting in a much lighter work effort to cater towards the app specific requirements. However, the devil can be in the details here.
Limits to templating
While a significant part of the business logic that goes into integrations of the same category can be re-used, the last 10% of customization can often still be a challenge.
Not all 3rd party APIs are designed to the same calibre which can lead to certain limitations in endpoints, and you will also want to build towards the strengths and differentiating factors of each app. Doing so successfully ultimately requires you to engage subject matter experts that know the ins and outs of the 3rd party app.
Subject matter expertise
Beyond the app specific knowledge, you may be building integrations for cross-functional teammates of your core user base. While this can unlock new use cases and expansion revenue, but it inherently is not an audience your team will be as familiar with.
Check out this article to see how to overcome those challenges, but often times partnering with the 3rd party app (for which that audience is the primary ICP) can be a shortcut to the heavy lifting of research.
This brings us to the next point of building an API for 3rd parties and partners to build integrations against.
APIs for Integrations
“It’s not true that if you build an API, they will come. Just building an API isn’t enough.”
Not only do you have to build a set of exemplar integrations that other companies can refer to, you need to design an API that is flexible enough to support many use cases.
Within the context of integrations, Matt says there are 3 things that your API must support.
- Data integration
- Used to pull data in and out of your platform (enabled through RESTAPI)
- Process automation
- Used to integrate with your customers’ critical business processes and workflows (supported by webhooks)
- UI integration
- Used to provide a more seamless experience for your users all in one view (may need iFrames or Javascript SDKs)
Side note - regardless of where you are in your journey of building an API for your app, here’s the one piece of advice Matt emphasized.
“If you’re building an API, please version it. It’s important to build discipline around it early on, because every decision you make today, you may need to change in the future.”
In Sugar’s case, overlooking this aspect of API development has made getting rid of old APIs and extension points nearly impossible.
Partnership led integrations
Once you’ve hit product-market fit, it may make sense to begin building invest in partnerships with 3rd party apps that you want to integrate with.
This enables a whole slew of benefits, including co-marketing, cross-pollination of users, synergistic value creation, and in the context of this article, access to subject matter experts from the 3rd party app’s company.
While the onus of building may still fall on your engineering team depending on the terms of the partnership, having the support from both sides in both the go to market and technical needs will enable you to build much more robust integrations.
To watch / listen to the full conversation, click here.
