Episode 446 | How to Build More Successful Integrations

Mike: In this episode of Startups For The Rest Of Us, Rob and I are going to be talking about how to build more successful integrations. This is Startups For The Rest Of Us episode 446.

Welcome to Startups for the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching and growing software products whether you’ve built your first product or you’re just thinking about it. I’m Mike.

Rob: And I’m Rob.

Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. How are you doing this week, Rob?

Rob: Doing pretty good, man. Just doing a lot of work on TinySeed. It’s been fun to start have more and more exposure to more and more startups. We’ve had a lot of exposure to a lot of different founders of startups over the years through all the stuff that we do with MicroConf and book, blog, podcast, etc. Then I felt like I leveled up when I started angel investing and got in depth views, ongoing longitudinal of a more companies and TinySeed feels like another leveling up for me. It’s just seeing a lot of different data, a lot of different applications, and seeing what’s working, and what’s not, tactics, strategies, approaches, even what is working with the founders who are successful and not, that’s been a fun thing to continue to begin to.

Mike: That’s cool.

Rob: How about you?

Mike: Well, on my end, I’m in the midst of rolling out some Bluetick updates. The main focus here is to provide, I don’t want to say platform, but more of a mechanism for me to do more in the future in terms of displaying emails inside of the applications. Right now, I can send emails out and you could see those emails, but you can’t see the replies to those emails in there or see the history there. Some of these updates are going to allow people to do that and also, give people the capability to inject Bluetick into existing conversations which is not something that it’s capable of right now.

I had actually answered somebody’s question through Twitter the other day. They were asking, “Can it do that?” I was like, “Not yet, but that’s on the roadmap but it’s coming soon. It’s coming in the future.” This will put me in a much better position to be able to do that. And then there’s also various things with the Google authentication stuff that’s in there. Frankly, I’m worried about how that’s going to turn out because it’s a completely opaque process. I have no idea what the end result is going to be so I’m still, I don’t want to say sweating it out, but what is going to be the end result of this.

Rob: Sorry. I don’t know what else to say. That sucks. Goodluck is probably…

Mike: I guess. I mean, there’s really nothing to say. It’s just waiting for them to go in. I don’t know what their checklist looks like, I don’t know what they do or anything. It’s a huge hole, I’ve no visibility here and it sucks. There’s nothing I can do either which is the worst part. It’s just they’re going to either approve it or reject it and they’re going to move on with whatever their timeline is which they’ve been fairly vague about until just very recently where they’re like, “Oh, yeah. You only have three days left.” I’m still waiting to hear from them so if anyone here works in Google and is involved in that process, please email me.

Rob: Yeah, email Mike. Due to some recent fixes that I mentioned last episode, fixes to our WordPress theme, comments are now appearing to end-users and there were a couple that I want to read through.

Episode 436: How to Respond to Customer Suggestions. Steve says, “Great podcast. I’ve made every mistake mentioned in here plus a few more. We have one additional solution while working with customer request. I had found that if a customer wants a specific feature and it makes sense to them in a product, though they want it now and you see it down the road, charge them to put it in now. We charge it as an expedited feature release, it has helped us grow Skills DB Pro…” which is his product, “…to an enterprise level offering while getting paid along the way. One more bootstrapping thought.”

I think that’s a good one. It’s not something that I tend to do with SaaS apps, but back when I had these one more time downloadable stuff, we definitely did it on a number of my products especially the ones that were smaller where a few thousand dollars and kind of expedited feature, this actually moved the needle on the product versus if you’re doing million or more, worst if you have a seven-figure SaaS app then try to charge a few grand to expedite a feature, it’s almost not worth the hassle is how I found it. But I think that was a cool suggestion that some folks might be able to take advantage of.

Mike: Awesome. Anything else?

Rob: Yeah, we have a comment on episode 437 where we talked about MicroConf Europe. I think this was back when we were still trying to figure out where it’s going to be or maybe we even said Croatia, but Rob said, not me, a different Rob says, “Come to Barcelona.” What do we say to that, Mike?

Mike: Do you live in Barcelona?

