You're being redirected to Olo

Wisely is now part of Olo. To connect with our sales team, please share your contact details on the form that will appear momentarily.

You'll be redirected in 5 seconds...

Build vs. Buy Restaurant Software Debate: Top 5 Considerations

Jan 12, 2021
min read
Written by
Mike Vichich
This article outlines:
What’s attractive about building restaurant software
Why tech companies have the advantage
Five reasons restaurant brands should default to buy, not build

he restaurant tech stack involves a complex set of inputs and outputs, but historically the industry itself has not been technology forward. Restaurants are racing to design the most seamless guest experience for an increasingly demanding consumer who expects tech-driven brand interactions. As a result, brands often find themselves navigating a mix of legacy tech and newer tools that can be hard to connect. 

As forward-thinking restaurants update and optimize their tech stack, the debate for larger, more resourced brands might shift towards whether to build a restaurant software solution or buy it.

What's Attractive About Building Restaurant Software

Working with external software partners can be complicated. 

Some high-profile restaurant tech companies make the majority of their money from consumer platforms. Restaurants leveraging these solutions don’t control their data, but rather serve as an acquisition tool for the consumer network. These tech companies may even compete with brands directly on search and social, and reroute guests to competitors in their own platform’s interest.

A scaling tech company may also get sold to a large corporation only for the tech roadmap and overall priorities to change. Even more simply, many tech partners fail to deliver on promised tech updates or oversell the future.

And through it all, tech solutions cost money for restaurant brands who famously operate on razor slim margins.

Custom software gives the restaurant brand full control.

The power of building native tech lies in owning the roadmap and defining the priorities—restaurants can determine exactly what matters and build it, even if they’re the only brand in the world that values those capabilities. This is alluring, especially for bigger brands, who might have more resources to take on a custom build.

Arun Nagarajan, CTO of BigSpring and a founding member  of Uber Eats, understands the draw. “It’s always attractive to build,” he said in a webinar with Wisely. “We think, why would I pay someone fifty bucks a month for that, why would I be constrained to this?”

Nagarajan, who hired and managed a full staff of engineers, and guided Uber Eats from $0 to $30B of GMV, understands better than most the costs and complications of native-built software.

Nagarajan explains that despite the allure of full control, “What I’ve learned is that when you build something you can’t just walk away from it, you’re maintaining it. The lifelong ownership and maintenance costs are high.”

The Problem with Building Restaurant Software

Despite the best intentions of building custom restaurant software, brands often find themselves in a quagmire. Restaurants don't specialize in tech.

Even companies like Lyft and Uber use Amazon Web Services (AWS). Why? Because specialization makes for a better outcome. A business that specializes in a solution will put the needed resources, rigorous testing, and world-class team of engineers behind it.

Lyft leverages AWS for their IT infrastructure, data center capacity, etc. so they can focus on building the parts of their product that are actually differentiated.

The same principle applies to restaurant brands. The need for a POS system or reservations platform is commonplace across the entire industry—execution of the food and customer experience is each brand’s differentiator.

Economics drives and powers specialization: 

  • If a tech company builds and launches a product, it can sell it to an entire industry of 100-500k restaurants. At $100 / mo., they can make $120-600M a year.
  • Contrast this with a restaurant brand—an enterprise concept with 2k locations might save $200k/year in SaaS fees. But, engineering salaries alone start at $100k/year in the restaurant vertical (taking into account payroll, taxes, and benefits). So, just two headcount in and a brand can’t even come close to justifying the SaaS savings.

5 Reasons Brands Should Buy Restaurant Software

1) The dollar cost is too high for potential execution failure

Restaurant brands cannot achieve the operational focus of a tech company intent on building a product that will be resold to thousands of clients. Tech companies invest their money, time, and resources into the product design, build, maintenance, and optimization to excel and stay competitive in their vertical.

