LookFar Labs6 February 2024

Build vs. Buy: Third Party or Custom-Developed Software

If you’re in business and that business is currently booming, you’ve probably got software on the brain.

You’ve got payroll to make, clients to reach, content to publish and you need some efficient, effective tools for the job.

There are generally two options when it comes to embedding software into your business processes: you search the web for third-party solutions that may satisfy some or most of your business requirements, or you hire software engineers to custom-build an application tailored to your specific needs.

Definitions to Know

So, which direction should you go? The answer is complicated, and it starts with defining a couple of terms we’ll be spending some time with.

Custom Developed Software:

Software that is specifically developed for an organization or other user.

Whew. Easy enough.

Third-Party Software:

A reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the operating system. Sometimes known as commercial-off-the-shelf or “COTS” software.

A little more complex.

Operating System:

The Operating System defines the first party (Windows or Mac) and the second party is you (the user). The third party is the vendor who created the software.

Here’s how it works if we’re talking about mobile apps: for both iOS or Android, many apps available were not built by Apple or Google, but instead by third parties including software development studios (like us) or solo developers. You, the second party, download the third party onto the first party, in this case, your phone. Three’s a party!

Now that we have an understanding of what our options are, let’s take a minute and talk through some of the build vs. buy pros and cons for software, with a bit of an emphasis on cons. There are risks to both approaches that occasionally get forgotten in the scramble to find a solution.

The Case for Buying Third-Party Software

Benefits

Save Time & Money

One of the most significant advantages of buying software is that it can save time and money. Purchasing software from a third-party vendor can provide a faster time-to-market, as the product is already developed and tested. This can be particularly advantageous for organizations that need software for a specific use case but don’t have the resources or expertise to develop it in-house.

Minimize Risk

Another advantage of buying software is that it can be less risky than building software from scratch. Vendors have already invested time and resources in developing and testing their products, reducing the risk of bugs and errors. Additionally, many vendors offer ongoing support and maintenance for their software, which can be crucial for ensuring the long-term success of the project.

Wide Range of Features

Finally, buying software can offer access to a wider range of features and functionality than what could be built in-house. Many vendors offer specialized software solutions that are tailored to specific industries or use cases, providing organizations with access to features and functionality that might not be available if they were to develop the software in-house. This includes investments in ongoing feature development. The resulting benefit of getting new functionality on a potentially ongoing basis, without having to pay for the resources to do the work is a big plus over building from scratch.

Potential Pitfalls

Staff Bloat

With so much technology available and company sizes at an all-time low, it is difficult to justify maintaining a staff that can support the a-to-z(s) of programming. A common mistake is to solve every problem with a one-off third-party solution. However, there’s something to be said about finding an app consultant or company who can provide guidance throughout your decision-making process and help you streamline all the cogs that make your company’s machine work.

Which leads us to our next point.

The Terrible Third-Party Web

The right decision today might not look so rosy tomorrow. Third-party solutions are not spandex, one size does not fit all. When implementing another vendor’s solution into your process, each new addition creates another layer of abstraction between you and your data.

For every implementation, we guarantee you, that someone on your staff will also end up taking on the responsibilities inherited with each solution.

Imagine a rapidly growing retailer. Not knowing what technology to use in the beginning, they implemented the following free tools: a website builder to create their public e-commerce site, an ERP system to track inventory and other business functions, an email service for advertisements and campaigning, a blog service to improve SEO and content marketing, and a payment processing system. Effectively, their data now lives in 5 different places.

And that’s…not good.

Data Swamp

Not only does every integrated third-party solution store your data in different places, but it’s unlikely that there’s continuity between the data sets. Picture our retailer who is shipping 500 units a day – at this point, the task of aggregating and normalizing all that information into meaningful data is going to be a nasty, involved task.

Those five platforms don’t talk to one another. Someone’s going to have to shoulder the task of pulling visitor count from their blog, order data through their ERP suite, and open rates from their email client. They’ll then enter that mess of data into a spreadsheet, figure out how it’s all related, and maybe come away with an understanding of how their pipeline is functioning.

Sounds like another full-time position right?

Of course, this hypothetical business might not have been able to succeed without those tools. We’d commend them for utilizing the resources available and charging forward. Sure, things can get messy, and there are pitfalls associated with vendor solutions, but they are saving both time and money.

At least, until they aren’t.

Integration, Continuous Integration, Discontinuation

Technology changes quickly and not always for the better. As with any software, third-party solutions will most likely be updated, unsupported, or discontinued sometime in the future. Even established companies like Meta change their code frequently, meaning you’ll need an engineer to go into the code and “re-hook” all of your integrations.

There’s also the looming chance that your lovely third-party software provider goes out of business. This is such a consistent, predictable part of software development and maintenance that we devoted an earlier article to handling it gracefully.

The Case for Building Custom Software

Benefits

Despite the advantages of buying software, there are several compelling reasons to build software in-house.

Increased Control

For one, building software provides greater control over the development process. Organizations can tailor the software to their specific needs and have complete control over the development process, allowing them to ensure that the software meets their requirements.

Cost-Effective

Another advantage of building software is that it can be more cost-effective in the long run. While buying software can save time in the short term, ongoing license fees and maintenance costs can add up over time. By contrast, building software in-house provides organizations with a one-time investment that can provide ongoing benefits and cost savings.

Control Data & Intellectual Property

Finally, building software can be advantageous for organizations that need to maintain strict control over their data and intellectual property. By developing software in-house, organizations can ensure that their data remains secure and that their intellectual property remains under their control.

Common Pitfalls

Legacy code

Let’s take a look at an unnamed Financial Firm. This particular firm is lucky enough to have a brilliant senior developer on staff, who has written custom applications that the business now relies on to operate. As great as this employee is, what happens if they leave? Does anyone else know the ins and outs of the software they wrote? Did the brilliant senior developer spend time to painstakingly document their code? We’re here to tell you- “No, they did not.”

Medium and large businesses alike often suffer from the inheritance of legacy code. You must account for the possibility of key personnel jumping ship. This is a giant, all-too-frequent disaster waiting to happen.

Cost vs. Quality

Another downside to custom software? It’s more expensive. Yes, it’s possible to find budget options, but just like custom suits, cars, and homes, getting exactly what you want and need does come at a premium. And the adage “you get what you pay for” is particularly true for custom software. More than a handful of times in our career, we have re-written software a company recently had commissioned – sometimes at great cost – because they found out too late that they’d paid for a completely unusable piece of tech.

Weighing this cost – and this risk – against the unwieldy but cheap, quick option of third-party solutions is anything but a trivial decision. Make sure you trust the team who is building your custom product.

Timelines and Deadlines

Building custom software is time-consuming. Even getting started requires hours of research, strategy, meetings with stakeholders, design and technical planning, and requirement gathering. It’s not unusual to get several weeks into a project without writing a line of code.

But once development starts, things speed up, right? Yes, but don’t forget about the time it takes going back and forth between PMs and stakeholders for review, feedback, and approvals. And, let’s not forget about the time it takes to complete Q/A, where we find and fix any bugs or issues!

Since custom applications are built targeted rather than blanketed or universal, it’s common for software to be released incrementally, with new functionality ideally being built as a product is tested and tweaked. As a result, the area of the application you need or care about might be the last in production – a frustrating delay for companies that don’t account for it.

Takeaway: Understand Cost/Risk

A quick Google search returns countless blog posts and forums covering build versus buy, but they all have one recommendation in common: Clearly identify the problem.  The better you understand, in extreme detail, the problem being solved for your business, the easier it is to choose from a sea of solutions.

Each potential solution must be reviewed to determine if the service offering fits your needs. It is so easy to find yourself bound to an agreement well above what is needed. Many vendors have sales teams who are more interested in upselling to hit a quota than they are in keeping your company alive. It’s the “want to make that whiskey a double for $2?” of the software world.

Except we aren’t talking about a few bucks. We’ve witnessed organizations pay upwards of $10k/month for unnecessary support, consulting, and additional services never utilized (and that’s for a single vendor). You may find that the only piece of third-party software available that solves your small but critical business problem is much more robust than you need, and so you’re shelling out for years of feature development that is not directly benefitting your business.

On the other hand, We’ve also seen companies develop custom code that wound up being a complete non-fit for their actual business needs. Scope creep is a natural plague of any software project, but trying to develop while meeting constantly changing requirements is an easy way to add a very long, very expensive chunk of work.

How to Decide: Buy vs. Build

Ultimately, the decision to buy or build software depends on the specific needs and requirements of the organization. Here are some key factors to consider:

• The organization’s budget: Building software in-house can be more expensive upfront, but can provide long-term cost savings. Organizations should consider their budget and the expected ROI when making the decision.
• The organization’s expertise: Organizations with significant technical expertise may be better equipped to develop software in-house, while those without this expertise may find it more challenging.
• The availability of existing software solutions: If a suitable software solution already exists, it may make more sense to buy rather than build.
• The need for customization: If the organization requires a high degree of customization, building software in-house may be the best option.
• The need for data security: If data security is a significant concern, developing software in-house may be the best option to ensure complete control over the data.

Ultimately, the decision to buy or build software is a complex one that requires careful consideration of the organization’s needs, resources, and goals. By weighing the advantages and disadvantages of each approach and considering the specific factors that are most relevant to the organization, organizations can make an informed decision that sets them up for long-term success.

If you find yourself looking for a more concrete recommendation, email us, and we’ll be happy to talk things through.

Written by