Rob: No. Well, that’s the first thing because everybody wants us to come to their city, but we have. We came to Barcelona twice.

Mike: Yup.

Rob: We tend to go to cities two years in a row and then we move on to keep things varied. Episode 440, How to Build Case Studies That Don’t Suck. Sarah said, “Great episode as always. You mentioned a book called the Hero’s Journey. There seems to be a few around with that name, can you give any additional details of the right one?” I don’t know if I mentioned a book, but I did mention Joseph Campbell’s Hero’s Journey. I never read a book about it. I tend to go Google and there’s this amazing diagrams and in-depth articles. I mean, the first result on Google is amazing, and it’ll give you the whole overview. Then maybe Joseph Campbell wrote a book called the Hero’s Journey. You can totally go to Google for that but frankly, just getting the idea of what a hero’s journey is like is pretty easy to do from the googs.

Last comment for the day, episode 441 where we answered some listener questions, and then in our aftershow, we talked about the first MicroConf Dungeons and Dragons game. Patrick Mckenzie, his character died early on and he became the final enemy, he was the boss, he was voicing the boss. Christoph Engelhardt chimed in and he said, “My biggest question is what kind of enemy in Dungeons and Dragons game constantly mutters ‘charge more’. Okay, I’ll see myself out.” I thought that was worthy of mention. One of the few funny lines I’m sure that will happen in today’s episode; one of the very, very few, Mike.

Mike: I don’t think I’ll be in any of this.

Rob: That was it. That was all one and done. Today, we’re talking about successful integrations. You want to dig us in?

Mike: Sure. I kind of based this outline loosely on some of the challenges that I’ve encountered integrating with other apps, taking Bluetick and just whether it’s integrating with IMAP servers or going into Zapier or other third-party applications or even using certain libraries, like code libraries. Some of this is retrospective like, “If I were to go back and do it again, how would I approach it?” Because there’s certainly things that I look at now and I would’ve done very differently and then there’s other things where I don’t know how much I would have changed or how much it would have changed, what the end result of that was. I think that these are the things that I’ve learned along the way of doing it and that are generally applicable to most people if they’re going to look to integrations.

I’m sure you have a ton of experience here in terms of taking Drip and integrating it with, I think it was like 30 or 35 different other applications, and incorporating them with Drip throughout it’s, I’ll say, rise to fame.

Rob: Yeah, I mean there was that, there was HitTail. I did, I don’t know, it wasn’t half a dozen, but it was approaching that, DotNetInvoice did a few. I had multiple apps, many apps I would say, that we’ve done integrations. Some successful, some not, some technically successful but revenue-wise, they weren’t that great and then others that were pretty simple and easy-to-build that wound up having a big impact on revenue. Yeah, a lot of learning and some do’s and don’ts along the way.

Mike: Before we dive in, what I want to do is provide a definition of this so that we’re working from the same page here. I’ve loosely defined integration as, it’s a part of your business where there’s something that’s handled internally and is reliant upon a third-party. Essentially, it’s outside of your direct control and there’s varying degrees of visibility and influence that you have over whatever the processing is or procedure or how it works. Some of the examples of those are things like code libraries or third-party APIs. Baremetrics, for example, is heavily reliant upon Stripe’s APIs. If those Stripe APIs went away, the business goes away.

I think a lot of discussions we’ve had in years passed about integrating with Twitter is they decided on a whim to go a route and either change the process of who is authorized to interact with their APIs or who has them available or even what you can do with them. Obviously, all these large companies like Google, and Facebook, Twitter, they all have varying things that they want to do in the future and those may directly conflict with you as an entrepreneur. These are areas of risks. Those are the types of things that you want to keep in mind when you want to integrate with somebody or something outside of your company. That could be software integrations, it could be business processes, it could even be a joint venture that you’re doing with somebody.

But I think the focus today is going to be more on the technical side of things but also taking into account the inter-business relationships as well because you have to know that the person you’re working with or the business entity on the other side isn’t going to totally screw you and if they do or if they could, what ways might those be. It’s really just providing some visibility to those areas of risk.

