A one-off build pays once and then generates support tickets forever. Here is how to structure ordering work as recurring revenue — what to include, what to meter, and what to refuse.
The default way a studio takes on a restaurant ordering site is the worst way: a fixed-price build, invoiced on delivery, followed by two years of unpaid WhatsApp messages about the opening hours.
The work is genuinely recurring. Menus change weekly, prices change with supplier costs, a delivery zone gets redrawn, a card payment fails, a new location opens. Charging for it once and then absorbing the rest is not generosity — it is a slow way to lose money on a client you cannot afford to fire.
This is about the structure, not the number. What you charge depends on your market and your reputation. What the structure has to do is make the recurring work paid and the cost side predictable.
Most bad proposals collapse three different products into one price.
Setup is finite work: domain, DNS, Stripe connection, menu entry, photography, delivery zones, opening hours, the first round of design decisions. It has a beginning and an end, and it deserves a one-off fee. Charge it. A free setup signals that the ongoing relationship is where you intend to make it back, which is true but reads badly.
The subscription is the part clients undervalue and you should not: hosting, platform cost, certificate renewal, uptime, the fact that orders keep arriving on a Sunday. This is the retainer floor, and it exists whether or not anyone touches the site that month.
Changes are the honest variable. New dishes, seasonal menus, a second location, a campaign landing page. Either include a defined allowance in the retainer — “menu updates within two working days, up to four a month” — or bill them. Do not leave it undefined, because undefined always resolves in the client’s favour and never in a way that gets discussed.
The retainer that works is setup once, then a monthly figure covering the subscription plus a named allowance of changes, with anything beyond that quoted. Boring, legible, and it survives the client’s bookkeeper reading it.
Here is the part you can be precise about, because these are the real platform numbers rather than my guesses about your market.
Pro is $20 a month and covers unlimited restaurants. That is the single most important fact for a studio’s economics: your second, fifth and twentieth client do not each add a base fee. What grows with the portfolio is metered volume — 0.5% on order volume above the included $5,000, $0.75 a month per custom domain from the second onward, $0.20 per GB-month of image storage past the first gigabyte, $3 per 100,000 storefront views past the first 100,000, $1.00 per 1,000 image transformations past the first 3,000.
If you resell under your own name, add the White-Label add-on at $49 a month. It is charged once for the studio, not per client, which matters when you are modelling ten restaurants rather than one.
So your platform bill is a small fixed base, one optional studio-level add-on, and a variable component that only moves when your clients are doing well. Your revenue is roughly linear in client count. That divergence is the entire reason this works as a practice, and it is worth putting in front of whoever signs off on your own business plan.
One practical note: because the included allowances are studio-wide rather than per client, your marginal cost per restaurant falls as you add them until you cross an allowance boundary. Model the portfolio, not the individual client, or you will price your early clients as if they were carrying the whole base fee.
There is a free tier: one restaurant, up to $1,000 a month in orders on it, storefront on a slug.margord.app subdomain, real-time orders and kitchen display, cash only.
That is not a plan to run a business on, and it is not meant to be. It is the best demo you have. Build a prospect’s actual menu on it — their dishes, their prices, their photos — and send them a link. A pilot on their own food beats any slide deck, and the constraints are exactly the ones that make the paid tier obvious: no custom domain, no card payments, and a ceiling they will hit if it works.
Do not run real clients on it indefinitely, though. The cash-only limitation means a restaurant taking orders on Hobby is handling money in a way that will eventually cause a problem, and the subdomain undermines the ownership argument you just spent a meeting making.
Two things are worth turning down explicitly, because both look like revenue and behave like losses.
Clients who need demand, not infrastructure. A restaurant with no signage, no regulars and no local reputation is genuinely dependent on the marketplace’s discovery. Selling it a standalone ordering page sells a cost cut that lands as a revenue cut, and the churn is on you six months later. Say so in the first meeting.
Per-hour retainers for platform work. If your retainer is priced as hours, every efficiency you build reduces your revenue, and every platform improvement you inherit for free becomes something you cannot bill for. Price the outcome — a working ordering channel, maintained — and keep the efficiency gain.
The build is not what costs you. Menu entry is what costs you, and it is almost entirely a data-quality problem you can control by refusing to start until you have what you need.
Ask for the menu as text, not as a photograph of a laminated card. Ask for allergen and additive information up front, because German law requires it and retrofitting it across ninety dishes is miserable. Ask for photographs at whatever resolution the phone produced — the image engine converts to AVIF or WebP and a 2 MB original becomes roughly 30 KB, so there is no reason to ask a client to resize anything, and asking is how you introduce a week of delay.
A client who cannot produce a text menu in a week is telling you something about how the next two years of change requests will go. Price accordingly, or decline.
The reason to structure it this way is that the portfolio becomes the asset.
Ten restaurants on retainer is predictable revenue that does not depend on winning new projects, on one platform you already know, with one billing relationship and one set of conventions. The eleventh takes less work than the third did. Your support load per client falls as you build up answers to the same eight questions. And the studio microsite in the White-Label add-on gives you a page of live clients on your own domain, which is the cheapest sales asset you will ever own — it is a portfolio that updates itself every time you add a restaurant.
None of that happens if each engagement is a fixed-price build. It happens if the recurring work is paid, the cost side is modelled at the portfolio level, and you decline the clients who need a marketing agency instead.
Be among the first studios on Margord. No credit card required.