No software lives in a vacuum. It always has a context that is broader than the users and functions it serves. Every software product--big or small, expensive or free, complex or simple--is sold and used in a world of direct competitors, indirect alternatives, compatible friends, incompatible foes, and your customer's permanent potential choice to do nothing. In other words, all software is part of an ecosystem.
In B2B software ecosystems, there's a natural hierarchy of how different software products relate to one another. To generalize what this hierarchy looks like:
These categories are not as straightforward as we're presenting them, here. But, this gives a good archetype for describing how integration differs for different types of businesses.
In this post, we'll go through each category and talk about why integration is important for that type of software product. We'll also discuss what success generally looks like for the integration programs for those products.
A point solution does one or a few related things very well. Point solution products zero in on a pain point that isn't addressed by the available options and they offer a specialized alternative. They have to be really good at solving that problem, and usually in a differentiated way. Sometimes they even solve a problem that no one else has seen or attempted to solve.
If a software product falls into this category it could be a sign that the company that produces it is fairly young. When you start a software company cash is tight, resources are limited, and time is of the essence. If the founding team has a big vision for the product, they only have the resources to address part of that vision.
Not every software product grows past this point. It may be a failure to execute on a big strategy, but it also just may be that the product has a growth ceiling and there's nothing wrong with that. In either case, whether growth beyond a point solution or simply being really good at one thing are the goal, integration is key to unlocking large chunks of the addressable market.
It's really hard to be successful as a point solution without key integrations to larger ecosystem players. A point solution by its nature does one thing really well, but it does so in the context of a whole lot of things that need to be done. The product has to be compatible with the products that do those other things.
Point solutions generally have limited resources, so investments into integration need to get a bang for the buck.
You likely won't see huge amounts of integrations available for point solutions, but the ones you will see are big names with big customer bases. Some point solutions may only have one integration (e.g. a bolt-on app for Shopify stores). Software teams at this level should view every new integration as a pool of potential customers unlocked, so it's usually best to invest those finite dollars in an integrations that can unlock large amounts of those customers.
Integration is important, because integration is a fundamental part of driving revenue. Lack of integrations will be a common reason for losing deals.
Successful integration strategy for a point solution is about making the right investments as often as possible. (You will have some misses, but hopefully more hits.)
When looking to invest finite resources in a relatively small number of integrations, prioritize building integrations to the following:
You may not find any that check all these boxes, and you may find valid reasons to go against one of these. For example, it might be worth paying that partnership fee to get listed as an integration, because the partner's customer base is so large and so relevant. But, as a general rule of thumb, these priorities will help you spend integration dollars well.
Bottom line: Integration strategy for a point solution is about quality over quantity.
A hub solution seeks to attack a broader set of use cases, but still within a general domain. For example, if a point solution is a tool for scraping LinkedIn profile data to find qualified leads, a hub solution is a CRM to store and manage those leads.
Hub solutions have a tendency to gradually take more and more bites out of the apple--gradually checking off as many use cases within a domain as possible. That's because at this stage, your selling strategy starts to pivot more to selling a "one size fits all" solution. Hub solutions grow customers by growing capabilities.
That said, you can't literally build everything, so integration becomes a huge part of being that "one size fits all" solution by becoming extensions of the product.
Hub solutions tend have more resources than point solutions, because their nature means the company has probably been around longer and built more momentum. Often you'll see point solutions graduate to being hub solutions as they continue to add functionality to their products.
Hub solutions, by their nature, are also probably larger and more expensive. These are bigger investments for customers to make. They are commitments to making the hub solution a foundation piece of their tech stack. In that role, a software product holds a higher burden for integration with all the other products your customer may choose. Failing to do so is a huge friction point in the sales process, because it's just too risky for the customer.
Hub solutions need to take it upon themselves to crank out integrations like a factory. But, this comes with its own challenges.
Integration strategy for a hub solution involves taking a larger burden of responsibility for integrations, considering them as features that will close deals.
Where point solutions build integrations to unlock and pull in demand, hub solutions build integrations to capture demand that is generated more broadly. Every integration you provide gives your customer another excuse to say "yes" when it comes to investing to make your product a foundation of their tech stack. Or, put another way, it erases a reason to say "no". Every integration you provide also makes it harder for your customer to leave.
(Typeform did a study and found that customers with 5 integrations churned 35% less.)
You need to create a factory. Your roadmap should be 2-1 proactive integration than reactive-to-customer-request integrations. You should have a backlog of integrations you've assessed are key to filling in the gaps for your customers.
This also means that developing (and/or outsourcing) the expertise to build and maintain integrations at scale is important. You can stumble through hacking together a dozen (+/- six) integrations. If you hack 30 or 50 or 100 integrations, you'll have a serious technical debt problem. You'll also probably have some unhappy customers who are having data dropped on the floor.
Lastly, hub solutions should start to treat integrations as a key product marketing driver. They aren't a necessary unlock to the market. They are differentiators in the market. That's why you'll see many hub solutions wisely investing in customer-facing integration marketplaces that showcase their breadth of integrations.
Again, each one is another reason for the customer to sign up for your product.
The vast majority of B2B SaaS products are either point or hub solutions. Again, graduation from those categories isn't necessarily a sign of failure. Some products simply have a limit to scale, addressable market, and what makes sense for feature expansion.
A small number of products graduate to being platform solutions, and things really change at this level.
If point solutions say, "Let's integrate to these couple of products, because that's where we can find a lot of customers."
And, hub solutions say, "We need to integrate to all of these different ones, because these integrations are what our customers demand."
Then, platform solution s say, "There's no way we can build all of the integrations our customers need, and we've got some weight to throw around in the market. You (other products) should build to us."
Platforms flip the script on their role in the software ecosystem, becoming the recipient of integrations more than the producer of them. Platforms tend to be very large products with very large customer bases. They tend to be among only a few competitors with outsized market presence. That also gives them the ability to set terms in the market instead of simply reacting to them.
Platforms are the products you've probably heard of: Salesforce, Hubspot, NetSuite, Shopify, etc. But, just because they are large and in charge, it doesn't mean integration isn't still extremely important.
Integration is important for platforms much in the same way it is for hub solutions--each integration is a reason your potential customer can say "yes".
But, at a certain scale, the dynamic changes. It becomes impossible for the product team to build and maintain hundreds or thousands of integrations. The cost of sourcing, prioritizing, delivering, and maintaining that many integrations would simply be too high.
To maximize their integration footprint, a platform must enable the smaller players in their ecosystem, the point and hub solutions, to build integrations to them (not the other way around). This means your integration team stops being a factory and starts being an enablement service.
There are common, non-negotiable features to every platform solution who has success.
Platform solutions have best-in-class APIs. They are well documented and well supported. Usually a community is cultivated around them for additional support. These APIs shouldn't release breaking changes without notice or vary significantly from customer to customer. Platform APIs should also use reasonably modern technologies, like REST or GraphQL, that a broad population of engineers understand.
Platforms also develop their own ecosystem of developers and partners around their product. There should be really strong alignment with the team that builds features to support integration and tech partnership and community engagement teams. They host partner events and cultivate the community, because that community's growth and happiness is critical.
Platforms tend to position themselves as enablers of business for their integrated software partners, not peers. Think of how many businesses exist that solely build Salesforce link cartridges or Shopify apps. Much of the community engagement is about "how to build a business around our solution".
Platform solutions provide functionality to support the community in building and deploying integrations to their product as well. This can include partner portals and app submission features. It also includes technical artifacts like SDKs, that speed up developers who build the integrations.
Platforms are primarily outbound about integration, where point and hub solutions are primarily inbound. If a hub solution markets with an integration marketplace, a platform markets with an app store.
This is not to say that platforms don't build integrations. Every integration strategy is always a mix of approaches. But they tend to rely on the community to provide an integration whenever possible.
Some platform solutions take the enablement of their integrated the partners even further. You're starting to see them not only provide APIs and help using them, but actual integration technology itself as part of the solution. These platforms, which aren't fundamentally integration software products, are now offering built-in integration software.
This is a new, but huge opportunity for software products the enable more "yes" answers from customers. It's especially useful when you're selling to customers who have very inconsistent, complicated integration requirements--when simply building an integration that supports everyone is really hard.
This post doesn't cover the different approaches to enabling SaaS integration, but one common way you'll see a platform enable full integration delivery features into their product is through the use of a commercial embedded iPaaS. Not all commercial iPaaS products can support this, but some of the more mature ones can.
You're also starting to see platforms acquire smaller iPaaS vendors to expand their offering to include integration features. As of this post, this is a pretty new trend to be seeing in the market, so time will tell if it works for those platforms and their customers.
These categories of software products and the specific approaches you should take for enabling integration in each category are generalizing the problem. It's far more complex than, "you fit in this bucket so do exactly this".
In reality your integration strategy will include aspects from all categories, no matter what size or stage you're in.
But, it is important to understand these archetypes to understand how integration's impact changes for software companies through their evolution. No two companies will address integration the same way, but these common patterns will help keep you on the right track.