Should you buy enterprise applications from a startup?

The idea of buying an enterprise application from a startup company might sound like anathema to a CIO. But Chris Laping, CIO of restaurant chain Red Robin, based in Greenwood Village, Colo., disagrees. He believes we’re in the middle of a significant shift that favors startups — moving from huge applications with extensive features to task-based activities, inspired by the apps running on mobile devices.

Mirco Mueller concurs. He is an IT architect for St. Gallen, Switzerland-based Helvetia Swiss Life Insurance Co., which — having been founded in 1858 — is about as far from a startup as possible. He recently chose a SaaS tool from an unnamed startup over what he calls “a much more powerful but much more complex alternative. Its list of features is shorter than the feature list of the big companies, but in terms of agility, flexibility, ease of use and adjustable business model, it beat” all of its competitors.

The biggest advantage of startups, in Mueller’s opinion? “They have no technical historical burden, and they don’t care about many technical dependencies. They deliver easy-to-use technology with relatively simple but powerful integration options.”

There’s certainly no lack of applications available from new players. At a recent conference focusing on innovation, Microsoft Ventures principal Daniel Sumner noted that every month for the last 88 months, there’s been a $1 billion valuation for one startup or another. That’s seven years and counting.

But as Silicon Valley skeptics like to point out, those are the ones you hear about. For every successful startup, there are at least three that fail, according to 2012 research by Harvard Business School professor Shikhar Ghosh.

So why, then, would CIOs in their right mind take the risk of buying enterprise applications from an untested entity that may be short on experience, money and maybe even time?

Because the world has changed. “The model we’ve used to buy on-premises software for 20-plus years is shifting,” insists Laping. “There are new ways of selecting and vetting partners.”

Part of that shift is simple: The business side sees what technology can do, and it’s banging on IT’s door, demanding … what? Not new drop-down menus in the same-old ERP application, but rather state-of-the-art, cutting-edge, ain’t-that-cool innovation. The landscape is wide open: Innovation can come in the form of new technologies, such as the Internet of Things, or from mobility, the cloud, virtualization — in fact, from anywhere an enterprise vendor isn’t filling a need. The easiest place to find that? Startups.

The fact is that every technology giant today exists because someone took a chance on them, the way Disney took a chance on Bill Hewlett when it bought eight oscillators at $71.50 each in 1938, the year before Hewlett-Packard was founded. Recent examples of 21st century ventures that hit it big include Palantir (est. 2004), Workday (2005) and Dropbox (2007).

It may not be so smart to bet on a startup that thinks it’s going to dislodge Salesforce as the go-to CRM application, suggests Patrick Sullivan, Managing Director of the Oracle technology practice at Accenture. “But startups can focus on the right gap in enterprise applications. The startups that find niches and innovate have done okay.” He cites Kony (a mobile application development tool) and Splunk (which logs machine-generated data) as two examples of startups that found their niche.

The risk-reward ratio

Like Laping, Karl Galbraith believes that the time has come for enterprises to consider startups. Currently a principal at security-and-audit-focused Galbraith and Associates in Ottawa, he was previously a CISO and acting CIO at various enterprises, including the Canadian Bank Note Corp and the several Ottawa-based start ups in security and legal domains.”The number one reason to consider a startup is that the current landscape of Magic Quadrant vendors is not serving a critical need. That’s a problem.” Especially in security, he says, some of the solutions from traditional security vendors are so unwieldy that “even after months and a lot of money invested, they never worked.”

The same concept applies to startups beyond security. Faced with an inability to get what they want without buying extensive solutions from established enterprise vendors, proactive CIOs started looking for tools with a new willingness to take risks, to listen to people who are more aggressive. With startups, Galbraith says, “CIOs get a view of next-generation technology. Whenever there’s a paradigm shift, you want a startup to give you feature agility.”

Ravi Belani is managing partner at Alchemist Accelerator, a Palo Alto, Calif.-based venture-backed initiative focused on accelerating startups whose revenue comes from enterprises rather than consumers. He says, “The innovation that used to come out of big software houses isn’t there anymore, while the pace of innovation in technology is accelerating.”

He acknowledges that there has been a longtime concern with startups about the ability of their applications to scale, but given startups’ ability to build their software on robust infrastructure platforms using IaaS or PaaS, and then deploy them via SaaS, “scalability isn’t as big a deal as it used it be. It costs $50,000 today to do what you needed $50 million to do ten years ago. That means it takes less capital today to create the same innovation. Ten years ago, that was a moat, a barrier to entry, but software vendors don’t own that moat anymore.”

The confluence of offshore programming, open source technologies and cloud-based infrastructures has significantly lowered the barriers to entry of launching a new venture — not to mention all those newly minted tech millionaires willing to be angel investors.

Another knock against startups: The potential that they won’t be around in a few years. Laping disdains that notion. “In the new paradigm, [most software] implementations are so much shorter, you don’t have to think about that risk. You’re not talking about three years and $20 million. You’re talking about 75 days and $50,000. You implement little modules and get big wins along the way.” (See Making it work for suggestions on how to protect yourself against their failure.)

Besides, he argues, there are related risks to bigger vendors. “We worked with one startup that got acquired because they represented innovation to the bigger company. They had been a small company with rapid product cycles, but the next four release cycles were nothing but integrating their software with the big company. That gave me no benefit.”

