Buy or Build Software? How Leading CIOs Make The Right Call For Their Restaurants

As your company grows and market demands evolve, your current systems may struggle to keep up. At this point, you’re faced with a crucial decision: which parts of your tech stack should you buy off-the-shelf, and which should you custom-build?

At first, I thought the answer was obvious: Why build what you can buy? 

Developing software is costly, time-consuming, and complex—I should know, being the co-founder of a software company. But the more I explored, the more I realised that the buy-vs-build debate is far more nuanced. The choice isn’t black and white. 

This article started as a personal exploration. I asked restaurant industry leaders for their insights, and my notes eventually turned into this piece. 

What I didn’t expect were the hidden traps that even experienced IT leaders fall into when making these decisions. 

In this article, we’ll dive into those pitfalls—and how to avoid them while staying ahead of the competition.

Emerging Brands Vs. Established Companies

Let’s start with what is commonly understood: buying software offers faster implementation and lower risk, but limits customisation. On the other hand, developing your own software provides complete control and the potential for a competitive edge, but it requires more time, costs, and resources. 

CTOs, CIOs, and IT leaders must regularly choose between these two options. Unfortunately,  understanding the top-level arguments doesn’t make the choice any easier. The number of variables involved is insane. There is no straight answer to the ‘buy or build’ question. 

One thing, however, is very clear: young companies hold an advantage. Why? Because they can start with a clean slate. They aren’t burdened by legacy systems or outdated practices. It allows them to implement technology with minimal friction, whether they develop it themselves or partner with a SaaS vendor.

For established businesses, the situation is more complex. As they scale or modernise, they need to integrate new technology into existing systems and processes. 

Software upgrades can be costly, disruptive, and sometimes ineffective, while workarounds often lead to inefficiencies and missed opportunities.

For these companies, the question isn’t just about finding the best solution—it’s about determining how much customisation is truly necessary. This is where some organisations stumble, convinced as they are, that no other company works quite like them. 

Overestimating Uniqueness

Companies can easily overestimate their uniqueness and lean toward custom-built solutions when an off-the-shelf option might work just as well or even better.

The allure of full control when developing homegrown software is understandable—it promises complete customisation to meet unique or specific needs. 

For many companies, there’s a solution that covers 90% of their needs, yet they burn tech resources just to manage the few exceptions they have.

Mike Rawson
CIO at citizenM

But, as Mike Rawson, CIO at citizenM, points out, “For many companies, there’s a SaaS solution that covers 90% of their needs, yet they burn tech resources just to manage the few exceptions they have.” 

They end up replicating tried and tested functionalities readily available in the market, but aren’t getting the benefits a ready-made solution offers, like ongoing updates, bug-fixes and scalability. 

Competitive Advantage vs. Closing Performance Gaps

On the other hand, some companies, of course, do develop a unique method of operation. It helps them stand out in a brutally competitive market. And if technology can drive that differentiation, investing in custom development is well worth the risk. As the IT director of a 500-unit restaurant chain said, “Buy for parity, build for competitive advantage.”

Starbucks is a good example. Their approach to service gave them a huge competitive advantage. Technology helped bring their vision to life. But the real advantage wasn’t the tech—it was the vision itself. “A brand’s identity, its personality, is often the true differentiator,” says Mattias Boterdaele, Transformation & E-commerce Director at La Lorraine Bakery Group. The software is a means to an end.

Besides, every technological edge fades eventually. On our podcast, The Food Service Growth Show, Peter Schimpl, VP of Digital & IT at L’Osteria, used McDonald’s as an example.

“McDonald’s is five years ahead of everyone. When they introduce something, it’s seen as innovation. Order kiosks are a good example,” Peter says. “Not every innovation fits all, but over time, some become industry standards. Today, it’s hard to imagine a QSR without order kiosks.” 

What was once a clear differentiator is now an industry standard. It’s the norm. “It means not having order kiosks has become a disadvantage for QSRs.” Restaurant chains that adopt kiosks today aren’t gaining an edge; they’re merely closing a performance gap.

When a certain solution has been in the market long enough, it becomes the bare minimum for doing business.

Geert Houben
Founder and CEO at Cubigo

“When certain software has been on the market long enough, it becomes the bare minimum for doing business,” says Geert Houben, founder and CEO of Cubigo. In such cases, developing the software in-house makes little sense.

Examples are everywhere, including reservation tools, kitchen displays and inventory management systems. If your goal with a custom build is to gain an edge over the competition, you need to be sure no one will be able to catch up with you anytime soon. It’s a risk. 