Rob: Right. Building your app on someone else’s platform where if they turned off the knob, you would lose 50%-80% of your revenue overnight, that’s one thing, and that’s platform risk. You can de-risk it by going to multiple platforms, sometimes you don’t need to de-risk it. It does impact sales multiples, if you ever try to sell a SaaS app that is entirely reliant on a platform and you don’t have an official contract, it’s a risk, so it requires to look at it and factor it in.

We’re not going to dive into all of that today. This is more about building individual integrations. You’d think about Drip that has all these incoming stuff from Stripe and from Shopify and from Event Pride, any one of those going away would have been a bummer because people want it and used it but it would not have been business-ending. That’s really more of the integrations we’re talking about today. We’re talking about both the process, the dev side of building it, the business development side of, how can you leverage that to get more customers and leads and we could touch on like deployment support and that kind of stuff.

Mike: As you’ve said, the best case scenario is really, if something goes away maybe you’ve lost some time or money and that’s about it but the worst case is everything that you’ve built is effectively gone and that kind of leads towards building on somebody else’s platform and you just have to evaluate that as a risk. We’re going to start through this list.

The first one is what level of effort is going to take to build something. I’ll […] up this by saying that I think in most cases, your estimate to build an integration are going to be too low by a lot. That will change over time as you get more familiar with building integrations and you create more infrastructure in your own application in order to build those things but what I’ve found is that there’s a few different places where I thought things were going to be in a certain way and it turns out that they weren’t.

For example, documentation is an area where when you’re trying to build a third-party integration or integrating to something else, I found documentation tends to be lacking, even if the documentation is there and it seems to be extensive, what I’ve found is that a lot of times that documentation is inaccurate and it’s because companies don’t keep their documentation up to date. There are places where it will say one thing and is absolutely not true or it documents in a certain way and it says, “Hey, this is how it works.” When you go start implementing it, it turns out it doesn’t actually work that way. These things sound like they shouldn’t be that big of a deal but in some cases, they really are. If you designed everything in a certain way, those things really throw a wrench into your plans.

Rob: Yeah. There’s an interesting X factor or a variable that is outside of your control that gets thrown in when you’re dealing with someone else’s API. It could be bugginess or it could be docs that are out of date. There’s a bunch of different things. It’s different when you’re just building your own app. You know there are going to be things that you can’t control in terms of, “Oh, I run into this problem. I couldn’t solve it quick enough. There’s a bug I couldn’t find for two hours,” or whatever, but external APIs can be one of the most frustrating things to develop against.

Here’s the thing, we got to the point with Drip since we’ve built so many of them, we basically almost by looking at documentation and whether we knew the founders or not, whether it’s a big company or a small company, we could gauge like, “Oh, this is Fortune 500 integration and they’re using SOAP. This is going to take a week to build,” versus, “Oh, it’s a REST API written by some […] developers that we know. We can probably literally build what we need in four hours.” I mean there were integrations we would get done in half a day. It’s because we have a whole repeatable system and a bunch of code on our side to help do that copy/paste and polymorphism and that kind of stuff but we would ballpark engage, “Yeah, I think this one is going to be a lot worse.” It’s like all APIs are certainly not created equal.

Mike: Another thing I’ve run into is there’s time that you’re going to have to do some sort of black box testing to figure out how things really work especially when you’re going up against external resources or external APIs that are providing data for you. Interesting thing I ran into was there was a code library I was using that says, “Oh, if you pull this information back, you get a list of strings over here and you get a list of integers over there and they represent the same thing.” Early on, I was trying to work with those and pull the data back and one of them took five seconds and the other one took 60 but it’s supposed to be identical data. The numbers, the integers should have been a lot faster and they weren’t. I ended up using just the strings, that worked fine.

Recently, I’ve gone back, and I’ve been doing some more test performance on that section of things and came back and said, “Why is this taking so long? It shouldn’t take that long.” I found some access to some additional logging capabilities and I printed it out and it turns out they’re actually returning not just those numbers but also a set of dates. I was like, “Wait a second. Why is this requesting dates?” It’s not even actually requesting one of the information I asked for, it’s requesting this other thing, and then just interpreting it and throwing those integers in there. It actually doesn’t even work. Like, “Wow, that’s just painfully wrong.”

