We’re always eager to try new third-party applications when one of our clients’ apps needs a new feature. Sometimes we’re approached by a client who is considering investing in a third-party tool to simplify their app. Other times we’re asked to build a feature, and our internal team will consider a 3rd-party integration to more efficiently handle the request without building from scratch.
Regardless of how 3rd-party tools are brought into our web development discussions, there is an evaluation process to follow once we decide to pursue an outside integration. Whether it’s payment processing, calendar functions, or authentication – there’s nearly always more than one 3rd-party tool that could get the job done.
So how do you choose which one can best accomplish what your app needs?
While the right 3rd-party application can simplify your development efforts long-term, the wrong one can cost you hours in implementation and integration, especially if you end up needing to switch tools in the future. Here’s how we evaluate 3rd-party tools when integrating with an app.
Questions to Ask
What does their developer documentation look like? Are there any examples or tutorials?
Even the greatest third-party apps become a lot less useful when the documentation isn’t up to par. Often an integration’s website is more focused on pitching the product than providing adequate documentation to set up and work with the app. Seek out the “Developers” or “Documentation” section of each app’s website to evaluate their documentation.
Will they provide a free sandbox environment for a staging site?
The 3rd-party application I talk about later in this post offered two sites, a test site and a live site, as part of their service. The addition of a free sandbox environment for staging is a big added value.
Are there client libraries for their API? Are they written and maintained well?
There’s no such thing as too little API documentation. Look for each potential 3rd-party app’s client libraries to ensure they include the language that your application is written in. Bonus points if they’re open source client libraries, so you know they’re always looking for improvements. Here's an example of well-documented client libraries for APIs.
How well do I understand the codebase?
This can also be asked as – Would I be comfortable patching or contributing to this codebase? If glancing through their code leaves you feeling overwhelmed, it may be complicated to work with as well.
Is there a clear way to integrate with other needed third-party applications?
Documentation helps here, too. If a tool is commonly paired with other third-party apps, there may be published how-tos and best practices.
Are they trying to do too many things? Or are they focused on the problem we’re trying to solve?
Many of the best tools do one focused thing and do it well. When possible, choose the third-party integration that focuses on the core issue you’re trying to solve in your application.
This Process, Applied
Recently, one of our clients asked us for a recommendation on a 3rd-party recurring payment tool. This client currently had a subscription service with recurring payments but wanted to look into other solutions.
They were looking for a service that would give them more options to create and manage multiple plans and provide a robust admin tool to analyze user and plan data. My own experience and a quick Google search gave me a few ideas of where to start. Automatic recurring payments have become the norm for many businesses, making the market for this service quite competitive. Some of the options I evaluated lacked adequate developer documentation and their sites focused more on sales.
While I found several services that were comparable, Chargebee stood out above the rest. In addition to meeting the client's criteria, they had great developer documentation, tutorials, a well maintained Ruby gem, and provided a free sandbox account.
Ultimately they got the gold star because of their clearly highlighted and well-documented migration plan they provided. Their migration plans include details depending on what language you’re using (Curl, PHP, Ruby, Python, JAVA, .NET, or Node). This improved my confidence that migrating would be as simple as possible.
I take great care when working on the income-producing mechanics of a client’s application. Small errors can turn into major ones when payments are involved. Migrating a customer base from one service to another with the fewest hiccups is key. A detailed migration plan makes that much easier.
Third-party apps can simplify your product development and save time for your team, but only if you’re choosing an integration that suits your needs. The next time you’re considering a third-party tool, hopefully, these steps will help you feel more prepared to evaluate your options and make the best decision for your project.