Swapping the logo is the easy 20%. White-label fails at the seams — the email sender, the receipt footer, the dashboard URL, the favicon. Here is the full list of places a vendor name leaks.
Every platform with an enterprise tier claims white-label support, and for most of them it means one thing: you can upload your logo. That covers the header of the page a diner looks at for ninety seconds, which is roughly 20% of the surface where your vendor’s name can appear.
The other 80% is where it goes wrong, and it goes wrong at a predictable moment — not at launch, but three weeks later, when your client forwards an order confirmation to their accountant and someone notices a name they have never heard of in the footer.
Here is the full inventory, roughly ordered by how quickly it surfaces.
The domain. If the storefront lives at your-vendor.app/some-slug, nothing else matters. It has to be the restaurant’s own hostname, which means a CNAME the restaurant’s DNS provider accepts and a certificate provisioned automatically — no support ticket, no manual cert upload, no expiry to diarise.
The transactional email sender. This is the most common leak and the most damaging, because email is the one artefact that gets forwarded. If confirmations arrive from noreply@vendor.com, the restaurant looks like a reseller of something. And the reply path matters as much as the sender: when a diner hits reply on a confirmation to ask about an allergen, that message needs to reach the restaurant, not disappear into a vendor’s unmonitored mailbox.
The PDF receipt. Receipts get printed, filed, and handed to accountants and tax advisors. A vendor logo in the footer of a document that ends up in a client’s bookkeeping is a conversation you do not want to have. This one is easy to miss because nobody on the build team ever opens the PDF.
The dashboard URL. Your client’s staff log in every single day. If they type a vendor’s domain to do it, the vendor is the platform in their mind and you are the person who set it up. That is precisely the wrong way round if you want to be the one they renew with.
The favicon. Sixteen pixels, and it is in the browser tab all day next to the client’s own logo. It is trivially small and immediately visible, which is a bad combination to get wrong.
The 404 and error pages. Nobody designs these and everybody eventually sees one. A vendor-branded error page is the seam that shows up exactly when someone is already annoyed.
The DNS records. Any competent IT person at your client will read them. We will come back to this one, because it is the honest exception.
Our White-Label add-on is $49 a month on top of Pro, and it exists to close that list rather than to unlock a logo field. Concretely it removes the “Powered by Margord” mark from every storefront, moves the dashboard to your own hostname, switches order confirmations to a branded sender with a custom favicon, and adds a studio microsite — a single-page directory of your restaurants, each with its logo, name and an “Order now” link, on your own domain.
That last one is the piece that changes the sales conversation rather than just the branding. It gives a studio something to point at: a page that looks like a portfolio of live clients, on the studio’s own domain, that updates itself as restaurants get added. Without it you are describing your work; with it you are showing it.
The pricing shape is deliberate too. It sits outside the base plan because plenty of studios genuinely do not need it — if you are launching under your own name and your clients know exactly who built their site, paying to hide us would be pointless. It is $49 rather than an “Enterprise, contact us” conversation because gating basic professionalism behind a sales call is its own kind of insult.
The DNS record is visible. A restaurant’s CNAME points at our infrastructure, and anyone who runs dig on the hostname can see where it resolves. There is no configuration that changes this, and any vendor who tells you otherwise is either confused or lying.
This is worth saying plainly because the instinct is to treat it as a gap in the product. It is not — it is how the internet works, and it is the same for every white-label service on the web. Agencies have resold hosting on this basis for thirty years.
What matters is that the answer is easy when it comes up. “We run the ordering platform on specialist infrastructure” is a completely normal thing for a studio to say, and a client who is technical enough to read a DNS record is technical enough to know that every agency does this. The problem was never that a subcontractor exists. It is being surprised by one — finding out from a receipt footer instead of from you.
So the goal of white-label is not deception. It is that your client’s diners, staff and accountant all see one coherent brand, and that the infrastructure question comes up in a meeting where you have already framed the answer.
Whatever platform you are evaluating, including this one, go through it in this order before you put a client on it:
From and Reply-To headers, not just the body.dig on the storefront hostname so you know the answer before your client asks.Most platforms fail somewhere between three and five. It takes about ten minutes, and it is considerably cheaper than finding out from your client.
Be among the first studios on Margord. No credit card required.