You Ran GloriaFood for Clients. Where Does the Book Go?
What an agency, POS dealer or web shop has to solve that a single restaurant does not — and what to check in a white-label program before you move a client book onto it.
GloriaFood's partner arrangement gave agencies something unusual: a product that cost the restaurant nothing, so the conversation was never about price. That is the part with no replacement, and it is worth saying plainly before anything else on this page.
What comes next for that book is a different business rather than the same one with a new logo: selling software under your own brand, at your own price, with your own invoice. Some agencies will find that a better business than the one they had. Others will decide it is not the business they want to be in, and would rather hand their clients a recommendation than a contract. Both are reasonable, and you should work out which one you are before you shortlist anything.
If you are a single restaurant rather than an agency, the page you want is the migration path, and the first thing to do is get your data out .
Four things a book has that a restaurant does not
Every migration checklist on the internet is written for one restaurant. These are the parts that only bite when there are twenty.
You have to move a book, not a site
A restaurant migrates once. You migrate every client, each with their own menu, their own delivery zones and their own opinion about when is convenient. The thing that decides how painful that is turns out not to be the platform — it is whether all of them land on ONE platform with one login, one support path and one invoice, or on whichever product each client picked in a panic.
Your billing relationship is the asset
If your clients end up buying directly from a vendor, you have converted a recurring line of your own business into an introduction you were not paid for. The whole point of a white-label arrangement is that the invoice stays yours: you set the price, you bill, and the platform vendor is not a name your client has heard.
The app-store accounts decide who owns the client
This is the question to ask any platform you are shortlisting, and it is the one most of them answer badly. If the client's app lives in the vendor's developer account, the vendor can take the relationship whenever it suits them. Under this program the apps are published under YOUR developer accounts, which is what makes the client yours rather than borrowed.
Support has to have a shape before day one
Twenty restaurants calling one person on a Friday night is not a support model. The split here is written down rather than improvised: you run first and second line — how-to, configuration, menus, and triage on reproducible bugs — and anything that reaches the platform or the code comes to us.
The split, written down
Read this before the commercial conversation rather than after it. A program that will not put this in writing is telling you something.
You own
- The brand the restaurant sees, on iOS, Android and web
- The price — set for their market, agreed with us in conversation
- The customer relationship, the invoice and the payment rails
- First- and second-line support, onboarding and training
- Their app-store accounts and developer identities
We own
- The platform, its roadmap and its uptime
- Third-line support and anything that reaches the code
- Per-tenant isolation, security and the payment integrations
- Release engineering and the app build pipeline the partner can call on
Support, by line
- First line
- how-to, config, menu — Partner
- Second line
- reproducible bugs, integrations — Partner triage → Devkart
- Third line
- platform, outages, security — Devkart
business-hours TARGETS, not SLAs, unless contracted.
When this is not for you
If you have two or three clients, the certification, the demo estate and the support desk are more structure than the revenue justifies. Point them at a platform directly and keep the website work. That is a smaller business than a partnership and it is a real one.
If you want a referral fee rather than a business, this is not the shape of program that exists here. There is one program and it is white-label — you carry the brand, the price, the invoice and the first two lines of support.
And if you are hoping to replace a free product with a free product, we do not have one. The restaurants pay a flat monthly fee at whatever price you set. Some of your clients will move to a marketplace instead, and for the ones doing four online orders a week that may genuinely be the right answer.
Moving a client book, answered
GloriaFood had a partner program. What replaces it?
There is no like-for-like replacement, and any page that tells you otherwise is selling you something. GloriaFood's arrangement gave agencies a free product to install and a print-and-flyer business around it; that model went away with the product. What exists here is a white-label program: own brand, own apps under their own developer accounts, own pricing, own billing, own customer relationships, own sub-resellers. Devkart is invisible to the end restaurant. The trade is different — you are selling software under your own brand rather than installing someone's free tool — and it is worth being clear about that before you plan around it.
When does my client book actually have to move?
Oracle's own statement puts full end of service at 31 March 2027, checked 3 September 2026. Most third-party pages say 30 April; that comes from an earlier in-product notice. Plan against the earlier date. Working backwards from it, a book of any size wants to start in the first half of 2026 rather than the second — not because the migrations are slow, but because your clients each need weeks to get their own customers onto something new.
Whose brand do my clients see?
Yours, everywhere. Fully partner-branded; no Devkart marks anywhere in the product or on the paper. Your clients deal with your brand on iOS, Android and web, and the platform underneath is not a name that appears in the product or on the paperwork.
Who sets the price?
You do. The partner proposes a retail price for their market. We discuss it against what that market's category leader charges — we bring the per-band evidence to the call. Once the retail price is agreed, our share of it is negotiated — as a percentage of that agreed price, so it moves with the market rather than against a USD list the partner never charges. Commercial terms are agreed per partner and set out in your partner agreement.
What stops another partner selling to a client I am working on?
Deal registration. Register a prospect before you sell and it is protected for 90 days, extendable once by 30; approval comes back within 2 business days. Where two registrations conflict, earliest valid registration wins; ties → the account's stated preference.
What do I have to have in place before you will sign me?
Certification — 1 Sales + 1 Ops/Onboarding certified; Demo estate — own demo brand + apps; Support desk — documented L1/L2, escalation contact, status comms; Paperwork — WL agreement + DPA (processor chain) + app-store ownership + sub-reseller flow-down; Reporting — monthly live-location count (automated). The bar exists because a partner without a support desk becomes our support desk, and that is a worse outcome for the restaurants than not signing.
Can I move clients one at a time?
Yes, and that is the sane way to do it. Take the client whose setup you know best, move them end to end, and let that migration teach you the running order. The second one takes a fraction of the time, because every decision you were making up as you went along is a decision you have already made.
Ready to Keep 100% of Your Revenue?
Get your own branded ordering platform. Live in as little as 48 hours — zero commission, no contracts.
Book a live demo on a real store · Free setup for early customers