“I Was Seduced By a Build Scenario": 11 Ways to Avoid This Exec’s Greatest Tech Failure

When it comes to enterprise software, the build vs. buy conundrum is a common one that many companies grapple with.

At first blush, the “build” route for managing SaaS apps seems ideal. Invest some time and resources upfront, and you can create a homegrown, bespoke solution.

However, there are direct and indirect (hidden) costs to building. Plus, there are critical short- and long-term implications you must take into account.

We talk to customers about this topic every day—and admittedly, we are biased about this topic. But we are passionate about helping IT contribute as much value to the business as they can. And if they buy (from a SaaS vendor, at that), they can devote more time to strategic initiatives that drive the business forward instead.

One exec’s greatest failure: “I was seduced by a build scenario … it turned out to be a very poor decision”

At MIT’s 2014 CIO Symposium, ThomasNet President Mark Holst-Knudsen said his greatest business/technology failure was building software when they could have bought it.

After being “seduced by a build scenario,” Holst-Knudsen says he convinced the company to move ahead with it, which turned out to be a very poor decision. Why? Because there was commercially available software that did the same thing, more or less. “It was one of those classic cases where we thought we were ‘different.’ We thought we had a ‘special requirement’ that had to be served,” he says. (The special requirement was that salespeople in the field had to be able to write contracts offline.)

“We weren’t thinking ahead in terms of the age of tablets and ubiquitous connectivity. So that required this syncing challenge, which became really a bear for us and too much to handle. It cost the company a lot of money and time when we could have done things a lot more flexibly and cheaply.”  

Holst-Knudsen says this experience has taught him a critical lesson. He will no longer build things unless it’s absolutely necessary.

“Really, you shouldn’t build anything that’s available off the shelf because it’s not a source of competitive advantage if everybody else can avail themselves of it. The only scenario where you should build is if it’s your core technology—the core source of your competitive differentiation and competitive advantage.”

Research: Software purchases will be the largest category by 2020, and most in-house projects do not succeed

Indeed, although building your own software might seem “seductive,” that allure may be fading. According to IDC research, software purchases will surpass app development in a few years. “While IT services such as applications development and deployment and project-oriented services will be the largest category of spending in 2017 ($275 billion), software purchases will experience strong growth (7.9% CAGR) making it the largest category by 2020,” writes IDC.

Additionally, research shows that in 2015, only 29% of in-house software development projects succeeded. 52% of projects were challenged, and 19% failed. (Success is defined as being delivered on time and on budget, with a satisfactory result.)

What does all this research indicate? Perhaps companies are realizing that the road to a perfect in-house solution is littered with too many challenges. Perhaps they’re opting for the “buy” option given the rising popularity of SaaS and all the benefits it confers.

Before you start building your own solution to manage SaaS apps, ask yourself these 11 questions. 

11 questions to consider

1. Does building offer a competitive advantage?

Will building your own solution make you better than the competition?

Barb Darrow writes, “[Convention holds that] companies should buy what they can and reserve their BYO chops for the most core, valuable assets.” And if you recall, this was the same lesson that Mark Holst-Knudsen, President of ThomasNet, learned the hard way. Many other experts agree.

Can you build something that’s faster and more efficient than your competitor’s clunky legacy technology? Will this set your company apart from the pack? If not, then there’s little value in building.

2. What’s the build cost?

Many companies opt to build because they think it’ll save money in the long run. They think an in-house product is “free” to build—you have to pay your engineers anyway, so it’s a sunk cost—and free to deploy in perpetuity.

But software development and IT resources are still a cost. And they are not cheap. Think about how many engineers you’ll need, as well as what their salaries are. Servers and storage also represent a cost. BareMetrics has a great Build vs. Buy calculator to help guide your cost analysis. Just input a few variables, and it spits out how much you’d save annually, as well as if/when it might be worth it to build (i.e., how many years it’d take to profit, if ever).

3. Have you taken all potential engineering restrictions into account?

“When you begin a project, the software that you are ‘going to build’ always looks better than the software someone else already has because you haven’t yet run into the limitations that inevitably show up in software engineering. As such, we will buy wherever we can,” writes Timothy Campos, former Facebook CIO.

4. What’s your estimated build/implementation time? (It’s often underestimated)

How long will it take to meet with stakeholders to determine the business’s needs, and then have engineers configure, write, QA/test, deploy code, build integrations, train others, etc.?

Build time is longer than you think. Specs change; delays happen. According to Matt Mazur, data scientist at Help Scout, estimating completion time is often incredibly difficult. “A one month project could easily turn into four after all is said and done. The more complex the project and the longer it will take to build, the more you should lean towards buying,” he writes.  

“The further out those predictions go, of course, the less reliable they become. Headcount and person-hours necessary for development and support is often a total guess unless you’re working in an organization that has done this sort of work before,” writes Blair Reeves, Product Principal at SAS Software.

There’s always the risk that in the end, building ends up being more expensive than buying, because build delays are lengthy and costly.

5. What’s the opportunity cost?

What alternative projects could your in-house team be working on instead? How else could they be innovating and adding value to the business? By dedicating time and resources to building this homegrown solution, how much revenue are they not making?

“Next thing you know, you’ve spent literally hundreds of hours building a tool that’s not core to your business. Hours that really hardly saved you any money,” writes Josh Pigford, Founder of BareMetrics.