Rob: That’s amazing.

Mike: Yeah. It works but only because of some other thing that happens to be going on. It’s issuing the wrong command to the server but those are the types of things that you’re going to run into and you won’t, since you don’t have the visibility into those things, you can’t troubleshoot somebody else’s code or somebody else’s server. It makes it difficult to find those things and it just takes longer. You have to do timing performance, benchmarks, and see how much memory allocation needs to be done for different things. You may not be able to do everything all in one shot. Those are the types of things that—it just takes longer, makes the process of implementing especially the early integrations that you do, just makes it take that much longer.

Rob: Here’s something I’ll say on how to streamline this. If you’re only going to build a few, then just do what you’re going to do and go straightforward. There are reasons to do this: a, it makes your product more sticky because you can get data from more places and therefore users get more value out of it; b, it makes your customers lives easier; and c, it can be a co-promotion opportunity. Off the top of my head, those are the top three reasons to do it.

If you’re going to build a bunch of them, then you’re going to want to standardize on the code side and like I said, develop something where it’s easy to just pop them in, you don’t have to build custom UI for each one. I mean, again, look at the Drip UI and we just pop an item in the dropdown list to add the next trigger or action that’s triggering something in Drip or sending out an action, something that goes out of Drip.

The other thing to think about is or the way we were doing it was, if I recall, we have three levels. We had a V1, V2, V3 of any integration that we did almost without fail where we would build a very simple integration first, and that was our V1, and that would typically take less than a day to build. Sometimes, it only had one or two triggers, one or two actions, something like that. It was easy to build, we’ve got two, three API, we’d push it live, we’d promote it, we’d see who used it, we’d see the request.

The best-case scenario is that we’ve got a bunch of people saying, “Oh, this is cool except for it doesn’t do this for me.” It’s almost like customer development where we’re iterating on the feature, almost like it was its own product because Drip had—off the top of my head—I’m going to say 20 different triggers and Stripe has 20 or 30 different actions. Well, there is no reason to build essentially 50 endpoints, 20 in and 30 out. Again, don’t quote me on those exact numbers but you get the idea of what I’m saying. There’s a lot. It’s a lot of work, it’s a lot of code to do.

If you build two in, two out, pretty simple, you throw it live and then as people ask for stuff, you can add another one in almost minutes. I mean, you have to write unit test and stuff but it’s very trivial to add. If you get enough people asking about it, well, you take it to that next level where it’s a tighter integration, you can add OAuth later. At first you can paste an API key which is a little janky but then OAuth becomes the V2, and you just build tighter and invest more in that, the more people who use it. That was how we did it and it seemed to work out pretty well in general.

Having the ability to watch the actual user behavior on your integrations before investing weeks of time is hugely valuable because it can save you a lot of time. There were integrations that we built, that V1, and 20 people used it out of thousands of customers, and we never did OAuth and we never added that extra week or two of development on it because there was no business case to do.

Mike: What I like about the strategy you just outlined—doing the V1 and then V2 and then V3—is that it allows you to come back and start very simple. Then as you start to see the technical problems with it, but also the features and functionality they’re missing, that customers are asking for, it allows you to fill them in afterwards. You don’t have to worry about as much about going back and rewriting some of those things that you’ve already built in order to satisfy what the customers need because you didn’t build very much to begin with. You did it really more or less to help pull that information out of the customers and find out what it is that they wanted and then take that forward.

That’s actually a mistake that I’ve probably made early on with integrating with Zapier is that I put too many things in there, but it was partly because customers were asking me to do a lot. I don’t what to answer how I would change that, but I think that I would probably spend a little bit more time on going back and verifying with Zapier directly like how this should have been done.