“You simply can’t maintain a competitive advantage with technology that your competitors can easily purchase off the shelf. It’s just impossible,” says the IT lead of a large catering company.  

Best of Breed

So, what do you do? For non-strategic functions like HRM, accounting or CRM, it’s clear. Almost everyone agrees that SaaS is the best choice. It’s fast, comes with support services, and offers predictable costs. However, as Benoît Dewaele, CIO at Vandemoortele, points out, “When no SaaS partner can provide the required functionality at a reasonable cost, we may need to consider building the software ourselves.” 

This was the case for Ville Lehto, co-founder of Huuva, a popular multi-brand restaurant. They developed a custom operating system so their kitchens could run seamlessly while preparing hundreds of daily food delivery orders.

“Order processing for food delivery orders typically follows a first-in, first-out principle, but operationally, for us, that doesn’t always make sense,” he says. “For example, if two burgers are already being prepared, bundling any upcoming burger orders with them is more efficient. So, we built functionality that makes it intuitive to bundle upcoming orders similar to the ones we are already preparing. This halved our prep times and sped up service immensely.”

But Huuva doesn’t custom-build everything. “Complex needs, like inventory management, would take too many hours to develop and maintain in-house. For that, we preferred to integrate towards Apicbase, which has worked out really well.”

Geert Houben follows a similar best-of-breed approach: “We buy technology for functions where it’s more efficient to rely on experts, like Apicbase, and we focus our development on ensuring seamless data integration between the systems we build and those we buy.”

Metrics That Matter

As Benoît Dewaele points out, investing in SaaS only makes sense if the value justifies the cost. However, “value” can be vague and hard to measure—much like “competitive advantage.” Both can be subjective and differ wildly between companies and industries, which doesn’t sit well with CTOs and CIOs. They prefer concrete, measurable arguments.

They use several indicators to guide their decisions. Each provides insight into different aspects of the tech choice. Here are the key ones:

1. Go-to-market (GTM): How quickly does the new feature or solution need to be operational to meet market demands or outpace competitors? 
2. Time-to-value (TTV): How soon will the solution deliver measurable, impactful benefits to the business? 
3. Return on investment (ROI): How quickly will the investment pay off, factoring in savings, revenue growth, and operational efficiency?
4. Total cost of ownership (TCO): What are the total, long-term costs associated with custom-built software, including development, ongoing maintenance, updates, and even potential tech debt?
5. Scalability: Can the solution grow alongside the company, or will it need to be replaced or heavily modified in the near future?
6. Control: How much flexibility and control does the company need over the software and its features? 
7. Risk: How much risk is the company willing to take with a third-party solution versus the risks inherent to in-house development?

These criteria offer valuable guidance, but they don’t make a company immune to blind spots, biases, or miscalculations, as we’ll explore in the following sections. 

Underestimating Costs

Underestimating costs is probably the most common bias. Companies are often overly optimistic about their ability to finish a project within a set budget or timeline.

We thought we had a handle on it, but we only knew about 5% of what was actually needed.

Tommy Giraux
Head of Restaurant Systems at Honest Burgers

“We thought we had a handle on it, but we only knew about 5% of what was actually needed,” admits Tommy Giraux, Head of Restaurant Systems at Honest Burgers.

Tommy has led many successful tech implementations, but one stands out in his memory precisely because it didn’t go as planned. It started with a straightforward goal: “We needed to streamline our workforce management. At the time, we were using Excel, but that didn’t give us the visibility we needed”, he says. It seemed an easy development, turning the spreadsheets into an app, so Giraux brought in a developer to build a custom tool. 

That’s where things went wrong. “We overestimated our understanding of the problem and underestimated the solution”, he says. By the time they scrapped the project, a hefty amount of money had already been poured into it—with nothing to show for it. “We didn’t even have a viable product,” Giraux recalls.

That anecdote reminds me of an experience I had with a large restaurant group. They decided to build their own inventory system, convinced by the board that going in-house would be cheaper in the long run. They poured significant time, money, and resources into the project. Fast-forward 18 months, and they had little to show for it. What made it worse was that their IT lead had warned the board from the beginning that they were making a mistake. 

He later told me, “You know what bothers me the most? Over those 18 months, we spent three times as much on something that went nowhere compared to the ROI we would’ve gained in just six months with Apicbase.”

Problem-Solution Cycle

These experiences drive home a common issue with custom development: even if the project looks simple, the actual development process hardly ever is. 

You go from problem to solution to more problems. Every issue you fix brings about a host of new ones. As a foodservice company, you need to be ready for that. 

