Often in the rush-to-market or aim to impress early investors, we make decisions before having a chance to step back and get a birds-eye view of our application’s game plan from inception to market. In this article, we will walk you through 6 important things to consider when planning for your application’s integration strategy.
1. Determine your use case
The most important question is always: What use case do YOU need to accomplish for your users with your integration?
Maybe you need to allow your users to create an automation rule for a workflow that they are going to be performing over and over again. For example, maybe every time a user uploads a folder to Box, they also need to automatically sync with their Marketo resources.
It’s quite possible that your application needs integration for on-demand user activity, such as allowing the user to pick and choose specific files from DropBox to upload directly into your app.
It may be that your application needs access to your user’s data for an entirely different purpose, such as security.
2. Consider your user
Let’s say you are building a security software app. To secure your user’s data in their storage service applications, your application will need access to that data to secure it.
The point of this question is not to second-guess your application’s need for storage integration, but to get you to think long and hard about the user who will take advantage of this functionality.
Considering who your user is is of the utmost importance.
Before you go digging in the weeds to incorporate outside services, libraries, and functionality, it’s important to think about what kind of users would access this functionality. Is it an individual user, or is it an administrator who is setting a rule for everyone in an organization? Questions like these are key to understanding your application’s purpose, as opposed to its functionality.
The two are not one and the same and should never be thought of as such.
3. To embed or not to embed?
It is always ideal to embed an integration into your application to control the experience. It is never a good practice to force your users to leave your app and go to a third party, only to have them return to your product environment after.
The upside of not embedding an integration is that your team doesn’t have to support the integration. But this benefit is outweighed by the overhead of asking your users to sign up for another service that they may not be comfortable with. By asking them to adhere to your preference of external third party integration means that you lose control of the user experience. Never assume that a user won’t side with apathy toward your app when forced into a service they may not already be accustomed to. By doing this, you miss out on valuable information about your users and how you can improve to meet their evolving needs.
The upside of embedding an integration, however, is that your user has less work to do and stays in the environment you have provided. You learn more about them and their needs this way.
You control the experience.
4. Automation or interactivity?
A good example of this would be Slack’s add-ons and integrations that are built directly into the app. When you upload a file in Slack, being able to click on the DropBox button is an on-demand capability. If Slack didn’t support that integration, users would be forced to use a service like Zapier to define the action that they want to take. This route would make the action automatic, meaning that it is limited to the rules that govern it and stripping it of any a la carte interactivity like having a file automatically download to a user’s DropBox when any file is uploaded to Slack.
A huge benefit to embedded integrations is the ability to build more use cases beyond these rules. When your application’s integration user flow is not written in stone, it allows you to have more flexibility and a variety of interactivity–Both of which are pivotal to setting your app apart from competitors.
Users are just people. They will gravitate toward what makes them feel comfortable and in-control of their experience. Some will resist the unknown in favor of the familiar. Give them the ability to pursue either.
5. Identify needed services
Next, prioritize what cloud services your application needs to connect to.
Look to the market leaders in each category. These are table stakes. They are the clear cut minimum that your application needs to support in order to thrive.
Any integrations beyond that will be driven by your end-users’ demands. Gather info from customers requesting different connectors and prioritize your product roadmap accordingly.
Choose these integrations based on what will yield the most business opportunity.
Lastly, you need to strategize on competitive differentiation. What do you need to connect to in order to stay ahead of the curve?
Maybe these connections are longtail or simply have some sort of cult following. They may not be the most heavily utilized in their category, but they can help your application stand out among the pack. If you simply add integrations for the services that lead their respective categories, your demand will dry up after a certain pool of customers. Make your product as competitive as possible by integrating with these smaller and more niche alternatives. Their rabid fans will thank you, and for all you know, these services may become the industry leaders down the line.
6. Build smart
None of these questions can be answered without forcing you to step back and evaluate your application’s real purpose.
That’s really the entire point of this article. We can’t provide you with one clear-cut, industry-standard roadmap toward your integration strategy because it doesn’t exist. Each and every application with a need for integrations has a different use-case and different end-users.
This is the time to search out the tools and make the right development decisions that will help your vision come to life and flourish.
Cutting down on the time and resources consumed by your dev team should be a top priority. Tools such as Unified APIs that allow for a connection to many services with the coding equivalent of connecting to a single service can not only save you time and money on development, but also protect you from unexpected roadblocks in the future should your integration services change the nature of how you connect to them. On top of that, the ability to give your users a veritable smorgasbord of services at once is something that can push your app over the edge when it comes to differentiating it from its competitors.
The real work isn’t what libraries or languages you choose to build with. It’s not even about the specific connectors you choose to go with initially. It’s about the strategy you take to make your application stand out. What makes it unique. What makes it comforting. What makes it desirable.
We look forward to what you build.