On the podcast “The Marketing Automation Discussion”, our cofounder Nash talked about the inception of Integry and how it is creating an impact in the integration space. The episode was hosted by Alex Glenn, an expert in growth marketing, and the founder of Automated.af. He started a platform where experts, marketers, product teams, organizations can come together and make automation happen. Catch the audio recording of the episode, here.
Nash talks about his experience before starting Integry with integrations. He talks about how a customer request made him realize to create an easy integration platform.
Alex: “This month we have spent a lot of time on what’s changing in the world of API integrations. Creating API integrations for your product was once a challenge at an enormous cost, not anymore! Batteries are now included as our guest would say. With today’s options, you and your dev teams can focus on your own product and turn on hundreds of native integrations at will between your app and hundreds of others overnight. Focus on your app and not on keeping an eye on what changes in other APIs.That’s the thing, this episode is for product teams and founders interested in productizing API connections from your application to 100s of others in your UI. We are excited to have the founder of Integry with us today.”
“So we spoke prior to starting this recording about your experience as a VP of Engineering at a Venture back startup in Silicon Valley and having to manage a lot of Zapier accounts for startups. So I would like to go into that anecdote first so that will help illustrate what we are about to discuss today. Can you first mention just a quick background and then we’ll go to that anecdote and then we’ll start the discussion.”
Nash: “Sure thanks Alex, I am an engineer and this is my fourth startup. In my previous company, I was actually an employee. I was the VP of Engineering of the company called Convo. It is a venture-backed company very much like Yammer or Chatter back in the day, a communication and collaboration platform. So maybe back four years, we had this request from a number of customers saying we want to integrate Salesforce with your application. So we put up a team together, we were a small company we put in some of our planning and time. Once we had this integration up and running with Salesforce, our customers really loved it. It changed the pattern of how our customers were using our app overnight and it really unlocked value.”
“Of course, if you are a communication or a collaboration platform like Slack integration is a core part of your product. We went around and asked them what do you want us to integrate next, and we were careful in building may be a list of 50+ integrations. We looked down the line, they were a lot of integrations we had to do. We took a chunk of that and developed a few user integrations. It took us maybe a year to build out 12 integrations among other computing priorities. When we looked at the road map, we had 300 integrations in our apps that our customers wanted to connect with. We thought this was crazy, we could not build integrations with these other apps. So, we looked around at that time Zapier was very popular and still is. We did an integration with Zapier and what happened our customers came and asked us if we have integrations with XYZ. Typically we would have that integration with Zapier, and we would point them to Zapier. The problem with this was, most of our customers were not technical. They were using our product and loved the way it worked. They just wanted to connect these two systems together in some simple way. What we were asking them to do was, Hey! Quit my app. Go to this other site. Create an account. Pay another service. Figure out what action and a trigger are. How does mapping work? It was the first time our customers heard about Zapier from us. It was too much for them, the whole integration experience. So we ended up taking their usernames and passwords. Another reason was to help them if they were stuck creating integrations. We literally had to ask for their Zapier credentials, login and figure out the whole thing. So we managed a bunch of our customer accounts and Zapier accounts. It was really a suboptimal experience. The other aspect of that experience was we really cared about the user experience and shoveling ways users from our site or app to Zapier ended up breaking the whole experience. The whole Zapier experience was not very optimal.”
“But if you looked at our native integrations, they outperform any integration on Zapier by an average of 30x. So, for example, we had an integration with Gmail. Our development team built an app and we also had integration with Gmail using Zapier. It is pretty simple. An email comes in, we want that email to be posted at Convo and vice versa. The Zapier integration started first, we had a head start of six months. Then we started building native integrations inside the app. A year had passed, we saw that the number of in-apps integrations setup was 30x. It totally made sense, right! If you want to connect your app and there is a button inside your app Connect to Gmail right now, the authorization dialogue comes up and in a couple of clicks, you’re done. As compared to the whole process of Zapier, leaving your site and figuring out yourself, there is so much friction over there. We found there is a huge gap in the market for B2B SaaS developers, any SaaS app that wants to have better cleaner integrations. We looked down and we couldn’t find a good solution in the market. That’s when we quit our jobs and started Integry. That’s where we came from. Since then the product has evolved, but it gives you sense where it came from.”
Alex: “I think it’s important to talk about the status of the industry today and where different companies fit in. While Zapier has progressed a lot, Zapier started as purely a one-way connector with the ability to trigger that action and have that update something in another app. You mentioned issues where you had to create Zaps for every single action. In the industry today it’s kind of five different segments. You have two-way connectors, one-way connectors, flow-builders, data-connectors, white-label solutions like what you are providing. You noticed the void, you noticed the issue and you went about to solve the issue and that’s where Integry was born. You are very unique and we don’t definitely have to dive in, just check out Integry. But you and I are gonna talk about the bigger picture here. Talk about what’s going on in the industry and what you believe is going to happen. So let’s talk about this integrator and where you see that role kind of changing for the next months and years.”
Nash: “Absolutely! So this goes about your original point of defining market, players and setting up these segments. This market is really muddy in terms of acronyms, you feel like a gardener. It defines the space as iPAAS which is Integrations Platform as a Service and this is really old. It goes back 30 years something called Enterprise Service Bus. You have incompetent space, whether that’s MuleSoft, Dell Boomi or Informatica, all these larger multi-billion dollar value companies all the way to these new entrants. You have companies that are B2C like IFTTT or Zapier which are directly targeting the end-customers. You have this middle-ground, where you have companies like Workado.”
“We’re all different from that. If you are an app developer and your users need to integrate. What we want to do is, you as an app developer we want to empower you making integrations a solved problem, so you don’t think about it again and again. The way we are approaching that is we want to give you a platform where we have these collections already in place, and we keep adding to them. Once you connect with us, you have the ability to push and pull data from all these connectors. For that very reason, we also have pricing designed in such a way that we don’t penalize you for a connector unlike most of the B2B. We have a hybrid approach between the consumer and the business end, and the part of that is we want the user experience really good and we want to empower teams using integrations.”
“Let me just break down the market over here. There are two to three ways of how integrations are developed in an app, in the market these days. If you’re doing it in-house you have an engineering team who is implanting these integrations, you might have someone from the product, customer success team or sales, who say we need these integrations. It ultimately comes down to the product, it defines what the final use-case looks like and then the engineering does the final implementation. Typically this is at least a few months of an effort, especially if you are an early company you don’t have a well-developed API. Eventually, you start rolling it out, it’s a huge maintenance burden. Our philosophy on that is you don’t want to do that anymore, integrations have become a solved problem using platforms like us. We have a large number of integrations and we give the options of customization, so you can just white-label our technology, embed it inside your app so your end users can now set up these integrations without having to program or do anything at your end. Once you add us inside your app, we want to shift the onus of creating these integrations from engineering to people in product, sales or customer success teams. If you are a CRM, and the person in the product team understands that these are some good integrations that we should make available to our end-users. They can go ahead and use our visual flow builders, build those integrations and just roll them out to their users without having to talk to engineering or run into deployments cycles etc. That’s our positioning in the overall picture with players and all.”
Alex: “So the business model, those of you have been listening and have not gone into detail for different options. You have these citizen integration platforms like Zapier, LeadsBridge etc. Those two have different business models; LeadsBridge charges per connection, while Zapier will give a number of actions that travel through the bridges and they form their business model around how many of those actions actually happened in a given month. Then there is a per-user charge if the user commits a certain amount of actions Zapier will charge your per-action. However, LeadsBridge charges you for the number of bridges you use, no matter the number of users or actions performed. So we’re talking to the founders, CTOs that have knowledge about technology, the development bandwidth, and resources, they have to consider. We are also talking to founders who are growing their company, maybe they have hit the profit, have a small round of funding. In any case, they have to be conscious of where to spend the development dollars. Do we spend these dollars building out integrations ourselves or do we look to a third-party? If we do what are the implications? “
Nash: “Just to touch about segmentation here. If you are a company whether a Small Business or an Enterprise, you have these apps inside your company and you want these integrations to be done within your company. A couple of things I want to add here. What we do is called external integrations and much less internal integrations. Let me walk you through a use case to clarify this better. About 15 years ago, millennials started entering the workforce. A typical example I’d give is, there is Sally who is heading the customer experience department inside a healthcare company. The way millennials work is that they go and pick up the app they want to use within their company. Like, if they want to use Trello they won’t ask IT they’ll just pick it up. Organically they’ll pick up apps they want to work with and this is how they work. This is the very reason that an average enterprise in the US has 1300 apps. This is not IT buying apps, this actually the end-users picking them up. Now if you fast forward, Sally now have 20 to 30 apps which she has to manage now. She is not a very technical person. In a large company, she would end up going to the IT department, which deals with a lot of Sallys. Some of them are higher priorities while some of them aren’t. They would typically call their integrator, maybe Informatica, Dell Boomi etc. and once you’re doing it now, it is going to take six to eight months to get these integrations in place. With 1300 apps, when you’re integrator comes in they are going to figure out what your use-cases, business cases, workflows etc. are. Once they do that they are going to build quotations around that and all. The problem with the centralized approach of IT is that’s not how users are working, they prefer picking up their apps and start using them. We’ve even seen individual employees putting up their credit cards in apps just to get the trial up and running. So that’s the older way. So as a reaction to that all these companies Zapier, Workado come up targeting the end users. In my view, the problems with these apps are that if you have 40 apps you manage and now there is a 41st app. You need to know how these apps work and pay for them. These apps are fairly complex and I think for typical use-case where you are looking point-to-point workflow this quickly becomes complex. Unless you’re technically inclined these workflows become hard for a single person to manage on their own. So, Sally goes to the app developers whose apps they are using, and tell them that we love your app and we want to adopt it more. It would really help us if you would integrate with these four apps we’re already using. Now the app developers have to prioritize where to burn their calories on, these guys are not integration experts. So other than having Zapier and Workado in place with limited functionality and lot of these enterprise rollouts require custom integrations. We empower these app developers directly by giving them integration technology which they can embed inside their app. By doing so what happened is that A they solved the problem of integrations. 90%-95% of users are looking at just connecting two systems together, not enough complicated scenarios. For example, you’re Salesforce and you have a CRM and you want to connect these together, you don’t need a lot of workflow complexity, to begin with. But at the same, you want to have some way of graduating from this single user within the company to multiple people. Using your app and having a more complex workflow using maybe two to three apps. All the way to something more complex with compliance, backup and IT. So, that’s what our toolset allows you to do. You can just connect Salesforce to my CRM. Click a button, authorize Salesforce and you’re done. But as things get more complex, you can open the workflow builder interface and you can customize the pre-built integrations developed by your app developers for you. You can customize further as you can have a different workflow, field mapping and your requirements are getting complex. You might want to write code now, you might have two-way data sync, data import or manipulation or data transformation involved. We give this graduation process to your typical users. So, I guess this is a very humble way of saying that, if you buy an app today we want the app to come with batteries included, so don’t have to buy another software for integrations. For example, if you have Slack today, it comes powered with 1500 – 2000 integrations today, it’s very rare for you to look for another third-party for integrations. That’s 90-95% case. If you move up, you have complex workflows you will need better workflow tools which we give. This is how we see our path, who we’re targeting, and how this journey starts.”
Alex: “I love that statement “Batteries are now included in your app”. The biggest issue with startups and SaaS space specifically gaining traction with new users is the inability to offer native integrations with tools they use every day. It is an enormous pain point, I have startups I have been working with that been putting money aside to create their native integrations they know they need to create. I have other startups that have chosen to natively integrate with apps that failed. I want to talk about if we can paint a scenario, I am an app developer, I have a product, I have raised a little bit of funding and I am a developer at trade and I am comfortable with creating integrations. My devil’s advocate role is essential, well I can just go ahead give a couple more weeks and give more time to create integrations that I quote unquote know my target audience is going to use every day. Also, I’m not going to go for a white-label provider because you don’t offer the new ones that I need my integrations. Further, I like to control that code. So whether this is or not your target audience who you’re going after with Integry. But maybe if I am that person, tell me what I need to know to make sense for that use-case.”
Nash: “So that’s a very typical conversation we have with technical people in our target market. Ideally, we like to talk to product people, but technical people are stakeholders in this conversation. So there are multiple things to consider here. Sure you can write the integration for yourself, develop those modules and start working there. What you’re sacrificing here is an opportunity cost. Given there is limited time to market, the resource constraints, that two weeks you’re spending on building that integration you can build your app. As far as integrations are concerned, they are solved problems for us. Any scenario you give, we are dealing with that in our platform. As a matter of fact, because of the tools, we are able to do it much faster. So, even if you have a very unique use-case that takes two weeks to do, you can do it using our toolset in a matter of day or two. So we end up saving your time depending upon the industry you’re in, and secondly, you talk about one integration. Say we have 160 apps today and we’re adding 5-6 connectors every week now. So if you have other integrations in line, instead of you have to pause, break away and build those integrations, you know you don’t have to worry about that. Thirdly, if we look at these connectors the API changes are fairly rapid especially depending upon who you are talking with. A large of companies Google and all those guys have an 18-month major release cycle, something large comes up to the degree that it might break your existing connectors. You have to maintain the actual connectors to run on your servers and there is a cost associated with it. The biggest cost is you have an old school API you’re connecting with for example Google Contacts, if you want to know there is a change in google contacts there is no direct API, you literally have to pull the google endpoint API. That’s every five minutes per user you have and that cost adds up really quickly. You want to avoid all this, you want to focus on what your app is unique for what uniqueness it adds and not to reinvent the wheel. You might end up doing a bad job at creating integrations, soaking up a lot of time. That might not even make or break your uniqueness of the app. We truly believe if you’re building a new company or a new startup your value really comes from what you’re building. Platforms like ours handle integrations at the back end.”
Alex: “Yeah, you bring up a very good point of maintenance. Something that early-stage, first-time startups don’t consider. If Gmail changes this, Salesforce changes this and hypothetically it happens at the same time, you may have to tell all your users to lean on that integration that you build manually. This is going to break for a week or longer, while my developers’ team comes through documentation and tries to figure out how to keep up with the changes unfolding. This happened recently, we did an episode on Gmail UI changes, SalesForceIQ is a perfect example. They gave up and said we are no longer going to support Google Chrome extension inside of Gmail. Gmail made it difficult for them and it wasn’t beneficial enough to keep up with the cost. That can happen to you. You’re a startup, not SalesForce that can be a nail in the coffin for you. If you have too many native integrations built out and you are spending too much time and money, in syncing cost. For those of you have not been in this kind of situation that is listening, a lot of times we see venture capital getting poured into these tech-startups. We know a whole lot going on at the front-end. We just wonder where is all that money going, this is one of the things that take up the cost and bandwidth keeping up with these integrations. They want to build more of them because it adds value to their app and opens them up to a wider share of the market. Focus on your app, don’t focus on what changes are made in the API, that is something you outsource. Before, I hand over to Nash to close the discussion, let me add there is a panel in January where we are actually going to scrum out the different roles, activities, and processes for which you either hire for, do yourself, or you find an agency or a software solutions; one of the big ones is API integrators. It’s up for the bait because there are still reasons that you build them out yourselves or do simple pros and cons. Here’s a scenario in terms of cost, here’s a scenario where we white-label all integrations, the benefits, the cons scrum that out and see what it looks like. I think you’ll find a scenario where you have a lot of native integrations going, it just not make any sense to build these out yourselves. Nash we have talked a lot, talked about the world of API integrations, different options, the solution you guys provide and the void you’ve filled. What is a citizen integrator and how that role is changing? What this means to product manager and marketing teams who can now turn on and off integrations. Let’s go down that road, real quick. Is there anything we can touch or talk about more where we can paint a picture for founders and startups out there. It’s a; most similar to the segment.io world actually where they came in early and said you know what instead of having to recode this plumbing from data point to data point, we give just a simple UI. Just toggle on and off the data flow, however you want to reroute or change it. If you could paint a picture to what it would look like on a day to day practice.
Nash: “If I could just touch a few things I was thinking about. In our experience, we come across two-thirds of APIs which have some differences between what is documented versus what is actually implemented. This is as simple as a field which is sets of different values that is documented all the way up to an action which is not behaving as it should be. As the number of SaaS apps is aggressively growing, so if you are a young company or an old company with a new product or you roll-out a new iteration of the product there are a lot of maintenance scenarios where you try to figure out what’s going on. You have to get down to the code to figure out what’s going on. That’s a lot of headaches that we handle for you.”
“As our vision, we want to productize the whole API Connection Integration Management experience. Whether you’re thinking of white labeling, doing in-house or in-app, we basically give a product for all of this. I’ll give you an example, one of the challenges of working with a large deployment is that it is hosted in your own data center, Integry is a cloud-native version. It is inside your own application, your own data center, dev-ops, you can manage it yourself. It allows you to build these workflows yourself, you’re doing it with your team it’s just that you’re using our toolset to build those integrations. It lets you rollout integrations really quickly. The end is really simple, you can just choose integration and add it inside your app. But also, if you are someone who has very unique needs, you don’t exactly want our integration. We have a very simple process to graduating to write your own code and get it up and running within your server. What I am saying that you don’t necessarily need to have one size that fits all. Some integrations you might want off the shelf, some of them you might want deep just shift them over yourself, you might be attending to some unique need. We will always provide you support for all of them. In the world of integrations in my opinion as a developer, once you write an API, from that point onwards to connecting with the other sources, for example, you are a CRM and you have updated the contacts API that contact might be syncing with other contacts systems inside other address books in other CRMs. So there is a whole bunch of work to be done while you update your API. What we want to do is first take the whole engineering overheads from that i.e. you as an app developer do not need to worry about these changes. We want to think this is the platform you need to connect to and once we do all of the integration scenarios are managed by the system, a system that can be trusted, it works, is protected, compliance and all stuff in place. For 90 – 95% of your use-cases, your users are addressed really well. For those 5% users, who are presumers might have Zapier accounts, for those guys we also have a toolset. So the key here is that your users do not leave your app, they use this interface to build stuff using your own UX/UI. Your users love your app, they bought it so you want to take the same experience a step ahead with integration experience on top of that. That’s what we envision, people who buy your app, love your app, we want them to not have a bad experience when they want to connect to another app. Lastly with the number of apps exploding with automation coming in, all the way to robotics process automation you want to be ready for API integration to happen for automation to take place. This is what we want, we don’t want this to be something that hinders app developers connecting with other apps.”
Alex: “I love the idea of productizing the API connections for your users. When a user goes to the website and clicks on integrations they go to a page where there are widgets and icons. They click on an icon and they get the same experience. Either just an explanation on how app natively integrates.If they’re logged in they get to a situation where they have to enter API key, maybe do a couple of drop-downs, map some fields, and then create the integrations with Integry. With this white-label solution bring Integry integrations to a UI that is your UI, it’s not going off to Integry, setting up and then connecting to Integry. It’s actually your users forming those API connections themselves in your UI leveraging Integry’s white label solution. It’s like having Zapier inside of your own app.”
Nash: “It’s correct! It’s like having a white label version of Zapier in your app. Again there is a lot control in what you can do. It’s designed to be simple, you can use your own HTML, CSS and it looks just like your app. It is indistinguishable for your end user to tell whether this is built in-house or being powered by us. It will just look like your app.”
Alex: “So, talked about the UI, talked about the experience! Is there anything we haven’t talked about with regards to painting this picture for products team out there.”
Nash: “The only thing I want to touch is in the business space, in the B2B world, you look at all the integrators there. Our view is that the number of SaaS apps is exploding really quickly also the use of these SaaS apps has doubled over the years. In the enterprise space, the average number of apps is 1300 being used. If you are looking for a platform, it doesn’t really make sense to charge by the number of connectors anymore. So that’s our approach, in terms of pricing, in terms of the modeling out there what we feel like our site is currently charging on the number of end-users you might have. We’re moving away from that, we’re moving towards unlimited users, unlimited connectors and we practically charge on the number of tasks, the transactions that occur on our platform. It allows us to keep adding connectors to our platform, which means to your app. We keep on adding features, you can keep benefiting from that. As the number of apps is increasing, you’re never restricted, you don’t have to pick and choose, you have access to all of these apps. So, for you to have your integration strategy compatible with the way the world is evolving, you don’t want any restrictions with who you want to connect with. A key part of this is how we have modeled our pricing. That’s something which a lot of the users and companies benefit from.”
Alex: “Because the number of apps has doubled in general their APIs have therefore doubled. The challenge for teams that build out API connections have doubled. So we talked about what that means and why that solution Integry exists. What does it mean for product teams? So, I hope everybody who listened to this episode will be very very excited to go ahead and check it out, this ideal solution for their integration needs. With regards to where you at, can you mention where you’re at with your beta, any dates, anything people can do right now at integry.io?”
Nash: “Absolutely, we have live customers, we have production, we have actually 10s of 1000s of users who are currently powered by our integrations. If you have an app, you are a B2B SaaS company, you should reach out to us. Go to integry.io and get in touch with us. Within the next month of December, hopefully before Christmas, we are launching a self-service portal. If you are an early SaaS company and you wanna try out the technology, you can just sign-up at integry.io. In the meanwhile, you can reach out to us and we will be happy to help you play around with technology with what we have.
Alex: “So head out to integry.io. We also have a complete API integrators review, it’s a living sheet. Nash and team will update it as they come out with new options. Go ahead and check that out as well. We’ll link to both integry.io and the API connectors review in the show notes to give you an idea how Integry stacks up. Thank you so much, Nash for being on the show, I know it’s late there though I appreciate you stayed up late for this recording. You have surely added valuable content, I’m sure everyone is going to love that.”
Nash: “Thank you Alex, it was great talking to you. “