Build vs. Buy and the 80/20 Methodology

Alex Brown, Editor-in-Chief
May 22, 2019

Finding the right enterprise-level mobile software is tough. Often, you'll find yourself pulled in a million different directions, barraged by conflicting information and dogged by relentless sales reps. It’s enough hassle that you might cave to the first reasonable offer, but there are many reasons why you shouldn’t.

The first and most important choice you have to make usually boils down to Build or Buy. Each has its own advantages and disadvantages, and there are a number of considerations to take into account before you dive into either side of the pool:

  • Will the proposed solution force you to change your business processes?
  • How specific are your needs? Can off-the-shelf products meet them?
  • Will you need to scale or expand the solution in the future?
  • How many employees will use the solution, and how will you coordinate training them with it?
  • Does your current IT team have the expertise to build what you need?

It’s important to form your expectations based on your unique limitations and requirements. If you’re operating on a tight budget, you may need to stick with a spartan-yet-functional solution from the App Store. If you’re seeking novel features for a highly specialized use case, you may end up paying a lot more than a monthly software subscription fee.

kelly-sikkema-251938-unsplash

Build It: Expectations vs. Reality

Even the biggest companies with large budgets see their internal software projects fail to deliver. According to the 2015 Standish Group CHAOS Report, fewer than 30% large-scale IT projects deliver on time, within their budgets, and with satisfactory results. With a failure rate that high, why do both big and small companies still try to do it all on their own?

They aren’t oblivious to the pitfalls of internal development; the problem is that they start by asking the wrong questions and supplying the wrong answers. For example, when setting a budget, a company that specializes in may be familiar with end-user software prices, but estimating development costs is well outside their wheelhouse. When they ask what a realistic budget should be, they compare it to the market rate of third-party developers or finished products.

Similarly, you shouldn’t expect an IT department whose primary focus is the maintenance of commercial applications to create a homegrown solution from scratch. Although your IT crew might have a wealth of coding experience, managing a project in IT is incredibly time-consuming, labor-intensive, and prone to delays. When inexperienced IT departments bite off more they can chew, it means hiring freelancers to pick up the slack – usually at a budget-bursting premium.

Depositphotos_14422313_xl-2015

Buy It: The Prefab Problem

When companies consider buying a prefabricated solution or hiring a third party to build one for them, budget usually isn’t the primary concern. They want software that works as expected and with assurances of quality, reliability, and dedicated support. What they forfeit in flexibility, they gain in confidence. At least, that’s what they think they’ll get. In reality, out-of-the-box solutions can cause more problems than they solve.

First, there’s the cost of ongoing maintenance and “hidden fees” for additional development and functionality. Some enterprise software companies won’t even attempt to accommodate unique use cases. They expect you to add even more software to your tech stack if you need solutions outside of their focus. "If it’s not on our feature list already, it’s not our problem," they might think. Simply put, most off-the-shelf solutions are built to add just enough value to make a sale.

Second, many solution providers are unable or unwilling to meet your current process halfway. Instead of integrating your existing methods, databases, and strategy, they force you to adapt your operations to their software. That requires re-training your workforce, painstakingly converting all your old data for their new system, and lengthy troubleshooting sessions. Even some platforms that boast easy database conversions won’t provide perfect-fit, one-to-one ratio digital versions of your current forms, processes, and workflow.

Finally, besides the growing pains of change management, out-of-the-box solutions are routinely inflexible. The go-to-market approach for some tech developers goes like this: “To catch the most fish, we’ll cast the widest net.” As an end user, that typically means the product you receive is shallow, basic, and only suited for the lowest common denominator in your industry. These solutions rarely merit the moniker of “jack of all trades” and more commonly align with “master of none.”

vadim-sherbakov-36-unsplash

The 80/20 Methodology

By now you might be asking yourself: “If both approaches have so many pitfalls, which one is actually right for my company?” The good news is that it’s not an all-or-nothing decision. There are options along the software development spectrum that allow you to be as involvedor absentas you like.

The 80/20 methodology is a hybrid approach that neatly dovetails the best of both out-of-the-box solutions and fully homegrown development. The initial responsibility rests on the software provider rather than their client: they supply a solution that already meets 80% of their customer’s needs. During early development, they work hand-in-hand with the customer as a technology partner, taking the time to understand their unique processes and challenges.

It’s during this early phase where the 80/20 approach easily outclasses homegrown software in terms of visibility and flexibility. Even if your use case is entirely unique, you can still work with an already functional framework. Likewise, while 80/20 development may not have every module in place at the outset, its open-handed approach to plugins and configurable elements means that whatever features you want can still be added.

Software providers who emphasize partnerships over products and renewals over one-off sales will strive to keep your business by meeting your requirements and listening to your needs. If you’ve ever tried to use a solution for “off-label” purposes just to avoid adding another layer to your tech stack, you know it’s like forcing a square peg into a round hole. That’s why your software should be flexible and able to reflect your company’s real needs and challenges. Most importantly, it should continue to add value over time instead of nickel-and-diming you at every turn.

Conclusion

The 80/20 approach is a foundation for success, but you shouldn’t cave on critical requirements or functions simply because a seemingly flexible software provider claims to have your best interests at heart. If you need specific features, such as on-premise server hosting or offline-first mobile functionality, don’t be afraid to ask the tough questions: “We need this feature. Can you implement it or not?”

A good software company will be honest with you. They might say it’s not possible or effective, but they can offer a better and more optimized approach to meet your need. At the end of the day, it’s impossible to know whether a solution is a good fit for you until you see it in action. Whenever possible, demand proof. Get your hands on a demo, critique it, and request revisions. A company that is willing to understand your organization’s unique challenges and technology goals is one that will continuously improve to offer value for years to come.

Want to learn more about the Form.com approach?

Our platform is built on more than 15 years of experience in developing and deploying mobile solutions, and we can customize it all for your organization’s existing forms and processes. It’s this special formula that makes Form.com the winning option in the Build vs. Buy debate.

Check out our BUYER’S GUIDE for more insights on the Build vs. Buy debate and find out what makes Form.com the best of both worlds.

Form.com Buyer's Guide

Subscribe by Email