Win a free ticket to the 2020 IoT Innovator Summit in Austin, TX.

Subscribe to our blog to get the latest articles straight to your inbox.

Should you build or should you buy? Everyone needing software has had to attack this question and, as always, the answer is, “it depends.”

If you’re asking this question, you’re usually in one of two situations: 

1. You’re building new software and need to know if you should use existing software products to get the functionality you need, or if you should build the functionality yourself.

Or...

2. You need software to solve your problem and need to either find an off-the-shelf solution, or build one that suits your needs. 

If you’re building new software, there will be features your users expect to have but aren’t core to your main value prop — things like authorization, authentication, configuration, administration, etc. 

If you need software to solve a problem for you, it’s likely that there are software packages available, but purchasing a new software solution would mean that you’d have to do a major overhaul to your internal business processes. 

Whichever situation you’re in, the software solution you want to integrate with is a dependency for your overall system, because whatever new software or functionality you add will depend on your existing tech stack to work the way you want it to work. Whenever you want to bring a software dependency into your solution, you or your team will need to take a good look at it before you begin the development process. 

So how exactly do you do that? At Very, we’ve seen it all. As specialists in custom software development, we’ve worked with many dependencies in the development process — both good and bad. When evaluating a dependency to determine whether you’ll build or buy your new functionality/software solution, you should consider:

  • Documentation
  • Support
  • Security
  • Cost

Is the Documentation Complete and Correct?

The documentation of a dependency is extremely important. Without it, we won’t be able to effectively and efficiently integrate with the software during the application development process. The documentation will tell engineers how to set up and configure the dependency, and how to interface with it. 

When you evaluate documentation, you should look at completeness and correctness

To check for completeness, you’re looking for documentation of the public interface. This is stuff like: what methods or functions can be called, what data needs to be supplied, and what’s the expected output. It’s also good to look for guides that will show what to do and what not to do. 

The best way to examine documentation for correctness is to perform a research spike and build out a small demo of the functionality you’re gaining. The code doesn’t need to be production-ready and it will probably have a lot of hardcoded values, but it will give you an idea of the value you’ll get out of the dependency, and how hard or easy it is to work with.

Does the Dependency Have a Solid Support System?

Because you don’t own the dependency’s code, you’ll need access to some kind of support if something goes wrong. 

While the plan is for everything to just work, the fact of the matter is there could be some kind of failure in the operating system. The server might lose power or network connectivity, and the same could happen for the dependency. It’s better to plan for failure rather than to ignore it. 

So, you’ll need some kind of support provided by the owners of the dependency. Some things to look for and assess, and questions to ask: 

  • Uptime guarantees
  • A status page
  • When was the last outage and how was it resolved? 
  • How is scheduled downtime communicated? 
  • Is live tech support available? 

All of this depends on how mission-critical the dependency is to your new software, and whether it’s a software-as-a-service (SaaS) solution or self-hosted.

Is the Software Secure?

Depending on the function the dependency plays in your software, security could be a concern. No one wants their name associated with a security breach like Equifax or Capital One

That being said, there are several areas you should review: 

  • What data will the dependency need access to?
  • Does it encrypt sensitive information and block you from retrieving it?
  • Have they ever had a security breach? 
  • How often do they release updates?
  • Is their code open source?

If the dependency doesn’t need sensitive data (like credit card numbers), and it’s a SaaS solution, then you might not need to dig into it very far. If it does need sensitive data, then that data should be encrypted, and you shouldn’t be able to retrieve the value — like how Stripe handles credit card numbers

If the software is self-hosted, then you’ll need to make sure that they release and install security patches regularly.

If the code is open source, then the community around it will be able to police any security infractions.

The point: there are many factors at play here, and it’s important to perform research spikes to determine the viability of a software solution.

How Much Should the Dependency Cost?

When you rate a dependency for cost, not only do you have to consider the cost of the dependency, but also how much it would cost if you built it yourself

For example — say a dependency costs $200 a month in subscription fees, and a development team costs $20,000 per week. Spending one week to build the solution would cost the same as purchasing a 100-month subscription from an outside vendor.

There are many factors that go into cost, and if you build your product instead of buying, keep in mind that in addition to managing the custom application development, you’ll have to manage documentation, support, and security yourself.

You might not need every feature of the dependency, but you should have an idea of how long it will take to build the features you do need, vs. how long an integration will take. 

Referring back to the example— if it takes two weeks to build the features you need and one week for integration, it’s better to integrate the dependency and have the team focused on delivering higher-value features the second week.

Remember… 

Building software is expensive, and it’s important to analyze and integrate dependencies so that your development team is focused on providing value instead of reinventing the wheel. 

Whether or not you incorporate a dependency into your software depends a lot on your situation. You’ll always need to consider documentation, support, security, and cost whether you build or buy. However, the most important thing is making the right decision based on your needs and business processes.

If you decide to build your software, choosing the right custom software development service will make all the difference when it comes to time and cost savings, while delivering the high quality functionality your users need.

If you’re curious about whether custom software development is right for your business, speak with one of the experts at Very today to talk more about your project