To build, a restaurant brand could put a year’s worth of SaaS fees (or more) into development (while paying a tech partner to keep ops running during the build) and still not do a better job than a tech partner. And, because the work isn’t ever ‘done’ once a solution is rolled out, the investment doesn’t stop there.

Bottom line. Marginal value invested in the restaurant software application often doesn't justify the marginal cost, because brands are limited on the number of restaurants they can create value for.

2) Tech companies can build a deeper talent bench

Because the economics are better for tech companies, they naturally attract talent. Engineers gravitate to companies where they are paid the best. Aside from large salaries, tech companies often provide equity in their fast growing companies.

On the other hand, restaurant brands have more complex environments — they need ops, culinary, real-estate, marketing, training, in addition to technology.

Since the dawn of the industrial revolution talent has been moving into greater and greater specialization. That trend is exacerbated in the technology industry, which leads us to the next point.

A related added bonus? A tech company taps into knowledge of a wide-range of customers and their guests, intel from competitors, integration partners, and the unique POVs of each specialist on their team—all in the name of building the best possible solution for an entire industry. A restaurant team building in-house is limited to input from a much smaller knowledge base.

3)  Building tech takes focus away from what matters

Werner Vogels coined the term undifferentiated heavy lifting to describe all the hard work engineers do that doesn’t add value to the company. This concept inspired Amazon’s development of AWS. Jeff Bezos put it this way,  “we build muck so you don’t have to.”

In discussing this theory, Nagarajan laid it out simply "building anything is hard. There are things you probably don’t want to build because it doesn’t matter who builds it. If you’re lifting heavy things anyway, lift the things that matter."

Building a memorable, authentic guest experience is what matters most for restaurant brands, and it is already a heavy lift.

4) Building results in too much time to value

If a tech solution really is a priority and solving a unique problem for a business, what is the cost of delaying implementing a solution while it’s built internally?

By the time a tech company finds product market fit they’ve gone through upwards of five iterations of their product, with rigorous testing, bug fixes, and multiple rounds of addressing user feedback.

Buying a solution comes with hard-earned ease of use, advanced features, product stability, and on-going support from day zero. Building custom software means likely having one fifth of the capabilities and ROI on day 365.

Equally as important as time to value is the consideration of points of potential failure once a system is rolled out. Leveraging an outside tech vendor offers risk mitigation against a scenario in which an internal employee exits a company and takes intricate knowledge of a proprietary system with them. (And, a new in-house engineer stepping in could take 3-6 months to ramp.)

5) Beyond dollar amount, the opportunity cost is high

The time spent waiting for a custom-built solution to be ready is not the only cost. The likelihood that a custom-built solution will be underdeveloped compared to existing solutions is high. This will result in missed value that would have come from having a vendor partner that drives results immediately. 

There is also a real probability that a custom-made solution won’t have connectivity across all the other technologies used by a brand, or crucial value-added features. In addition, the difficulty in keeping up with the industry’s evolution at pace will put brands exponentially further behind their competitors. All of this increases opportunity cost long-term.

So, What Business Do You Actually Want To Be In?

The real question restaurant brands need to answer when considering building custom restaurant software is what business do they actually want to be in?

The work doesn’t just stop once software is built (think: integrations, updates/evolution, analytics). An increasingly short tech life-cycle also means that anything built today will be irrelevant in 18 months. The truth is, there is no finish line.

Nagarajan puts it this way, “Your time is the most valuable resource you have—every decision you’re making is an investment decision, not just a point in time decision. Are you willing to own technology, and are you willing to truly invest in it long term?”

There’s already so much that restaurants have to build and also control—financial models, operating systems, training programs, menus. It isn’t worth diverting resources to build custom software, when a good, responsive tech partner will help solve unique problems, ensure a brand has control of and access to data they own, and works with flexible APIs.


When it comes to build vs. buy, the economics usually don’t play out in favor of building a custom solution. The default decision should be to leave the undifferentiated heavy lifting to tech specialists, and put time and resources into what truly matters to their brand.

Photo Credit: Regina Victoria