“But worse than that, it was hours that weren’t spent making more money by improving your core product. Not only did you save an insignificant amount of cash, you actually stifled future cash. /facepalm”

6. What’s better: Using a 90% solution immediately, or waiting indefinitely for a 100% solution that may or may not succeed?

Many companies balk at buying an off-the-shelf product that satisfies only 90% of their business needs. They need to satisfy 100% of their requirements, they believe, in order to see any value out of the product—hence their decision to build.

But given the improbability of successfully building and deploying your perfect pie in the sky solution, the “buy” alternative might be more pragmatic.

“In my experience software usually takes much longer to build than initially expected, so it winds up making more sense to pay for a 90% solution that you can have immediately and devote those engineering resources to the core business,” writes Mazur, who also says he usually defaults to “buy” unless there is a compelling reason to build.  

CIO.com makes the same recommendation. “Assuming normalized fit scores where 100% means all requirements are fully met, if several cloud or off-the-shelf products have a fit score of 80 percent or more, then buying is the right way to go.”  

7. What is the maintenance cost (and who will maintain it?)

Once you build a product, you have to maintain and upgrade it regularly. How much will that long-term support and upkeep cost? Is maintenance even feasible? Who will maintain it continually? What happens if those engineers leave the company, or become swamped with other projects? Maintenance will never be your team’s top priority (in fact, it will be an additional burden), but it will always be of prime concern for a third-party vendor.

“Engineers do not stay on the same project forever. Engineers frequently change projects and teams. It is not enough for one manager to have a maintenance plan. An entire management team needs to plan resource allocation for years to come on every new product built in-house,” writes Segah Meer, Chief Data Consultant at Cauta & Co.  

8. How will you scale and adapt?

Once you’ve deployed your product, how will you scale and adapt its functionality?

Business requirements inevitably become more complex. Technology changes, evolves, becomes deprecated. Admins want to see enhancements and new features.

“Even if [companies] can maintain it—they can’t evolve it,” writes Jason Lemkin, Founder and VC at SaaStr.

This is where SaaS vendors are invaluable. They will scale and hire more engineers whose sole purpose is to make the product better.

“That richness of feature set and experience can never be replicated by an in-house solution. Those go stale in a year, at least, almost always.”

Likewise, Reeves writes: “The cost of software needs tends to scale non-linearly, meaning that beyond a certain point, it’s hard for any one company to justify the additional spend necessary for top-of-the-line systems. SaaS vendors can and do, because we rely on those systems to make our software scale.”

SaaS vendors enhance their products by building in best practices that are driven by customer feedback. They anticipate how business needs will evolve, working to “future-proof” their product.  They are proactive, whereas in-house teams can only be reactive.

9. Who will be accountable for the product’s reliability?

When things break, or when there are bugs, who will be invested enough to fix them ASAP?

Meer brings up a solid point about SaaS: The entire industry survives because of renewals. As such, it’s in a SaaS vendor’s best interest to provide best-in-class products.

“Vendor supplied tools are more reliable than in-house solutions that are not core to the primary business because vendors have to respond to feedback or else they go out of business,” he writes.

Vendors are incentivized to go above and beyond—i.e., be fully accountable—when it comes to customer service, troubleshooting, and product development. Your internal team will not be, because they have a day job (aka your core business) that they must focus on.  

10. How will you secure it?

Given the rise of data breaches in recent years, security is paramount. Companies are increasingly trusting SaaS vendors to house their critical information. After all, SaaS wouldn’t be a common system of record today unless these apps were highly secure.

But many companies who opt to build their own software do not have experience in security best practices. After all, securing software isn’t their bread and butter. Reeves points out that software vendors, on the other hand, are heavily incentivized to invest in high security and are much more secure than in-house solutions.

“Building and maintaining high-quality software is literally all we’re paid to do, and software companies are able to attract and invest in the best talent and infrastructure systems available to do this,” he writes.

“Generally speaking, retailers, airlines, banks and other non-software firms are not. Building software is just not what these companies do—it’s something they typically invest in only insofar as it allows them to do the thing that keeps them in business.”

11. Why reinvent the wheel?

And finally, as a parting thought: Why bother inventing the wheel? SaaS products are the result of work by dozens of engineers, hundreds (likely thousands) of hours of R&D, and copious amounts of customer feedback. “If a problem has been adequately solved in a commercial product, why solve it again? Why not focus on a new and more interesting problem?” writes CIO.com.

Conclusion

Of course, your answer to the build vs. buy dilemma depends on many variables: business needs and goals, resources available, timeline, the size of your company, your industry, etc.

But CIO.com sums it up quite well.

“If an organization has an in-house development team, there is always the push to build because they can supposedly satisfy all needs. However, from my experience and observation, it is usually far cheaper and faster to buy than to build,” writes CIO.com.

“While it takes significant work to execute properly, the costs of making the wrong decision will be felt for years. On the other hand, the consequences of the right decision can resonate with the bottom line for decades or more.”

BetterCloud has a team of 90+ full-time engineers solely dedicated to maintaining, scaling, enhancing, and improving our product. We’ve spent the last two years rebuilding our entire product from scratch, spending $35 million to become the first-ever SaaS Application Management and Security Platform. We’ve released 50+ features this year alone. To learn more, visit https://www.bettercloud.com/product.