Rob: Yeah, it’s easy to over build. You get in there and you think they need to be able to do everything that they can do through the Bluetick UI or everything that the API offers, they need to be able to do that in Zapier. I would say that’s not true for a V1. You may miss something, but take your best guess, 80/20 it. What are the 2 out of 10 things that you think or you know people are using or your gut feel of what you think they’ll use which is sometimes you just don’t have the data and then pop it in. When they’re like, “Oh, I also want to do XYZ.” Well then you put that in your queue, and you build it out as soon as you can.

Integrations are—they’re a curious thing because I remember with HitTail, we skipped this with Drip too, but it was like, “Do you integrate with Shopify?” It’s like, “What do you mean by that? What does an integration mean in your head? Does that mean that we’re taking data in from them and we’re triggering things? Does that mean you want us to pull data and display it as a report? Does that mean you want us to push things into your Shopify store?”

Same as Stripe, “Do you integrate with Stripe?” It’s like, “Yeah, we do but what do you need it to do?” It was often digging in questions and then they would have a use case typically. It’s like, “Well, I want once someone purchase, I want to be able to mark them as a customer and drip.” It’s like, “Well, yeah, of course. We do that.” Or, “Once an invoice is created on the second Tuesday of every month, I want this and that to happen.” It’s like, “Oh, we don’t handle that use case, but we can build that.”

Saying integrating with Basecamp or Highrise or with Slack, that can mean a whole slew of things. Integrating with Slack can literally be, “Oh, I’ll just dump a message in there when someone says something.” It’s an integration but it might not be what everyone has in mind. You often want to dig in if people are asking for these things and find out really what is your exact use case and then just build those one at a time but build it in a framework such that it’s easy to add other functions.

Mike: Yeah. The question that I’ve kind of usually responded to for those types of request is, “What is it that you’re trying to do?” Because usually, that’ll entice people enough to give you the information that you need to either extrapolate it or what you need to build or what sorts of things they’re trying to do and whether it’s even remotely possible. If it is, then you can dig in a little bit more with the technical stuff but usually, at a high-level, it gives you enough information to say, “Yes, this conversation is even worth pursuing or it isn’t.”

Rob: Right.

Mike: Next step we’re going to dig into is the actual API integration itself whether you’re calling an external API or they’re trying to call back to yours from an external application. What I found is that, because there’s so many different ways to design an API, it’s probably not going to be likely that your API is going to be able to be used directly by the other application. This applies whether it’s having to respond to webhooks or accepting them or tracking them or just make external function calls.

If you have an external application that’s calling into yours, they already have a standard way of doing it. You may need to change how your product works. If you’ve already built an API, it may not be the easiest thing in the world to change your API especially if you have other customers interacting with it or your application depends on it. Bluetick for example is a single-page application and it’s got an API specifically for the app itself, it’s also got a public API and then I have additional endpoints that I’ve created.

This is one of the, I’ll say, hacks that I’ve learned is that creating your own dedicated endpoints for other apps could be in your best interest to do. It sucks to have to maintain them in addition to the other code that you have, but it may be the best way to go about providing a mechanism for them to talk to your app without having to rewrite all the different things in your app. Even if you would have just two of them that need to call into your application, they may be doing things differently between each other and then your application may be doing something else as well which makes it hard. You can’t standardize on one thing that’s different for three different people. A dedicated endpoint for each of them is a good way around that. I won’t say the best way, but it is a way that is workable.

Rob: Another thing to think about is rate limiting. I think I’ve talked a little bit about how segment, well, there are few people, segment was the most notorious for it a couple of years ago, but they would accidentally DDoS us. Someone would activate something, and it would just hammer your API and we had rate limiting in place. We had a Ruby Gem that basically sent back, I believe it’s a 304 response, 403, there’s some response where you encode. It’s like, you’ve been rate limited, you can send this much per hour, and wait this long before you can send your next batch and they just weren’t honoring that. There were several that weren’t honoring so you have to code the work around those. I know that Zapier has rate limits and we coded early on to help with those.

