Custom POS System Problems for Restaurant Chains: The 6 That Break at Scale, and How to Avoid Them

Why does menu and price governance get scoped last?

Because it is the least visible thing on a demo screen and the most operationally expensive thing to get wrong. Everybody scopes the order engine, the payment flow and the kitchen display, and the menu is treated as data that will be loaded rather than as a control surface that head office needs on a Thursday afternoon.

At three locations that is fine. At forty it is the whole problem. A price change has to reach every store before the Friday rush, with the exceptions your franchise agreements permit and no others. A limited time offer starts on a date and must stop on a date, in every market, without a district manager driving anywhere. An item goes out of stock in one store at six in the evening and has to disappear from that store's delivery menus in minutes rather than at the next sync.

Governance means modelling the menu as a hierarchy with an owner at each level. A corporate item with a corporate price, a regional override where the market genuinely differs, and a store level availability toggle that never touches price. Every change carries an effective time, an author and a target set, and the system reads back to confirm each store actually applied it. Without the read back you have a broadcast rather than a control, and a broadcast that silently misses store eleven is how you sell a promotional item at full price for a week.

What goes wrong when menu, modifier and loyalty data migrate?

Menus look simple in an export and are not. Modifier groups are where restaurant migrations actually break, because packaged systems each model them differently and the differences are invisible until a ticket prints wrong.

Expect four specific problems. Modifier pricing that was expressed as an absolute in one place and a delta in another, so a paid substitution silently becomes free or doubles. Nested modifier groups that exceed the depth the new system supports, usually on build your own items, which means somebody has to redesign the item rather than import it. The same physical product existing under several item codes because different locations added it independently, which destroys any cross store item velocity report until it is merged. And recipes attached to items for inventory purposes that were never maintained, so importing them produces theoretical usage numbers nobody should trust.

Loyalty is the higher risk item because guests hold balances and will notice. Reconcile point balances and stored value separately from menu work, freeze accrual during the cutover window, and publish balances to guests in parallel for a period so discrepancies surface while both systems are available. Never migrate a stored value balance without a signed off reconciliation, because it is money and a rounding rule difference across thousands of accounts is a real number.

Why do delivery marketplace and accounting integrations break after launch?

Marketplace integrations break because the menu is a moving target and the reconciliation is genuinely hard. Orders arrive with the marketplace's own item identifiers, its own promotional discounting, its own commission and adjustment lines, and its own idea of when a refund happened. If your integration only ingests the order, your revenue per channel is a guess and your item margin across channels is unknowable.

What is required is a reconciliation layer that matches every marketplace order to a payout line, holds the commission, promotion funding and adjustment separately, and reports the gap. Operators who build only the order path discover in month three that they cannot answer whether delivery is profitable at item level, which was one of the main reasons they left the packaged system.

Accounting breaks more quietly. A transaction level sync to QuickBooks or Xero is straightforward until you hit the cases nobody scoped: tips split across a shift, comps and voids that need to post differently, refunds crossing a period boundary, and gift card liability that is not revenue. Each is a mapping decision that belongs to your controller, not to your developer. Get those decisions written down before the integration is built, because retrofitting them means restating a period, and restating a period means a bookkeeper doing by hand exactly what the platform was supposed to eliminate.

What happens when offline card capture and PCI scope are not covered?

Every restaurant loses connectivity. The question is whether service stops. Offline behaviour has to be designed rather than hoped for: orders continue, tickets still route to the kitchen, cards capture locally against defined limits, and everything reconciles when the link returns, with a clear rule about what happens to a capture that later declines.

The failure mode is subtle. A system that appears to work offline but queues captures without limits will happily accept forty transactions it cannot settle, and the operator discovers the loss two days later. Set the limits explicitly, surface the offline state on the terminal so a manager knows what mode they are in, and decide in advance which order types are refused while offline rather than leaving it to a server at the counter.

Cardholder data scope is the other boundary and it is far cheaper to design than to remediate. The correct architecture keeps the platform outside scope by using a processor integration where card data goes device to processor and your systems hold only tokens. A developer who waves off the question has not been through an assessment. Put the boundary in the statement of work as an explicit constraint, with a change order required to alter it, and ask specifically how offline capture works without holding card data, because that is where naive designs fail.

Should you build custom or configure what you already own?

Under roughly eight locations, stay on packaged. Square and Toast will keep pace with you, the build cost will not clear against per terminal savings, and you will spend management attention on software instead of on restaurants. Between eight and fifteen it becomes a genuine decision that turns on delivery volume and how badly the reporting gaps hurt. Above fifteen, and especially in a franchise model, ownership usually wins on total cost and control within three years.

Before you price a build, exhaust the configuration path honestly. Take your three worst operational problems, write them out precisely, and ask your current vendor to demonstrate the fix in a test environment with a date attached. Many chains discover that one of the three is already solved by a module they are not using, one is solved by fixing a menu structure that grew badly, and only one is genuinely a product limitation. That changes the size of the build considerably, and a smaller build is a build that ships.

The signals that hold up are specific. Per terminal pricing scaling with your worst case shifts rather than your revenue. Delivery data you cannot reconcile to item level margin. Menu changes that require a support ticket rather than a control panel. A payment processor relationship you cannot renegotiate. If none of those are true, the honest answer is that packaged is still the right tool and a build would be a costly way to obtain the same capability with your name on the uptime.

How do hidden costs get into the quote?

In our delivery experience a working release across ten locations covering the order engine, payments, kitchen display, one delivery marketplace and accounting sync runs $120,000 to $180,000 in 3 to 4 months. A full chain platform adding a second marketplace, loyalty, franchise governance, regional reporting and inventory hooks runs $180,000 to $300,000 over 5 to 7 months. Network scale franchise capability with franchisee onboarding, tiered permissions and hardened offline behaviour runs $300,000 to $400,000 and beyond over 7 to 10 months.

Marketplace partner review is the classic omission, and it is calendar rather than cost. Each marketplace runs its own onboarding and review cycle, none of which respond to your launch date, so a project that starts that process in month three has already lost the time. Begin it in week one alongside processor onboarding.

Payment processing is the second, because proper scope handling and offline capture add real engineering weight that is easy to leave out of an optimistic quote. Rollout and training is the third and it is routinely absorbed into development, which means it gets cut when development runs late. Ask for pilot, rollout waves and store training as their own line items with their own dates, and ask what the support path looks like for a manager at half past nine on a Saturday.

What separates a build that works from one that fails here?

Ask to see a live deployment handling real payments during a real service, not a demonstration. Restaurant point of sale is unforgiving in a way that most business software is not, and kitchen display routing and offline capture are specialist work that looks trivial until you watch a real kitchen at capacity.

Ask whether they have passed a delivery marketplace partner review before, and how long it took. A firm that has done it will give you a number and a list of what the reviewers asked for. A firm that has not will describe the interface, which is the easy half.

Ask them to talk about scope reduction, tokenisation and offline capture without prompting. If the payments conversation has to be started by you, they have not shipped payments. Then ask what happens when the internet drops mid ticket, and listen for whether the answer includes limits and a visible mode indicator rather than a claim that it just works.

Insist on a pilot first plan. Any vendor proposing a ten location launch on one day does not understand restaurant operations and should be disqualified on that answer alone. Finally, settle ownership of the source, the data and the hosting before contracting. At Digital Heroes the client owns the code from the first commit. You are leaving a packaged platform to escape lock in, so read the contract carefully enough not to sign into a new one on the way out.