“It’s a huge risk to go with a startup,” acknowledges Arthur Lozinski, CEO of Oomnitza, a Mountain View, Calif.-based developer of asset-tracking software founded in 2012. “But startups can give enterprises attention to detail and fast turnaround times. We’re not doing anything else” except thinking about our product, he says.

“There’s a lot more intensity and energy at a startup,” agrees Brian Gardner, executive director of the mobility center of excellence at Oakland, Calif.-based healthcare provider Kaiser Permanente. Kaiser has tested a number of niche startup applications over the last few years, purchased a few and tested some it never pursued, according to Gardner. Startups’ focus “is on one product. [In IT] we’re working on multiple products at the same time with multiple stakeholders, and having to balance that through the workweek and quarter. They don’t have the distractions that we do.”

The rewards

CIOs who’ve bought from young ventures acknowledge the risks and the rewards and are eager to share best practices in making a startup partership work.

First and foremost, CIOs have to find the value in the new venture. “It’s got to be something worth taking the risk,” says Jonathan Gardiner, vice president of IT customer solutions for DHL Supply Chain Asia-Pacific in Singapore. He acknowledges that it may be difficult to find that little niche where startups fit, but he also notes that a number of startups originate “from people who were in the corporate world and who understand what an enterprise-level app needs to be” — and not just from the newly minted engineering graduates that come to mind when people think “startup.”

For Oliver Binz, an independent management consultant for IT and risk management based in Brisbane, Australia, startups for CIOs aren’t any different than startups for investors. “They’re always going to have higher risk than an established company, but you invest in one because the return is likely to be greater.” But that also means you must apply other safeguards. “To take the analogy further, don’t invest in a startup if you can’t afford to lose your money or live with the consequences if it fails.”

Multiple aspects of new ventures appeal to CIOs. Startups are hungry. To use a word that comes up a lot, they’re nimble. They’re also focused and responsive. DHL’s Gardiner notes, “You can pick up the phone and directly call the guy who knows how the code works. You get a good level of response and agility when you use a startup. That is an upside.”

CIOs may legitimately ask why — if they just need someone to focus on a project — they can’t simply build what they need themselves. “Creating a startup within a corporate setting is a great way to innovate, but there will be distractions — the processes, the way things are done, the sheer legacy of the organization,” says Kaiser Permanente’s Gardner, himself a veteran of two startups.

Making it work

When you’re taking risks, never underestimate the importance of relationships. CIOs and entrepreneurs alike confirm that it’s easier to connect when there’s a trusted middle conduit. Red Robin’s Laping says, “As open-minded as I am, I won’t take a cold call.” He only meets with startups he’s met through a “matchmaker” called Trace3 that brings together CIOs, venture capitalists and entrepreneurs. That’s important, he adds, because when you’re looking for a startup, “it’s not like you’re going into a bar to pick someone up. I rely on my peer network or partners to tell me about someone they’ve run into” who can meet a specific need.

Pedigree counts too. That means looking at what venture capitalist firms or angel investors are backing the startup, or simply checking out the top executives’ resumes. Notes Accenture’s Sullivan, “The guy who started Nest came out of a well-established product company called Apple. It had processes, it had quality control and he took that knowledge along with some of its employees.” Along the same lines, Oomnitza’s Lozinski spent several years at SAP Labs.

Sometimes to make the relationship work, CIOs need to apply special dispensation. In a previous position, Peter Bowen, who now manages a team of consultants at Bedford, UK-based Telesperience Consulting, bought a billing application from startup Centenary Services (which has since been purchased by another company). Bowen’s company promised to make payments on faster terms than it did to other suppliers in order to help the startup avoid cashflow issues. “Basically, we micro-managed the whole process,” he says. “Buying from a startup can be good, but you need to make sure the fledging does not get killed before it has learned to fly. You should be prepared to provide a helping hand.”

One of the biggest issues both CIOs and entrepreneurs cite relates to product support — something that can overwhelm the startup and leave the enterprise frustrated. At Red Robin, Laping engaged San Francisco-based Firespotter Labs, which had developed an application for iPads named NoshList. It’s essentially a self-service waiting list that texts walk-in customers when their table is ready. Though such a capability is more common today, Laping says, he believes that Red Robin was one of the first national chains to tackle this.

Even though he had “never had a support issue” with Firespotter, when Red Robin launched the NoshList pilot, Laping initially made it available to only 50 restaurants, with the proviso that the restaurant staff itself had to be prepared to provide support. Laping insisted that the employees use the chain’s internal social network to share support questions and answers among themselves, rather than banging on his IT staff. Another method: Let the startup train IT staff to provide tier 1 support, while still relying on the startup for tier 2 support.

It’s also a good idea to protect yourself through various methods of acquiring the code for an application in the event a startup fails. These include setting up escrow accounts for the code, or — if the startup decides to take the company in a different direction — setting up a plan to acquire early versions of the code so, if needed, the enterprise can integrate it itself into its own ecosystem.

CIOs may have to even go so far as to determine how working with untested companies may affect their reputation. “Think about whether it fits with your brand,” advises consultant Galbraith. A conservative bank that’s found to have used a security startup but still suffers a breach is not a story a CIO wants to see in the press.

“But if you’re the Canadian space agency and you’re using a grid-computing startup, that’s okay,” Galbraith says, “because you’re supposed to be leading edge.”