In the last week we have been removing our Xero to HubSpot app from the platform which seems like a major milestone as we remove our first major feature app.
What's behind the decision?
Since the app was announced we have seen some interest however have also had significant headwinds which mean that maintaining the app is not viable at this point in time.
When we built the app we had a clear vision for the product:
- Help companies accelerate their adoption of HubSpot to empower sales with historical sales data. Bootstrapping the sales team's data on both lifetime value and outstanding payments can significantly accelerate the time to the sales team gaining value from HubSpot while reducing manual overheads populating the customer database.
- Create a truly 5* experience for companies migrating their data. There is clearly demand however most of the other apps available have relatively low review rating scores.
- Offer competitive pricing leveraging our platform at scale. As Baack is designed for scenarios like this, powering the migration with low costs meant we could offer a highly competitive alternative.
- Showcase building on our platform. With the flexibility and ease of use we are building for other developers there was also a great story about how quickly we could build a competitive offering.
When we researched the space we found that for the top apps in this space, with around 10K installs the average rating was just 2.5* and we knew we could do better.
Where things came unraveled
As any business or their developers know, building an integration isn't as simple as fire and forget. Any integration carries overhead. Not all APIs are created equally and the cost of building a solution that connected Xero data to HubSpot was higher than we expected, not least due undocumented API behaviours.
Some of the APIs have also been undergoing substantial change. Companies with a significant market position want to migrate developers to new versions to avoid delays in their own product velocity. This can become a challenge for their own internal velocity as they face challenges around the trade-off between maintaining older interfaces and releasing new features.
This particular pain point is something we at Baack have tried to design into our API release process with clear expectations around the payoff for integration. Working on some of the biggest API surfaces online we have seen how the trade-off between velocity and return on investment can be a barrier to adoption. Case in point, for our app features that were built against the 'current' version of a products API only a few months ago is already deprecated for replacement with an updated API requiring significant migration cost. When building integrations or offering new API surfaces we plan based on the migration cadence.
The other key aspect is the maintenance cost of migrating, how time consuming the migrations are. For this app we found that the complexity of building a 5* experience in a space where APIs are undocumented, documented by AI experiencing hallucinations or just downright misleading meant the cost for building something great was very high. Given the relative frequency of updates with this high migration cost it isn't viable for us to maintain the app at this time. With our own APIs we go out of our way to make them as transparent as possible to minimise the cost of migration.
Any integration has to balance the equation: Value > [migration cadence] * [cost of migration].
Barriers to entry
One critical mistake we made in our strategy which may be the deciding factor in this story was a knowledge gap missed around the different app stores listing install volume requirements.
Unlike general app stores like the Google Play store and the Apple app store, which both have quality requirements, business app stores also have scale requirements. This in effect means that you already have to have customers before you can list in the app store to be considered as part of customer acquisition. This lead to our app relying on organic and paid marketing outside the app store which limits social proof for a new app in the space creating a vicious cycle.