What the All-in-One Ordering Platforms Don't Tell Independent Restaurants

There's a pitch every independent restaurant hears: one platform for your point of sale, your online ordering, your loyalty, your marketing — one login, everything talking to everything. It sounds like relief. Running a kitchen is hard enough; let one company carry the software.

The tools are real and they work. What nobody walks you through is the shape of the deal — and the shape, not the monthly fee, is what quietly decides how much of your own success you get to keep. It costs you in three places, and none of them prints on a statement.

The fee isn't the price

Every owner can quote the numbers: the per-order percentage, the software charge, the hardware lease. Those are the costs the platform puts on the invoice, so those are the costs you negotiate.

They're the smallest part. The real price is structural — it's how the arrangement is built, and it shows up as three things you don't get to argue about: a cost that grows with you, a customer base you don't hold, and a storefront you can't rank.

One: the commission ratchet

When your ordering runs on a platform that takes a cut of every order, its income is tied to your growth while its work is not. The night you double your volume, it does nothing new and earns twice as much. Every promotion you fund, every regular you win, every busy Friday you earn — it rides along on a percentage.

That's a partner taking a share without carrying any risk, and it tightens exactly when you're winning. A cost that scales with your revenue instead of with the service delivered isn't a fee. It's rent on your own growth.

Two: whose customer is it, really?

When people order through the platform's app, join the platform's loyalty program, and get the platform's email, the relationship belongs to the platform. You're renting access to your own regulars. The order history — who buys what, on which nights, how often — is the data that should sharpen your next decision, and it lives in someone else's system, shaped to serve their business instead of yours.

And it doesn't come with you. The day you decide to leave, you learn the loyalty list and the customer emails were never yours to take. You built the traffic; they kept the audience. A restaurant that can't reach its own regulars without paying a middleman doesn't own its customer base — it leases it.

Three: the storefront you can't rank

This is the cost that gets noticed least, and it compounds the other two.

Your ordering page is the single most valuable page you own — it's where a hungry search turns into money. On a bundled platform, that page usually isn't yours. It's a templated flow on the platform's infrastructure, often at a URL you don't control. So whatever ranking it earns in Google accrues to the platform, not to you. Search for your own food and you find the marketplace sitting in the spot that should be yours.

You can't fix it from inside the platform, either — you can't add a crawlable page per dish, or the local schema that wins the map pack, because you don't own the site, you rent a slot in theirs. It's the same trap we wrote about for drag-and-drop websites: a storefront you can't restructure is a storefront that can't rank. A bundled ordering platform imposes that ceiling on the highest-intent page you have.

What we build instead

The fix isn't "go without software." It's to stop bundling the parts that were never meant to be one thing.

Underneath, a commodity point of sale does the register job well — payments, cash, your catalog — and exposes clean APIs so everything above it can be built the way you need. We run our restaurant work on Square for exactly that reason: it handles the counter and gets out of the way. On top sits a first-party ordering site that is genuinely yours, and "yours" means three things at once — the customer relationship and data live in your system; the loyalty program is one you own, not a slot in someone's app; and the site is a real, indexable website, with its own pages and schema, so the search ranking you earn is yours to keep. A decoupled front end, independent loyalty, a commodity payments backend. (Owners often ask how this compares to keeping everything inside a platform like Toast — the honest answer is that the bundle is convenient right up until the day you want your customers, your data, or your rankings back.)

Marketplaces still earn their place in this — as a channel to get discovered, not the landlord you pay forever for introductions to people who were already yours.

We don't just recommend this — we run it

It's easy to write this down. It's harder to have lived it on a Friday night. The direct-ordering, own-your-loyalty model is the one we built and battle-tested at Karachi Chaat House — a real restaurant, real cash drawers, real peak-hour tickets. We didn't sketch it on a whiteboard and hand it off; we run it daily and fix it when it breaks.

That's the line between a shop that sells you a platform and a team that builds you an asset you own. When the software running your revenue is something we design, run, and stand behind, the ceiling on your ordering channel is your kitchen — not a vendor's contract.

A piece of that build, in the open

Here's a concrete example of what "a site that's genuinely yours" actually buys you — the kind of thing a bundled platform never has to explain, because you can't see inside it. A first-party ordering site has one unglamorous problem the platform hides: the price on the page has to match the price at the register, every time. Change a price in the point of sale and a hand-built site will happily keep showing the old one — to customers, and to Google.

The lazy fixes both fail. Re-typing prices into the HTML by hand doesn't survive a busy month. Fetching them live from an API every time the page loads makes your menu depend on the register system being reachable, and hides the price from the search crawler that never runs your scripts.

So we bake. Once, at build time — not at deploy, not at page load — we read the catalog from the point of sale and write the correct price straight into the committed HTML. What ships is a plain static page: the number is already right when a crawler reads it, and nothing is fetched when a customer opens it.

The trap that catches almost everyone who builds this is keying prices by the item's name. Two items can share a name and cost different amounts — a dish that's $12 at lunch and $16 at dinner is two different objects in the catalog, not one. Key by name and the second silently overwrites the first; half the menu goes wrong and nothing throws an error. Key by the catalog's own item ID and both stay correct. It's a one-line decision that quietly decides whether your prices are right.

And because the baked prices are committed, we can prove them. Every price ships next to a snapshot, and a check confirms — offline, with no network — that the visible price, the structured-data price, and the snapshot all agree. Edit one without resealing and the build fails. The prices aren't just correct; they're tamper-evident.

We pulled that price-baker out of the Karachi Chaat House build, stripped it down to neutral demo data, and published it as a reference you can read end to end: pricelock on GitHub. It's the receipt for the paragraph above — the difference between a shop that tells you it owns its stack and a team that shows you the code.