It’s one of those things that in the early days doesn’t matter and as you scale, it matters a lot because it’ll either take your API down, it could take your app down, your database down, it can take web servers down, or it can mean, if you’re not queuing things and you’re hitting and you’re getting rate limited, you could lose customer data. If you are queuing them, it could back your queues up because you have all this retrial logic. If a failure happens, it’ll just fill your queues up and say you have to expect rate limits and it’s a bunch of code, it solve problem logically but it can require a lot of code on your end to properly implement rate limiting.

Mike: Another thing that’s similar to that which is parallel request. You may end up with request that are coming in on your API that are close enough to each other where if that resource doesn’t exist, for example, then it needs to be created. If you don’t have your transactions set up properly in your code, then you can end up with duplicate resources created inside your app and then suddenly, things start to fall over because it’s basically what amounts to a raise condition, which you never would’ve run into in normal interactions with your app because users aren’t clicking on things with milliseconds between each request. If that happens to your app, if it’s coming to an external API, that can easily happen. You do have to be careful and cautious about those types of things which some frameworks are good about transactions and some are not so much.

Another thing to think about when you’re looking to integrate with an external API is what customers are using that and what visibility do you have for the other side of things. If you’re receiving commands or queries from another system, can you log into that system and see what has been initiated, can you see what has been satisfied, can you see the errors that we’re running to? Because a lot of those things, you may not necessarily have the information on your own servers like there could be requests that’s going out. You may see the request come in, but you don’t necessarily know if it was responded to properly or it’s sending back the wrong data.

If your code is incorrect or it’s not responding properly, how would you know that? The only way to know that is to go to the other side and look from there. Being able to monitor things both internally and externally is important. You don’t always get that external viewpoint that you need, and you may not be able to track them down to particular customers either. If you see an incoming request not just, why did it come in, and where did it come from, who is the vendor, but what customer of yours is that request associated with. If you can’t see those things, it makes it difficult to troubleshoot, it makes it difficult for you to offer support for your own customers.

Rob: Another think to think about is when you are building the integration, who can you contact for support. Is the documentation—we’ve already covered a little bit—is it good, is it buggy, is it correct or not? Do you have email access, phone access to a developer on there? Because you’re going to run into problems, and do you have access to a developer? Do you just email their general support that they have specific integration support?

We love integrating with the three-person startup where two of the founders were developers. I mean, those went so smoothly, they could fix things so quickly, and they knew how everything worked. You’d email them and be like, “Hey, there’s a problem here. This is the result we’re getting.” And they’re like, “Fixed.” It was so good. The larger the teams get and if you’re sending an email again, to Salesforce, to their support, to try to get integration, it’s an absolute nightmare. You hear back a week later, and they don’t understand your question at all, and they don’t escalate you, blah, blah, blah. Those are kind of the two extremes that I’d point out but it’s something to think about when building this.

Mike: The last one, typically comes around when there are webhooks of like, “How do you go about testing them?” This also applies to just you sending information over but how do you go about making sure that the stuff you’re developing has a test area on the other side? Are you working with production data? I would hope not but there are cases where you are going to have to do that which means that you have to create an account on their side and use that to do all of your testing and effectively it’s in production but on your side it’s not. That makes it hard because you have to keep things straight locally like, “Oh, is this information here that we’re working with in production or not on their side?” You may have internal flags or toggles or fields that you use to keep track of that stuff, but it can get complicated especially if you’re trying to document that. It’s got to be documented in places where it’s easily accessible by you to understand what’s going on both side and which environment it’s going on.

Rob: And then, as you get it built, there’s going to be an approval in publication process and again, with smaller startups there’s typically not much of a process. You send an email, you say, “Hey, this is live. We’re going to push this live in our UI next Tuesday.” They’re like, “Cool.” With Zapier or Salesforce or someone who’s doing a lot of integrations or having a lot of people integrate with them, they are going to have a process, they’re going to have a checklist of requirements. You’re going to want to look at approval timelines because I know some apps take weeks and/or months to get approval publication timeline after it’s approved.

