Why you shouldn't build user-facing SaaS integrations yourself cover

Why you shouldn't build user-facing SaaS integrations yourself

Hassan Syyid profile image

by Hassan Syyid

Jan 31st 2022


If you’re building a SaaS product it's only a matter of time before users start asking about integrations

Whether you’re building:

  • accounting software that needs to pull invoices from Quickbooks, Xero, and NetSuite
  • sales software that needs to pull CRM data from Salesforce, HubSpot, and Pipedrive
  • reporting software that needs to pull analytics data from Google Analytics, Mixpanel, and Heap
  • or any other type of SaaS platform you can think of

The trend is the same: customers want to try your product with a self-serve experience, and they want your product to seamlessly integrate with the other SaaS platforms they use.

So, how do you build that experience?

Well, what does it look like?

Before I go further, I find with developer tools it's usually easier to show than tell. Below is an example of what a decent integration experience looks like.

The example shows a user of a demo product (Example Company) connect their accounting system (Quickbooks Online). All the user has to do is log in to their Quickbooks account – easy peasy, right?


Don't build it yourself – no really, don't.

As a developer, your first impulse will usually be to build it in-house. After all, don't all these platforms have open APIs? How hard could it be to get the data I need?

You're right. For one integration, you could likely build it in-house with a small development team inside of a month and start onboarding users.

The problem is the next integration. If you already built an integration with Quickbooks and are busy onboarding users and iterating on your product, who's going to build the Xero integration? Soon enough, your development team will have a backlog of integrations they need to build.

To make matters worse, these APIs may be open but they are far from unified. For example, here's what an invoice looks like in Quickbooks vs Xero:


Hint, hint: They don't look very similar – and that's just one object

As you can see, there's quite a few reasons to avoid building all these integrations in-house. Especially because other developers have already built the same integrations. Just look at GitLab's Meltano project, which has a whole library of open source connectors to all sorts of SaaS APIs.


If you're looking to build integrations for internal company data, I'd highly recommend checking out the open source Meltano project I mentioned above.

A small self-promo

We believe an engineering team's time is more valuable when they're doing things like building new product features, squashing bugs, and making the product awesome.

That's why we've been working on hotglue – a free tool for developers that makes building user-facing SaaS integrations 10x easier. Beyond handling authentication, hotglue makes it easy to preprocess raw data from these APIs, send the final data where you need it, and orchestrate data syncing scalably.

If you're currently looking to build integrations, I would love to talk with you and see if our platform can help.

Closing thoughts

I'd love to hear how you may have already built your integrations, or how you've thought about building them. What pain points were there in that process?

Thanks for reading! 👋