What seems like a small, manageable task can quickly spiral into a much bigger, more complicated (and expensive) endeavour than anyone expected. It’s an ongoing cycle. You go from problem to solution to more problems. Every issue you fix brings about a host of new ones. As a restaurant company, you need to be ready for that. 

Take it from me—I’ve seen it firsthand. At Apicbase, we’ve gone through the problem-solution-problem cycle more times than I can count. 

For example, when we began building our inventory management system, we thought, “We already have a recipe database—how hard can it be?” Turns out, very hard. After integrating with POS systems, the next challenge was stock counts, followed by semi-finished products. Then we had to figure out how to transfer products between outlets. And after that, “What if you run a central production unit?”. And so, the cycle continued, not to mention the inevitable bug fixes along the way.

It’s never as simple as it seems, and you need to be ready for those twists and turns.

Sunk Cost Fallacy

By the way, underestimating a project’s complexity is the “gift” that keeps on giving. If companies don’t step in early, they risk falling into the dreaded sunk cost fallacy.

The sunk cost fallacy is a cognitive bias that leads people to stick with a losing strategy, even when cutting their losses and shifting to a better option would be the smarter move.

The sunk cost fallacy happens when companies keep investing time and money into a failing project, simply because they don’t want to “waste” what they’ve already put in. 

The problem with this mindset is it can have lasting consequences. One CTO shared his experience: 

“My predecessor invested heavily in a system that went nowhere,” he explained. “The project dragged on, cost a fortune, and delivered nothing. Now, the board is extremely hesitant to greenlight any new technology initiatives in that area.”

As a result, valuable tech projects get overlooked, which means missed chances for growth, improvement, or staying relevant in an industry increasingly fuelled by data. 

Future-Proofing

When evaluating metrics like TCO or TTV, along with common mistakes like underestimated costs or the problem-solution cycle, one key challenge becomes clear: our inability to predict the future. This uncertainty makes CFOs and CTOs uneasy.

They would buy a crystal ball if they could because they know that if they build a solution that only addresses current demands, it risks becoming obsolete by the time it’s launched. Software development isn’t just about solving today’s problems—it’s about preparing for challenges you can’t yet predict. 

As the market and tech landscape evolve quickly, your software must be flexible enough to adapt to unexpected changes.

This doesn’t just require technical foresight. “You also need the financial resources to keep pace with ongoing development,” explains Geert Houben, CEO and founder of Cubigo. “Can your system adapt to a new version of iOS or Android? What happens when your APIs—the connections between different software—require updates? Is your entire infrastructure at risk?”

The future is unpredictable. Few anticipated how crucial software integrations would become a decade ago, yet APIs have reshaped the technology landscape. Anyone building software will face unforeseen challenges—larger data volumes, more users, new regulations, and evolving integration needs. Whether you build custom software or use a SaaS solution, your systems must be adaptable and robust to stay relevant.

Future-proofing isn’t just about technology either—it’s about people, too. As Mike Rawson says, “If you decide to build it yourself, you better have the right people.” Custom software development requires a skilled team to maintain and evolve the system as new challenges emerge. With IT talent in high demand, the real question is: can you attract and retain the right people to see the project through? 

With IT talent in high demand, the question is: can you attract and retain the right people to see the project through?

A comment from an IT professional on Reddit pushes this challenge even further: “It’s not just about whether your team has the skills to build the solution. The real question is, do they have the time? Most of your team is likely focused on your most pressing business challenges. So, with whoever’s left, do you have the capacity to build what you need or maintain what you have? And more importantly, what are you giving up? If you’re building something, you’re not focusing on something else.”

Conclusion

The decision to buy or build is never simple. It’s a balancing act between: control and cost, speed and customisation, immediate needs, and long-term strategy. Every business must weigh these trade-offs with clear-eyed realism, whether emerging or established. 

One truth stood out: a hybrid approach is usually the best route. It’s a buy-AND-build strategy. Buy for non-strategic needs to save time and resources, and build only where you can truly gain an edge.

For the software that keeps your business running smoothly, you need stable, proven technology, as Mattias Boterdaele of La Lorraine Bakery Group emphasised. An inventory system, for instance, must reliably track stock depletion and replenishment. Once you have that solid foundation, company-specific tools—like a data lake—can be built in-house to meet your unique needs.

And if you choose to build, be sure it’s worth the effort—steer clear of the pitfalls of underestimating complexity, overestimating uniqueness, or falling into the sunk cost fallacy. 

Ultimately, the right choice depends on your company’s needs, capabilities, and vision for the future. But whatever path you take, prioritise scalability and flexibility. After all, in this industry, change is the only constant.