Is there a beta period? This is something that Zapier I think does well. It feels like a pain when you’re doing it, or it feels like hoops to jump through but they’re doing it because they want to keep the quality of the service side. If they don’t have the beta period and all that where you have to get 10 users using it because they want to force you to work out the bugs basically. I think they do a good job of that. Then how will you get support during beta? How will you provide support to your folks during beta? It’s all things to think about to get it live. Oftentimes, writing the code is the least time intensive piece of this whole process.

Mike: Yeah. I think the piece of this process that does take the most time is just making sure that there is that trust factor there on both sides that, “Hey, this is going to work and is generally going to be good for everyone who’s using it but if it’s not working or it’s buggy or there’s problems of any kind where there’s transaction delays or things are just overly slow or they’re using too much memory or there’s scaling issues on either side, all of those things can essentially erode the credibility of the integration.

At that point, one side of the other is going to want to back things off a little bit and introduces this additional delay. Delay factored just from becoming comfortable with it is important, but you also need to have ways to resolve that. This begs the question of, “How are discrepancies or disputes handled” Those disputes or discrepancies can be like, “We expected this data, we got this data instead.” Or it could be something along the lines of, “This isn’t working right. Why is it taking so long?” Or it maybe it could be a designer or an architectural issue, “Oh, you said that you want to send us data XY and Z but it’s also including this other thing. Why is it doing that? I don’t think that it should.” You have to have someone resolve that.

Sometimes, you’re talking directly to developers. Sometimes, you’re talking to an anonymous email box where you have no idea who’s answering it or what their ability to make change is or even knowledge of the entire system is. Each of those is going to be a different approach but they’re things that you have to be aware of especially when you’re working with larger companies or smaller ones.

Rob: Then something we’ve alluded to several times during the episode is I mentioned there my top three reasons for building integrations and one of them is the comarketing opportunity, the business development so to speak, which is to be able to both promote who you’re integrating with and for them to promote you in one way or another. There are a lot of ways to do this such as joint webinar is a pretty good way. You think about it, if you’re integrating with another startup, you both want the exposure to each other’s audience. If you’re integrating with Stripe or Facebook or Google or whoever, you’re not going to get that, but it’s nice to think about high-touch opportunity to show how the integrating works and the benefit it provides—so joint webinar is one.

Certainly, I found a lot of success with the joint email. We email our list, you email yours. Copromote blog posts also on both announcement blogs for each company. There are the functionality updates whether they handle that via email or in-app or whatever. You can offer in-app announcement on both. Even providing customized landing page that says, “Welcome, Pipedrive users. Welcome, Stripe users.” That they can link to from the other place that you can get is in their app directory, their integrations directory. There’s typically one in the app and out on their public market website. That’s another place you want to be.

From there, we found that building custom landing page for some of them, but not all, worked really well and increased conversions quite a bit. There were a couple of integrations where the clickthrough from the in-app or from their integrations directory on the marketing site to our landing page and then sign-up for a trial was something like 30%. It was outrageously high. We asked for credit card upfront. Typically, the number is very small, and it was 20%-30% and it was shocking. We did so much to tune that page and split test it but the ones where we were getting 3% or 4%, you obviously don’t care as much about those.

But those comarketing opportunities can be fascinating because if you get a big email sent out to 30,000 of their marketing list or customer list or whatever, you can get a nice bump there. But then if you get in their app directory or you get in these other longer, living links basically, you not only get the SEO juice from that, but you then get that flywheel of traffic. I’s not huge, again, maybe it’s 100 visitors a month, so it’s not a huge amount but if you’re getting 10%, 20%, 30% of those to sign-up for a trial, that’s 10, 20, 30 trials every month that shows up. Then you multiply that by 10, 20, 30 integrations and you start to see how you can potentially build a flywheel out of this.

Again, you can’t just take this advice and apply it to your app without thinking, “Does this make sense? Is it going to provide the value? Do I have the leverage for these folks to do all of this?” That is the integration marketing playbook that can help grow your business not only as a one-time thing but as a sustainable approach. With that, I think we’re wrapped up for the day.

If you have a question for us, call our voicemail number 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt. It’s used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for full transcript of each episode. Thanks for listening. We’ll see you next time.