3rd Party Components: Considerations in Custom Software

I’ve talked about 3^rd party components and how and why we use them. Well, there are several things to consider before integrating them in your custom software system, so I’m going to walk through how we evaluate and choose 3^rd party components for our clients’ applications to help you understand the rigor needed to ensure a successful integration.

I first want to clarify one point on terminology. There is a difference between a 3rd party application and a 3^rd party component. The diagram below shows how we rely on 3^rd party components embedded in your software to integrate with external 3^rd party applications. However, for the purposes of this article I will blur the lines between the two—many of the pros and cons and the factors we consider are the same for both.

Learn more about integrations in custom software development.

How to Evaluate 3^rd Party Components for Use in Custom Software

A 3^rd party component is basically a software solution that is developed by another company or developer. When we’re building custom software systems, we don’t like to reinvent the wheel. So if a 3^rd party app exists that meets your functionality needs without us having to build it from scratch, it’s worth evaluating.

There’s no inherently right answer to whether to build (create custom) or buy (integrate via 3^rd party) when it comes to custom software, so we evaluate the best options for each situation. When we’re deciding whether to integrate a 3^rd party application, we consider a lot of different factors, including:

1. Goals of the System: For a 3^rd party component to be effective, it needs to have the functionality required within the bigger picture of the custom system. If you need an email delivery service, does SendGrid accomplish what you need, or do you need to evaluate other applications?
   
2. Cost of Implementation: 3^rd party component pricing plans vary from freemium to monthly/yearly subscriptions, often based on the features and usage levels you require. Weighing the cost of developing the functionality from scratch vs the upfront and ongoing costs of a 3^rd party component is critical to understanding your options. Generally, a 3^rd party component will cost less in the short-term than starting from scratch, so we always consider cost within the bigger picture.
   
3. Ease of Integration: The effort required to integrate a 3^rd party component can have a big impact on project costs and timelines. If we’re unsure of what it will take, we may elect to do a proof-of-concept to validate the effort.
   
4. Resources and Support: We always review a 3^rd party component’s resources—specifically their developer resources, knowledgebase, and support center. If the documentation and support are lacking—or worse, if there are no separate resources for developers—that says a lot of about how developer-unfriendly the component is likely to be.
5. Vended Vs. Open Source: While enterprise vended solutions tend to be easy to get started with, come with up-to-date documentation, and offer accountability for each product, there’s a lot out of our control. Open-source software, on the other hand, gives us a starting point that can be customized and controlled by our developers. So, before picking a 3rd party component, it’s important to consider whether the software is vended or open-source.
6. Product Roadmap: We prefer to use 3^rd party components from established businesses with a product roadmap for the future. This is a good indication that they plan to continue investing in the long-term support of the product.
7. Version History: The version history shows how actively the 3^rd party component is being developed and supported. If a component has not been updated in over a year, chances are it’s not one you would want your custom software to depend on. Just like custom software systems, components need regular maintenance.
8. Statistics: The number of downloads and other statistics are a good way to gauge the popularity and performance of a component. It’s similar to how we quickly evaluate the quality of a mobile app—if nobody is downloading it, chances are it is not of high quality.

Other 3^rd Party Component Considerations

Despite the fact that using 3^rd party components can save significant time and cost up front, there are other considerations.

1. Regular Updates: Good 3^rd party components make constant updates to their platforms. And while that’s generally a good thing, sometimes those updates impact the components in a way that requires a change to the integration on our side. To extend the life and viability of your software system it’s best practice to update the components on a regular basis.
2. Coding Changes: The regular upgrades may require us to make development changes to the system. When you integrate 3^rd party components, plan for periodic maintenance that’s out of your control.
3. No Control on Pricing Structure: Another risk of working with a 3^rd party is that we’re not in control of the pricing structure. The 3^rd party can change the pricing plan or even change a free app to a paid one. The extent to which pricing structures are modified is completely out of our hands and may impact your ongoing costs, so it’ good to be aware of this up front.

As you can see, there are many factors to consider when choosing 3rd party components for your project. And there may not be just one “correct” option. Regardless, we’re dedicated to helping educate you on your options, the realities, and the pros and cons of 3^rd party apps and components.

In the end, it’s about evaluating your options and choosing the best one for your custom system, whether that’s a 3^rd party integration, custom software integration, or something else.

Are you curious about how 3^rd party apps and components could impact your custom software? Reach out.