Photo by Caspar Camille Rubin | Unsplash
One common decision businesses face is how to get software. The three classic options: buy, build or work with a third party. It’s a decision that can have serious financial and efficiency consequences.
Worldwide IT spending on enterprise software is expected to reach $856 billion in 2023, according to Statista, up from 297 billion in just a decade. It’s big business, and one purchase can have a big effect on a company’s operations.
Brite Nites is a Utah-based company that has been providing residential and commercial holiday lighting since 1993 and has expanded to cover more than 10 states.
In 2016, the company set out to create scheduling software to automate its operations across multiple states. Opting to work with an outside company to develop custom software became an ordeal.
Brite Nites VP of business operations Jaime Lyons originally started the process by drawing up a plan of everything the company wanted in software, from scheduling, HR and finance to truck maintenance. Quotes came in at about $500,000, and they eventually moved forward with an Italian company.
“They said, ‘Great!’ They promised us the world, and after two years, they barely could deliver some sort of scheduling platform,” Lyons says. “It was buggy. It barely worked. We tested it for years and years. They promised us the world and delivered something so subpar.”
That sent Lyons and her team back to the drawing board, cutting down all the extra frills and opting to create a scheduling software that just got the job done. Another $400,000 in, and the company they went with, Go Interactive, was able to get the job done. They still work with the company today.
“Six or seven years later, we’re fully functional. Everything’s beautiful, runs pretty well, and now it’s fun because we get to add whatever we want, add new features,” Lyons says.
Payments continue for continued fixes and updates. With about $1 million into the project, Brite Nites at least has its ideal scheduling software.
To build or to buy, that is the question
Brite Nites’ story of delays and cost overruns is not unique. Harvard Business Review found that the average IT project overrun was 27 percent, but more notable was that one in six projects studied saw a cost overrun of 200 percent and a schedule overrun of 70 percent.
Fears over the price tag, wasted years of inefficiency while testing other systems, and being forced to start over if the first product isn’t up to standard might be enough to steer most companies toward off-the-shelf software. That might be for the best in most cases.
Dr. Steve Elmore is the managing director of business development and advisory services for Fresh Consulting and owns the company’s customer relationship management and contract tools.
In most situations, he says, companies should buy software rather than build it themselves.
“You should build when there is no solution available in the marketplace or [if] customization of an existing platform would be worse than custom dev,” he says.
Lyons agrees, “For most businesses, stay with the kind of software you can buy and use it to its max potential. … Use what’s out there first because I bet it could work for 85-90 percent of companies.”
Developing the perfect fit
Some of the top considerations for every software build or buy are price, security and functionality.
There may be a temptation to go into software development with costs and savings at the forefront of the mind. Lyons says that for her company, price was a factor, “We’d never spent that much money before on software, so we decided to go with a company that promised more.”
Ryan Mackerell, chief strategy officer at Ultradent, a dental products company based in South Jordan with nearly 2,000 employees and worldwide operations, says price shouldn’t be the leading factor in a software decision.
“I think you actually start with functionality. You’re either buying or building some software to do a job for you,” Mackerell says.
Similar to Brite Nites’ decision to whittle down its desired software that had previously included too many features, simple is best.
“The single biggest mistake that I think people make is they go looking for a software solution that is some sort of a silver bullet or a fantastic solution to a problem that they have, and they think that the software, whether they build it or they commercially buy it, that it’s going to cure all that ails them, and that is very rarely the case,” Mackerell says. “My advice to people, and this is something I’ve had to learn over the years, is to really go in and understand the problem you’re trying to solve, what you’re trying to accomplish with the software. And spend the time doing the analysis.”
That analysis means doing considerable research and not taking the word of marketing materials or software salespeople, he says. A lack of market research may force software developers to turn away companies looking to collaborate. At least that’s the case for Dale Richards, owner of Utah-based software innovation firm AppCreative.
“There’s an entire decision that needs to be made upstream from ‘buy or build,’” Richards says. “Is this even a product that should exist on the market? Is there an unmet market need for this product?”
When a customer comes to his team looking to build an app, Richards says he’s always looking to see if the customer “has done due diligence” in assessing the desire for any product that they want to build and take to the market, especially if it’s something they’re looking to monetize.
There are times when building software makes the most sense despite generally being more expensive. Having specific functionality requirements is one reason you may opt to build or at least modify pre-built software.
“You get into the special use cases where the majority of companies don’t need that functionality,” Mackerell says. “The vendor doesn’t put it in there, but they do at least leave the door open wide enough that you can go in and modify their software … [and] create that functionality.”
Ultradent spends millions on software annually and has internal developers and engineers on staff to work with its software products, patch problems and help with any questions.
Commercial applications often have security patches issued regularly, Mackerell says.
That’s important to small companies that might not have staff in-house to issue security patches or explain software to other staff members.
“The most important determining factor should always be security,” Elmore says. “Can you build a secure solution? Can you recover on your own if there is an incident? In most cases, the answer will be ‘no.’”