14
27 Comments

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

Introduction

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?

hotglue demo

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:

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.

Conclusion

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 about our free beta

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! 👋

  1. 5

    I run a multi-step form builder, where users want to send their form submissions to various sources (salesforce, hubspot, etc).

    We survive with Zapier, but there is value in an easily-configured "native integration" like this, as it means my end users don't have to pay for it (and don't rely on configuring a 3rd party).

    Don't understand the negativity in this thread - keep going, looks like an awesome product.

    1. 1

      Thanks – I definitely agree with you on making the process easier for end users!

  2. 4

    This framework approach to building SaaS integrations internally, not outsourcing them to an "as a service" product, is where integration is going for sure.

    We're doing something quite similar, built on an open source framework called Open Integration Hub. It's particularly well suited to moderate-to-high complexity integrations where the simple "extract-transform-load" pattern isn't sufficient.

    The vendor lock-in risk that an embedded iPaaS introduces for a SaaS company is a tough pill to swallow. So, while we approach it differently, I 100% agree with where you're headed here.

    1. 1

      Just checked out Open Integration Hub – seems pretty interesting! And yes, I totally agree. The vendor lock-in risk is definitely something to be wary of especially with newer solutions like ours. But hey, you get the same risk when you use something like Stripe too – I think embedded iPaaS solutions are just less common.

      1. 1

        I've been thinking about the comparison to Stripe a lot. In fact, at one point I was fundraising (to start our business a different way) and I used to say "Stripe but for product integration".

        Here's where my head's at now: integrations are fundamentally features of your product, albeit ones that cross-over with another product. Billing is a necessary utility. Your customer doesn't get value from your use of Stripe--at least not really. They do get it from any integrations you build.

        Probably not a clear delineation, as I've described it, but I think there is one.

        1. 1

          Yeah, I definitely understand where you're coming from. I think the end-result for us may be that the core functionality becomes open source – I think a lot of embedded iPaaS solutions have realized that once they become more than an OAuth wrapper users are (understandably) more worried about vendor lock-in. The beauty of an open source approach is, the developers retain full control over everything and things like lock-in become slightly less worrisome.

          1. 1

            You're speaking my language, brother.

  3. 3

    Integrations are one of the best ways to grow a SaaS business, and accordingly deserve time and effort. Every SaaS business should build out their own Zapier integration as a minimum, and then prioritise other integrations like they prioritise any other feature request. As you launch integrations then partner with those firms to do partner marketing and build your backlink profile.

    It shouldn't be a case of spray and pray, integrating with every platform under the sun, in the same way you wouldn't build out every feature under the sun. Spend time on them and make them genuine partnerships.

    It's also worth saying, that with an open API integrations are one of the easier things to outsource to 3rd party developers, should development be a constraint.

    1. 1

      I agree with you on this point.

      "Spray and pray" integrations are definitely a terrible move – as I wrote above, the typical flow seems to be that developers build one strong integration and flesh out their feature set. From there, users request new integrations and the engineering team builds them. I am in agreement that building up integrations that way is the right move – like you said, these are important to users, so they should be important to developers too.

      When I wrote don't build them yourself, I really meant don't build them from scratch. Currently every SaaS business (as you mentioned) builds integrations – and a lot of that process involves boilerplate and orchestration of infrastructure. My point here was there should be a solution that minimizes the development work it takes to build great integrations.

      1. 1

        Anything which minimises dev work is great, although this hasn't been the biggest blocker to integrations in our experience.

        BUT if there is an open-source platform which does reduce work, we'd be stupid to not consider it and would very much support that movement.

        Integrations are so integral, both to users once built and to the growth of the business, that it'd need to be open source, rather than perennially committing to a 3rd party.

        1. 1

          Literally this is what we're doing. Would love your thoughts on it, if you want to connect offline. Maybe a good fit for you guys, but at the very least, would love the feedback.

        2. 1

          Yeah, I was just discussing this in another thread. Obviously our product is still early in development, but we have been considering going the open source route. It seems like with integrations being so close to the core business value that vendor lock-in is a risk most teams aren't willing to take. Thanks for the feedback!

  4. 2

    I thought your product was affiliate with Hotjar, as the icon and font are quite similar.

    But I don't think it is, right?

    If there is no affiliation, here's some friendly feedback: I find it a turn off that you've appropriated someone else's brand... kind of makes you less trustworthy. You've got a cool name for your product, there's definitely a way to brand yourself differently to Hotjar :)

    1. 1

      Thanks for this feedback :) – I was unaware that the branding was similar to Hotjar (now that I am looking at Hotjar, I can see some similarity). I'll take this under consideration. Cheers!

  5. 1

    Your advice is solid. We as devs should stay away from doing this type of work and put the time on the features that are actual differentiators.

    As a side note, I'd humbly suggest you to review your logo. It looks strikingly similar to hotjar and even if you might keep it without any legal implications, the similarity won't play in your favor from a marketing perspective.

    Best of luck!

  6. 1

    So, did not get it. Why not integrate with zappier or integromat?

    1. 2

      Zapier and Integromat are good solutions for giving your users trigger based connections to their apps that they can manage. On the other hand, the integrations I was referencing are those that sit within your product. There are actually quite a few SaaS apps that support both of these approaches. The benefit to having them sit in your product is that it's less work for your users – instead of setting up a Zap, they just login and your software takes care of the rest.

      Another point mentioned was that with Zapier or Integromat, your users bear the cost of integrating with your platform. On the contrary, an embedded integration moves that cost (if any) to you.

      1. 1

        Ahh i see now. White label integrations. Sounds good. However you will be hard pressed to catch up to these services. Though if, for example, most of my users require activating campaigns for marketing then you could potentially cover many of them. Like hubspot, mailchimp etc... that would be great. I would say that a combination of your service and zappier or integromat will be best. Then again looking at your pricing it means i will have to charge 0.2$ more for all users, thinking they may use your integrations, as opposed for zappier collecting per usage, lowering my price attractivity. It may be problematic for your customers which are not charging per usage.

    2. 1

      There are also different types of integrations, in terms of complexity and necessary user input. Those are phenomenal products for dealing with a really wide range of mostly pretty simple integrations. If your product requires ERP integrations or complex enterprise integrations or integrations to legacy software systems, they really don't meet the need.

      I usually advocate for a multi-strategy approach with your product integration portfolio, and often it makes sense to use one/both of those to handle a certain subset of your integration use cases.

  7. 1

    I think you are talking to the wrong audience here and you should have posted in the No Code-section?

    The process shown above is an Oauth2-authenticiation. Most services which provide an API provide example code and/or libraries for the most popular programming languages.

    The actual processing of the data itself (second screenshot) is not unified by your service? So, there is only the benefit to do the authentication - which, doesn't make sense to me because the authentication would have to be done by my customer to access their bookkeeping-tool. That means, my customer would have to leave my application to do a complete setup with authentication, job schedule & storage only to use my application? No way :)

    1. 1

      Hi there! On the contrary, what we're building is not just an OAuth wrapper. hotglue is focused on exactly what you said – the processing of the data.

      To take it a step further – we're also not a no code tool. Our thesis is that developers who build SaaS integrations need to retain control of the data, so your customer does not leave the application for authentication, job scheduling, or storage. Instead, we enable the following:

      1. Developer configures what sources to support and writes preprocessing scripts in Python (takes raw payload from API and extracts whatever you need)
      2. Developer configures where processed data should go (ie. S3 or some database)
      3. Developer builds simple OAuth flow (either using our wrapper or building it themselves)
      4. Developer sets a job schedule which will handle syncing user data on our infrastructure.

      So the real value is exactly what you're talking about: preprocessing raw data from these APIs, storing the data from those APIs, and orchestrating data syncing scalably.

    2. 1

      This comment was deleted 3 years ago.

  8. 1

    I have know Hotglue for nearly a year now. I am a member of the slack group too. Initial attempt to get in contact was unsuccessful.

    The listed data sources seems to not include the ones we are looking for. Is there a way to build custom source on your platform?

    1. 2

      Hi paschal, I'd love to get in touch. I'm not sure how you attempted to get in contact but you can shoot us an email at [email protected]

      Yes, there is! Our sources are all open source and use the Singer framework – if you'd like to build a custom source, you can build it using that framework and hotglue can support it natively. It's worth mentioning that if there's a source not already covered by Singer we can also build it for you

  9. 1

    First you say to not build external integrations to clients but your only recommendation is Meltano which seems to be down...

    When it comes to integration its mostly about how well documented they are. So really no problem. Put most requested integrations to roadmap as any other feature.

    1. 1

      Not sure if the Meltano site was down – you can access their GitLab repo if it is.

      As far as putting integrations on the roadmap and treating them as other features: I would argue that's 100% the way most companies now look at it, but I'm interested to see if that can change.

  10. 10

    This comment was deleted a year ago.

    1. 5

      I'd respectfully disagree with this criticism - OP gave a reasonably high quality argument against building things, even though the "here's the solution" may have been a bit clumsy.

      The advice "build in a proper layer of abstraction, rather than building over and over again" is solid advice, even to those who enjoy building things.

      1. 2

        This comment was deleted a year ago.

        1. 3

          Hi Primer, as I mentioned the product I referred to is in beta – those paid plans you mention are placeholders at this point signifying that one day it could turn into a business. At this point it's really just a free developer tool.

          My goal here was to get feedback on how others see the integration space especially as they're building SaaS products themselves. I mentioned our free beta to give an idea of the types of embedded iPaaS solutions that are now available and get feedback on the concept as a whole.

          I understand how that could appear misleading, but I hope that clarifies :)

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 16 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments