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

This post by Michael Arnold originally appeared on the LookFar blog.

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.

Take Our Buy Or Build QUIZ

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.

So, which direction should you go? The answer’s 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.

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 studios and 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.

ThirdParty.jpg

3rd Party Integrations: Potential Pitfalls

#1: 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 for finding a 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 me directly into my next point.

#2: The Terrible Third Party Web from Hell
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, I guarantee you, 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.

#3: Data Swamp
Not only does every integrated third party solution store your data in different places, 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? See Pitfall #1.

Of course, this hypothetical business might not have been able to succeed without those tools. I’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.

#4: Integration, Continuous Integration, Discontinuation
You’ve chosen a third party solution and successfully integrated it into your business process. First off, congrats! I’ve been hired to integrate a solution chosen by an organization that didn’t just work as promised “off the shelf” far more than I’d like.

But anyway, it’s integrated. That’s it right? I’d love to say yes, grab your medal and take the day off…but the fact is, technology changes quick 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 Facebook 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 I actually devoted an earlier article to handling it gracefully.

Custom.jpg

Custom Development: Common Pitfalls

#1: 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 which 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 his code? I’m here to tell you- “No, he 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.

#2: 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 old adage of “you get what you pay for” is particularly true for custom software. More than a handful of times in my career, I 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.

#3: 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.

It is critical that each potential solution is reviewed to determine if the service offering fits your need. 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. I’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.

And on the other hand, I’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.

Alright, I get it, build and buy are both valid. Which is right for ME?

Take our quick quiz to determine which option suits your business needs best.

You may notice that we did so using a 3rd party solution. Our quiz unequivocally determined that we should grab off-the-shelf software to create it, rather than coding something ourselves, and we take our own quizzes extremely seriously. Check it out for at least some early guidance on whether you’re ready to take the plunge on custom development or should stick to off-the-shelf options.

Of course, no 9-question test can give you a definitive answer on such an important question, so don’t treat your result as the alpha and omega of the build vs. buy debate. If you find yourself looking for a more concrete recommendation, email us, and we’ll be happy to talk things through.

Click here to take your own build vs. buy quiz.

Summary

In closing, there really is no blanket solution or universal answer for this question. You have to know how any decision can affect you immediately as well as years down the road. I have been around long enough to know that no software is perfect, or guaranteed to live forever.

Whichever option you choose, devote some time and thought to it. Otherwise you might wind up with a third party product death web, and if you try and opt for custom software on a shoestring, you might as well donate a wad of money to your favorite NFP and then go hire a real software shop to build your product. You’ll spend that much anyway and not have the satisfaction of donating to your cause, unless your cause is crappy software.

And that really, really shouldn’t be your cause.