For Hotel & Resort Groups

Corporate oversight.
Outlet isolation.

Recipe management and food costing structured exactly like your estate: one corporate layer, every resort beneath it, every outlet isolated from the others. Built for hotel groups, resort groups, and multi-outlet clusters.

See pricing
EU hosted (Helsinki)
GDPR compliant
Corporate read only, by design
Data Isolation

Corporate can see everything. Corporate can change nothing.

Every resort and every outlet is its own organization: a hard tenant boundary for every recipe, ingredient, menu, and cost. Read access flows downward only, one layer at a time, nobody reads sideways and nobody reads upward.

Corporate reads every resort and outlet
A resort reads its own outlets
An outlet reads only itself

Whether you call a property a resort, a cluster, or a central production unit (a CPU cooking for several outlets at once), the model is the same three layers: just another organization in the pyramid, with the same boundary around it.

Who can read, who can write
Access by layer of the pyramid, enforced server side on every request, not just hidden in the interface.
WhoScopeCan readCan writeNote
Corporate (group admin or owner)Every resort and outlet in the groupEvery non read method is refused before handler logic runs, not filtered in the UI
Resort team (owner, manager, chef, viewer)Its own outlets, one level down onlyNever sideways to another resort, never upward to corporate
Outlet's own teamIts own outletFull access, exactly as it worked before any group existed
Category scoped member (for example a pastry chef)Only the recipe categories assigned to that personA recipe outside their categories answers not found, the same response a stranger gets

The gate is the method, not the screen

Every write from a corporate or resort reader, create, edit, delete, is refused before a single line of handler logic runs. That holds for every write endpoint that exists today and every one added later, without per-route work.

One narrow, audited exception

Corporate can manage who works at an outlet: invite, promote, remove. It still cannot touch a single recipe, ingredient, menu, or setting there, and every such act is written to that outlet's own audit trail.

Scoped access, down to the station

An outlet can scope one of its own team members to named recipe categories. A recipe outside that scope answers not found, the same response a stranger gets, never a permission error that confirms it exists.

Resort Layer

A resort holds no recipes of its own

A resort organization reads as a rollup of its outlets: it has no recipes, ingredients, or menus that belong to it directly. The main dining room, the beach bar, and the banquet kitchen each keep their own costs; the resort above them only ever reads.

The resort layer holds no recipes, ingredients, or menus: only its outlets do
Nesting outlets under a resort, with its own read-only rollup, is available on an enterprise contract
Properties evaluating this typically compare Cucinovo against Meez and other enterprise hospitality suites, not single-kitchen recipe tools
Corporate Rollup

One dashboard for every resort and outlet

A group login rolls up food cost percentage, active menu counts, and the worst performing item across every resort and outlet in the estate, nested the way the estate is actually shaped: resorts, each with its own outlets underneath. The same numbers a resort's own overview panel shows, so the two layers of the pyramid never disagree about one property's food cost.

Per resort and per outlet food cost percentage (GP% read the other way round), active menus, recipes, and ingredients
Outlets nested under their own resort, not a flat list to re-sort by hand
Built from persisted cost snapshots, so viewing the rollup never runs a cost calculation across a property whose recipes you cannot see in full
Group Dashboard
Outlets
9
Avg. food cost
29.4%
Worst item
41.2%
Resorts
Marina Bay Resort3 outlets
27.8%
Palm Coast Resort4 outlets
31.5%
Old Town Hotel2 outlets
28.9%

Illustrative data. Read only: this view has no create, edit, or delete controls for any resort or outlet.

Group Rollup
3 outlets, 3 functional currencies
Marina Bay Resort (outlet 1)EUR
Palm Coast Resort (outlet 2)USD
Old Town Hotel (outlet 1)GBP
Rolled up without an exchange rate
Food cost %, recipe count, menu count

Illustrative data, the same three outlets shown above.

Multi-Currency

Every outlet, its own currency

