Restaurant Operations Software: Building the Equal Parts Stack

Most restaurant owners buy software the way most startups buy software: one demo at a time, one problem at a time, until the stack is a pile of logins nobody owns. My position is simple. Restaurant operations software should be chosen the way a good SaaS company builds its go-to-market stack. Start from the guest journey and the weekly operating cadence, pick a small number of systems of record, and refuse every tool that does not have an owner and a job.

I'm Richard Yu, co-founder and Managing Partner for marketing and operations at Equal Parts, a 5,000 square foot restaurant and cocktail bar at 478 Green Street in North Beach, San Francisco. I led concept development, fundraising, vendor partnerships and the operating stack, built on OpenTable and Toast. Before that I spent years building solutions engineering and customer success functions at software companies. This is how that discipline carries over.

Why I Treated a Restaurant Like a Software Rollout

From 2013 to 2019 I was the founding head of solution engineering at Naehas, a marketing operations platform for financial services. Later I built go-to-market infrastructure at ChartHop and led enterprise customer success at Lob for a $90M+ ARR portfolio of Fortune 100 clients. In all three jobs I watched the same thing happen. Software almost never failed because of features. It failed because nobody owned it, nobody was trained on it, and nobody looked at it on a schedule.

A restaurant is a harder version of the same problem. Your users are servers, bartenders, hosts and line cooks working fast, often in their first weeks with you. There is no quiet afternoon to read documentation. If a system is confusing at 8pm on a Saturday, people will route around it, and your data will quietly stop being true.

So when my partners Victor Pichardo, Jacob Cortes and I were building Equal Parts in the landmark Old Spaghetti Factory building, I approached the stack as an implementation project, not a shopping trip. The question was never which tool is best. It was which tools we could actually run, every week, with the team we had.

Start With the Guest Journey, Not the Feature List

Feature lists are written by vendors. Guest journeys are written by you. Before you look at a single demo, write down every moment a guest touches the business and ask two questions for each: what system holds the information, and who on the team owns it. A typical journey looks something like this:

1. Discovery. Someone hears about you from a friend, a review or social media. Owner: marketing.
2. Booking. They reserve a table or decide to walk in. Owner: front of house leadership.
3. Arrival. The host greets them, knows if they have been before, seats them. Owner: host team.
4. Ordering and service. Orders reach the bar and kitchen accurately. Owner: floor and kitchen managers.
5. Payment. The check closes cleanly, tips are handled correctly. Owner: management.
6. Return. The guest comes back and is recognized. Owner: whoever runs guest relationships.

It is the same logic as mapping a buyer journey in software. Once it is on paper, the stack almost designs itself. Most steps land in the same two systems of record, reservations and point of sale. The gaps become obvious, and so do the tools you were about to buy that cover no step at all.

Picking the Systems of Record: Reservations and Point of Sale

In a SaaS company, the CRM is the system of record for customers and the billing system is the record for money. Everything else feeds them or reads from them. A restaurant works the same way. For Equal Parts, OpenTable is the system of record for reservations and the guest relationship, and Toast is the system of record for orders and payments.

Choosing the systems of record first does two things. It forces you to decide where the truth lives, so nobody argues about which number is right in a weekly meeting. And it gives you a filter for every other tool: does it connect to one of these two, and does it make that record more useful? If not, it needs a very good reason to exist.

Then comes the rule I care about most. Every tool in the stack gets a named owner and a one-sentence job. Not a department, a person. If you cannot finish the sentence "This tool exists so that ___, and ___ checks it every week," the tool should not get bought. That single rule cuts more spend than any negotiation, and it keeps the restaurant tech stack small enough that a new manager can learn it in their first week.

How to Evaluate Demos and Pricing Without Getting Sold

I spent six years leading solutions engineering, the team that builds and runs software demos. I know how they are built: the cleanest data, the happiest path, the feature that photographs well. That is not dishonest, it is just a demo. Your job as a buyer is to drag it back to your real Friday night.

Here is what I recommend. Send the vendor a short script in advance: your layout, your service style, the three moments most likely to go wrong. Ask them to walk through those, not their standard tour. Bring the person who will actually use the tool day to day, because they will ask questions you would never think of.

On restaurant operations software pricing, do not compare monthly subscription numbers in isolation. The real cost has several parts, and every one should be in writing before you sign:

• Subscription fees and which features sit behind higher tiers
• Hardware, and whether you own it or lease it
• Payment processing terms, if the vendor handles payments
• Add-on modules you will predictably need within a year
• Contract length, renewal terms and what leaving costs
• How you export your own data if you do leave

The last two matter most. A tool you cannot leave is a tool that does not have to keep earning your business.

Training the Team So the Software Actually Gets Used

When I was scaling a startup post-sales organization from $1M to $20M+ ARR, the lesson that survived every stage was this: adoption is designed, not hoped for. Restaurant operations training is no different.

Train by role and by moment, not by feature. A host needs to master arrival and seating in OpenTable. A bartender needs to ring, modify and close checks in Toast quickly under pressure. Nobody needs a full tour of everything. Short, role-specific walkthroughs beat one long session that people forget by their next shift.

Pick a super user on each shift, someone the team trusts, who knows the system a step deeper and can fix small problems without calling a manager. In software we called these champions. They matter more than the vendor's support line.

Finally, put the stack on the weekly cadence. Look at what the systems of record say, ask the team where the software got in their way, and fix one thing at a time. The unglamorous details are where the work actually happens.

What I Would Tell Any Owner Before Signing a Vendor Contract

At Lob, my team ran strategic accounts with 0% churn. Results like that depend on treating renewal as something earned every month, not something that arrives once a year. Flip that around as a buyer. You want vendors who expect to earn your renewal, and you want to be organized enough to notice when they stop.

Before you sign, I would want clear answers to a few questions. Who is your actual contact after the sale, and what is their response time when service is live? What happens to your guest and sales data if you leave? When does the contract renew, and is that date already on your calendar with a reminder months ahead? Which person on your team owns this vendor relationship?

Then slow down. Opening a restaurant creates pressure to sign everything at once, and vendors know it. The systems of record need to be decided early. Almost everything else can wait until you have run real service and know where the gaps are.

If you want a second set of eyes on your stack or your operating cadence, that is the kind of work I do through the GTM & Operations Plan, and you can book an intro call to see if it fits. I post operating notes from Equal Parts on Instagram.