← MenuCrafters

Restaurant Operations · Updated 2026-09-21 · 7 min

Ghost Kitchen Menu Strategy: Building a Delivery-Only Menu That Works

A ghost kitchen menu strategy starts from a simple fact: the guest never sees your room, your plating or your staff. They see a list, a photo and a delivery estimate, and then they see a sealed bag. Every menu decision has to work inside those constraints — dishes that survive the trip, names that read clearly in a list, prices built from known costs including packaging and commission, and a station layout that can hit the promised times. The menu is also your cheapest experiment: you can test demand with a short list before you commit to equipment, staff or a second brand.

Delivery-only kitchen station at night with sealed takeout bags, lidded containers and a blurred order list on a phone.
A delivery-only menu is engineered for travel, packaging and a list view rather than for a dining room.

Try the menu description generator

What is different about delivery-only

Four differences change almost every decision.

The guest cannot ask a question, so the item description has to carry what a server would normally explain. The food spends time in a bag, so texture and temperature matter more than presentation. The order arrives through a platform that takes a commission and controls part of the listing. And the kitchen is optimised for throughput, not for the rhythm of a dining room.

The menu that results is usually shorter than a dine-in menu, with fewer components per dish and fewer modifiers. That is not a compromise; it is the point.

Build a menu that travels

Choose dishes with three properties, then write the packaging note while you design the dish rather than after the first complaint.

  • **They hold heat.** Braises, curries, rice and grain bowls with sauces packed separately, and baked items that reheat well.
  • **They hold texture.** Weak candidates are anything fried and served crisp, delicate garnishes, and dishes that depend on a specific plate.
  • **They pack in a way that keeps components separate until the guest opens the bag.** A dish that needs three containers and a separate sauce pot is a different operational cost from one that goes into a single box, and the menu should reflect that.

Names and descriptions that survive a list view

In a list view, the guest sees a name, a price and a short description. That is the whole pitch.

Name the dish so the main ingredient and the format are obvious. A guest scrolling quickly should not have to guess whether "House Bowl" is a salad, a rice dish or a soup. If the dish has a story, keep it to the description, not the name.

Descriptions should do four jobs in two sentences: say what the dish is, name the components that matter, indicate spice or richness, and state anything that arrives separately. Do not spend the space on adjectives that do not help the guest decide. And keep the same description in every channel you control, so the guest who compares your hosted menu with the platform listing sees the same dish.

Price with known costs only

Delivery pricing needs one more line than dine-in pricing: packaging, and on most platforms, a commission. Build the price from what you know.

Start with the food cost of the dish as served, including the packaging that leaves the kitchen with it. Add the labour you can attribute to assembling and handing off the order. Then apply the commission your platform charges — and if the platform's commission is a percentage, apply it to the total the guest pays, not to the food cost alone.

If the arithmetic does not leave a contribution you are willing to accept, you have three honest options: simplify the dish, raise the price for that channel, or take it off the delivery menu. What you should not do is price from a dine-in menu and hope the commission works out. Many delivery-only menus carry a slightly higher price than the dine-in version for exactly this reason; the important thing is that the guest can see what they are paying for and that the arithmetic is real.

Station layout, prep time and handoff

The menu decides the station. If three of your top five dishes need the same fryer basket at the same moment, the menu will fail at peak even if every dish is good.

Sketch the flow: where the order prints, who assembles, where the bags are sealed and where they wait for pickup. Keep the bagging station away from the cooking line so a rider waiting for an order is not standing in the middle of service. Label every bag so the right order leaves with the right rider.

Then test the promised times against the menu you designed, not against your best-ever service. A menu that only hits its estimate on a quiet Tuesday will damage the listing's rating on a Friday.

Testing demand before you scale

The advantage of a delivery-only concept is that you can test the menu before you invest in it. Start with a short list — enough to cover the main eating occasions, small enough to execute well — run it for a defined period, and review three things.

Set the review date before you launch. Without a date, a test menu becomes a permanent menu by accident.

  • **Which items sell,** so the list can be shaped around real demand rather than the original idea.
  • **Which items generate complaints or refunds,** because delivery problems show up as refunds faster than they show up as feedback.
  • **Which items slow the line,** since a dish that blocks the pass costs more than a dish that sells poorly.
  • **Then act:** remove the bottom performers, fix the items with operational problems, and only then consider adding a second brand or more equipment.

Worked example: a short delivery list

The numbers below are illustrative.

A kitchen tests a delivery-only rice bowl concept with six items: three bowls, a soup, a side and a drink. Each bowl is designed to pack in one container with the sauce separate. The list is short because the kitchen has one cook and one packer at peak.

After four weeks, two bowls account for most orders, the soup sells poorly and generates the most complaints because it arrives lukewarm, and the side has a healthy attachment rate. The drink is cheap, fast and lifts the average order.

The review removes the soup, adds one variation of the best-selling bowl using the same station, and keeps the side and drink. Nothing is added that requires new equipment, and the next review is set for four weeks later.

Limitations and assumptions

This approach assumes you can measure your own food and packaging costs and that you know your platform's commission structure. It assumes you can control the hosted version of your menu; platform listings may update slowly or may restrict what you can change. It cannot predict demand, platform ranking behaviour or rider availability, and it does not cover licensing, food-safety or insurance requirements for a delivery-only operation, which vary by location and should be checked directly. The testing method needs a review date and honest data; without both, it becomes guesswork with extra steps.

FAQ

How many items should a delivery-only menu have?

Enough to cover the main occasions you want to serve, and no more than the kitchen can execute consistently at peak. Many delivery-only concepts run well with six to twelve items. A short list is easier to photograph, describe, price and improve than a long one.

Should delivery prices be higher than dine-in prices?

Often yes, because packaging and commission are real costs that the dine-in price does not carry. What matters is that the difference is deliberate and that the contribution still works after the platform's cut. Check the arithmetic per item rather than applying a blanket rule.

Can I run a delivery-only brand from an existing restaurant kitchen?

Yes, and it is common, but it competes for the same equipment and staff. The menu should be built so its peak overlaps as little as possible with the dine-in peak, and the station layout has to keep delivery orders from interrupting plated service. Test the timing before you launch a second brand.

Build your menu

Turn the ideas in this guide into a hosted QR and print menu with MenuCrafters.

Help & support