Every outlet prices its own ingredients in its own functional currency, across 17 supported currencies. The group rollup deliberately never combines absolute costs across outlets: it aggregates the numbers that do not need converting, food cost percentage, recipe counts, active menu counts, so a resort billed in euros and an outlet paying in dollars are never silently added together at the wrong rate.

Each outlet keeps its own functional currency for its own recipes and costs
A recipe with one ingredient priced in the wrong currency is flagged, never silently converted or summed in
Cost per portion, and cost per cover or cost per guest for a banquet (the guest count and menu a function sheet or BEO already specifies), in the currency the outlet actually pays in
Recipe Migration

Get thousands of recipes out of Word, Excel, or wherever they live now

Migration is supported from any app or file, not a fixed list of formats.

ODT, DOCX, CSV, and Excel import directly today
Dozens of recipe cards in one document, each with a photo and numbered method
That is the shape a real hospitality export actually takes

Bring your own file

Any app, any file. If the importer has not seen your export format before, we run it by hand rather than leaving it as your problem.

Many cards, one document

A single document holding dozens of recipe cards, photos and numbered method included, imports as dozens of separate recipes, not one.

Pre-opening is the easy case

A pre-opening property has no legacy file to fight at all, standards go straight in as they are written, with nothing to migrate.

Hands-on support, if you need it

If your export does not match a format the importer already handles, we will help migrate your recipes rather than leave it as your problem.

Dietary & Cultural Flags

Alcohol and pork flags that travel through every sub-recipe

Ingredients can carry flags: contains alcohol, contains pork, contains gelatine, contains non halal meat, contains meat, contains animal products. A dish built from sub-recipes inherits every flag any component carries, so a sauce with wine in it flags the dessert that uses it too. Particularly relevant for Gulf and Indian Ocean hotel groups running halal kitchens alongside international dining outlets under the same estate.

Flags are set at the ingredient level and roll up automatically through composed dishes
Every flag reads as contains X, a positive fact, never a certification
An unflagged ingredient means nobody has recorded a flag yet, not that the ingredient is clear
Recipe: Braised Lamb Tagine
Lamb shoulder
Preserved lemon
Red wine jus (sub-recipe)
Contains alcohol
Rolled up to the finished dish
Contains alcohol

Illustrative example. The flag came from one sub-recipe and travelled up automatically.

Approvals & Audit

Brand standards enforced by the system, not just the handbook

An outlet can require that recipe edits go through a second person before they go live, so one chef cannot quietly rewrite a corporate standard mid-shift.

A change becomes a pending revision, held until an approver accepts or rejects it
Every change to a recipe, ingredient, or team membership is logged: who acted, what changed, and when
Written to that outlet's own audit trail, readable by the outlet itself on its own settings

Recipe approvals

Turn on a require sign off setting per outlet, and an edit waits as a pending revision until someone holding approval rights accepts or rejects it. Nothing goes live unreviewed.

Audit trail per outlet

Every change is logged against the outlet it happened in, including anything corporate did there, who acted, in which corporate role, and exactly what changed. The outlet reads its own history.

Data Residency

Where your data actually lives

Production infrastructure runs on a Hetzner server in Helsinki, Finland, with the production database on MongoDB Atlas in an EU region. We lead with exactly where the data lives and who can reach it, rather than a compliance badge.

Named data centre

Hetzner, Helsinki, plus an EU region on MongoDB Atlas. Not a region dropdown, the actual place your data sits.

Published DPA and sub-processors

Read the Data Processing Agreement and the sub-processor list before you ask for them.

GDPR rights, built in

Full data export and right to deletion for every account, no third party data sharing.

Send this to your IT team before the meeting

Isolation, currency, GDPR, and migration, answered in writing. Bring us your own recipe file and we will show you it working live.

Start a free trial

No credit card required for the trial • Enterprise quoted within one business day

Free plan for home cooks
No credit card required
14-day trial for restaurants
GDPR compliant