Restaurant menu launch checklist

Complete this review before the first QR code reaches a table. Every item is checked while signed out, on a phone, and in each published language — that is the only state a guest ever sees.

Work through it in order. A failure in an early section usually explains several failures further down.

1. Structure

• [ ] Every menu type the restaurant sells is enabled, and nothing else is.
• [ ] Every enabled menu type has at least one category with published items.
• [ ] No menu type is enabled with an empty menu behind it.
• [ ] Category names are the ones staff and guests actually use.
• [ ] Category nesting stays within one level, and the order matches how the card is read.
• [ ] Uncategorized Items is empty on every menu type.

2. Items

• [ ] Every dish, drink and wine that is being served is published.
• [ ] Nothing that is out of season, discontinued or unfinished is published.
• [ ] Titles are spelled and capitalized as they should appear to guests.
• [ ] Descriptions are consistent in length and tone across the whole menu.
• [ ] The featured star is used sparingly enough to still mean something.
• [ ] Items are in a deliberate order inside each category, and the order was saved.
• [ ] Photos share a consistent style and orientation.
• [ ] No placeholder photo, sample dish or test item survives anywhere.

3. Prices

• [ ] Every published item has at least one price.
• [ ] Serving formats match reality: half portions only where they are served, glass prices only where the wine is poured by the glass.
• [ ] An empty price means "not offered"; a zero price appears only where the item is genuinely free.
• [ ] Prices were compared against the current printed card or POS, line by line.
• [ ] The way prices are written — decimals, currency symbol, spacing — is identical across every menu.

4. Allergen and dietary information

• [ ] Every food item has been reviewed for allergens by someone qualified to do so, not filled in by guesswork.
• [ ] The allergen list matches the information the kitchen actually maintains.
• [ ] Items that cannot be guaranteed are marked according to house policy.
• [ ] If the archive shows an allergen filter, filtering by a common allergen returns a sensible menu.
• [ ] Staff know that the published information must be corrected the same day a recipe changes.

Fenómenus stores and publishes the allergen information you enter. Its accuracy, and compliance with the food-information rules that apply to the business, remain the restaurant's responsibility.

5. The restaurant profile

• [ ] Site title and public business name are correct.
• [ ] The logo renders correctly on light and dark backgrounds and on a phone.
• [ ] Fiscal name, fiscal address, NIF and mercantile register match the registration documents.
• [ ] The business address is the one guests visit.
• [ ] Both email addresses are monitored, and a test message to each one arrived.
• [ ] The legal and privacy pages show real data, not sample text.

6. The public menus

Open each published menu in a private window, on a phone:

• [ ] The chosen layout renders as expected, with no broken section.
• [ ] The category navigation reaches every section.
• [ ] The contact dock shows the intended links and every one of them opens something real.
• [ ] The utility toggles that are enabled — filters, favorites, language — all work.
• [ ] Colors, icons and menu labels are the restaurant's, not the defaults.
• [ ] The front page is edited, with no placeholder copy, sample gallery or sample address left in place.
• [ ] Pages load fast enough to be read while standing at a table.

7. Languages

• [ ] Every language you intend to publish is enabled.
• [ ] Every published item exists in every published language.
• [ ] Category names are translated, not left in the source language.
• [ ] Prices and allergens are identical across languages.
• [ ] The language switcher reaches every language and returns from each one.
• [ ] No half-translated menu is reachable by a guest.

8. QR codes and printed material

• [ ] Each printed destination was opened and verified before its code was generated.
• [ ] Codes were downloaded as SVG for print.
• [ ] A printed proof was scanned at its final size, at table distance, in dining-room lighting.
• [ ] Multilingual codes were checked against their language group.
• [ ] Table codes point at stable destinations, not at seasonal categories.
• [ ] The generated files are stored somewhere the team can find them for a reprint.

9. PDF menus

• [ ] The PDF was generated after the digital menu was finished, so both show the same content.
• [ ] Every language that needs a printed menu has its own PDF.
• [ ] Logo, typography, colors and footer legend are correct.
• [ ] Allergen display matches what the printed card should show.
• [ ] The file was opened and read after downloading, not only previewed.

10. The team

• [ ] The people who maintain the menu have their own accounts.
• [ ] Staff who only edit dishes have the Basic profile enabled.
• [ ] Someone specific owns prices, someone owns allergens, someone owns translations.
• [ ] The team knows that a change is only live once it has been checked while signed out.
• [ ] The team knows how to move an item to Draft the moment a dish runs out.

11. The day-one routine

Agree these before launch, not after the first incident:

• [ ] How a sold-out dish is hidden during service, and by whom.
• [ ] How a price change reaches the digital menu, the PDF and the printed card.
• [ ] Who re-checks the public menu after any bulk edit.
• [ ] Who reprints QR material if a destination ever changes.
• [ ] Where the last verified export or PDF is stored, as a reference point.

The menu is ready when every intended item is visible to guests, nothing unfinished is reachable, prices and allergens are correct in every language, and the person on shift knows how to change all of it safely.

For everything that comes after launch, see Updates, support, and safe maintenance.