Blog

All Blog Posts

3rd Party Components: Considerations in Custom Software

3rd Party Apps

I’ve talked about 3rd 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 3rd 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 3rd party component. The diagram below shows how we rely on 3rd party components embedded in your software to integrate with external 3rd 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.

3rd Party Apps and Components

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

A 3rd 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 3rd 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 3rd party) when it comes to custom software, so we evaluate the best options for each situation. When we’re deciding whether to integrate a 3rd party application, we consider a lot of different factors, including:

  1. Goals of the System: For a 3rd 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: 3rd 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 3rd party component is critical to understanding your options. Generally, a 3rd 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 3rd 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 3rd 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 3rd 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 3rd 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 3rd Party Component Considerations

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

  1. Regular Updates: Good 3rd 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 3rd party components, plan for periodic maintenance that’s out of your control.
  3. No Control on Pricing Structure: Another risk of working with a 3rd party is that we’re not in control of the pricing structure. The 3rd 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 3rd 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 3rd party integration or not.

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

Categories