Ghost Kitchen Multi-Brand Delivery Dashboard with Menu Optimizer

Problem and target customer

Why this exists

Customer problem

Ghost-kitchen operators run several storefront brands from one production line, but delivery exports use different item names and status formats. They cannot compare item margin, prep burden, cancellations, and availability without manual spreadsheet cleanup.

Who pays

Independent cloud-kitchen operators managing multiple virtual brands and receiving orders through more than one delivery channel.

Business model

Monthly subscription tiered by kitchen location, brand count, and imported orders.

Editorial note

A menu optimizer is only as credible as its product mapping and cost assumptions. The first release should spend more design effort on unmatched items, fee allocation, and low-sample warnings than on producing confident recommendations.

CSV is a deliberate starting boundary. It proves that normalized cross-brand evidence changes decisions before the product depends on delivery APIs whose access, fields, and update permissions vary by market.

Choose your next step

What do you need next?

Evaluate the operating tradeoffs quickly, or inspect how to build the MVP.

Evaluate this ideaSee the cost and deployment preview

Compare the three operating paths at the default workload before opening the full calculator.

See cost preview Build this ideaInspect the build blueprint

Review MVP scope, workflow, states, data rules, architecture, and acceptance criteria.

Open blueprint

Evaluation preview

What would it take to run?

Directional infrastructure estimates for the current 10,000 orders imported assumption. Open the full calculator when you are ready to change it.

Open full cost and deployment

ManagedSelected

$5-$40/ month

Railway hosts the app, database, and import worker.

Lowest operating effort

Lean self-hosted

$7-$25/ month

A Hetzner cloud server processes pilot exports.

Lowest baseline cost

More control

$25-$100/ month

Dedicated or larger instances isolate batch work from dashboard traffic.

Most separation and control

Build blueprint

Build the first paid use case

Product goal

Who it serves and what it must change

Target user: A ghost-kitchen operator deciding which menu items to keep, pause, reprice, or investigate across virtual brands.
Problem: Channel-specific order data cannot be compared until brands, products, modifiers, statuses, and fees are normalized.
Measurable outcome: After importing one week of exports, the operator can reconcile unmatched items and rank each canonical menu item by orders, contribution estimate, cancellation rate, and median preparation time.

MVP scope

What ships now and what waits

Included

Import delivery order CSVs and map external brands and items to canonical records.
Capture recipe cost and compute per-item contribution, cancellation, and preparation metrics.
Create a review queue for pause, reprice, rename, or investigate recommendations.

Excluded

Directly changing third-party menus.
Inventory purchasing, kitchen display, and courier dispatch.
AI demand forecasting or automatic pricing.

UX and user flow

Screens, actions, and states

Import Review

Validate a file, resolve duplicate orders, and map unknown brands or items.

Upload exportMap itemCommit valid rows

Brand Overview

Compare order volume, net sales, cancellations, and prep time by brand and channel.

Change date rangeFilter channelOpen item detail

Menu Decisions

Rank item signals and record an operator's action with evidence.

Review recommendationApprove actionDismiss with note

Primary flow

The operator uploads a channel export and reviews detected columns.
Known orders and items normalize automatically; unknown rows wait for mapping.
Committed rows update brand and item metrics for the selected period.
The operator records a menu decision and later marks the external change complete.

Loading, empty, and error states

Import: uploaded, needs_mapping, ready, committed, rejected
Menu item: active, paused, retired
Decision: proposed, approved, dismissed, applied

Core entity outline

Entities and business rules

CanonicalMenuItem

Represents one kitchen item across brand and channel listings.

Fields: name, brand_id, recipe_cost, active
Relations: Has external item mappings, Has order lines

ExternalItemMapping

Maps one channel item identifier to a canonical menu item with effective dates.

Fields: channel, external_item_id, canonical_item_id, effective_from, effective_to
Relations: Belongs to one canonical item

Order

Stores normalized timestamps, brand, channel, totals, fees, status, and preparation duration.

Fields: channel, external_order_id, brand_id, placed_at, net_sales, status, prep_minutes
Relations: Has order lines

MenuDecision

Records the metric window, proposed action, rationale, and operator decision.

Fields: menu_item_id, period_start, period_end, action, evidence_json, status
Relations: Belongs to one menu item

Business rules

A channel order ID is unique within its channel and repeated imports update rather than duplicate it.
Contribution estimate equals item net sales minus configured recipe cost and channel fee allocation; assumptions remain visible.
No recommendation changes a delivery-platform menu automatically in the MVP.

Architecture and data flow

Components, integrations, and controls

Operations console

Serve imports, mappings, brand comparison, and menu-decision views.

Import worker

Parse files, validate rows, detect duplicates, and stage mappings.

Metrics service

Aggregate order, margin, cancellation, and preparation signals by item and brand.

Relational database

Persist canonical catalog, mappings, orders, costs, and decisions.

Integrations

CSV exports from delivery platforms for the MVP
Optional Make transfer into a signed import endpoint

Data flow

The upload creates a staged batch and column profile before any production metric changes.
Mapping approval normalizes valid rows and commits each external order idempotently.
Scheduled aggregates calculate transparent signals and snapshot evidence for each proposed decision.

Failure handling

Reject invalid rows with line-level errors while preserving the staged file
Roll back a batch if commit constraints fail
Keep the previous metrics snapshot visible with a stale label when aggregation fails

Security

Use signed, expiring import URLs
Remove customer names and addresses during normalization
Restrict cost and fee data to operators
Log mapping and decision changes

Rate limits

Limit import file size and frequency
Serialize commits per channel and kitchen
Throttle expensive date-range queries

Deliverables and acceptance

Definition of done for the MVP

Deliverables

CSV import and mapping flow
Canonical catalog
Brand and item metrics
Menu decision queue
Idempotency and metric tests

Acceptance criteria

Importing the same channel file twice does not double order or sales totals.
An unknown item is excluded from item metrics until the operator maps it.
The contribution calculation displays its recipe-cost and fee assumptions.
If a batch commit fails, no partial orders enter reporting and the operator can fix and retry the staged batch.

Recommended stack

Enough technology for the first version

Application

Next.js and TypeScript

Supports data-heavy operator views and upload workflows.

Database

PostgreSQL

Canonical mappings, idempotency, and metric periods require relational constraints.

Imports

Node.js worker with a PostgreSQL queue

Large files need durable staged processing and retries.

Charts

ECharts

Dense brand and item comparisons benefit from interactive operational charts.

Why this is sufficient

The hard problem is trustworthy normalization, not AI. Stage every import, make mappings explicit, and show assumptions behind each recommendation before adding direct channel APIs.

Not required for the MVP

LLM APIReal-time streamingDelivery dispatchWarehouse system

Next stepTurn the blueprint into an execution plan

Copy the build prompt, model the operating cost, and choose where to deploy.

Build and ship

Execution

Build, price, and deploy the MVP

Once the blueprint is clear, use the prompt, cost model, and deployment options to start building.

Build prompt

Copy this into a builder

Build a TypeScript operations app with PostgreSQL and a durable import worker; start with CSV exports because delivery-platform API access varies by operator and market.

Build prompt

Your build prompt is ready

Open the prompt pack whenever you are ready to take this blueprint into your builder.

Based on the blueprintReady for your builderFollow-up steps included

Cost calculator

Model the MVP operating cost

A technical run-cost estimate for the first production version. Team, acquisition, payment fees, and business COGS are excluded.

Estimated monthly total$5-$40

$5-$40 per 10,000 orders imported

Orders imported / month10,000 orders imported

Selected pathEasiest

Pricing checkedAug 2, 2026

Cost breakdown

$5-$40 per month

Low and high values allow for usage variance and plan headroom.

Managed analytics stack

Railway hosts the app, database, and import worker.

20K orders imported included, then $3-$10 per 20K orders imported

$5-$40

Included

Application, database, and import-worker compute
Order aggregation and dashboard queries

Not included

Delivery-platform fees
Kitchen hardware
Menu photography
Operator labor
Paid API access

Pricing basis

The estimate combines the selected infrastructure path, required operating modules, selected optional modules, and usage above included monthly allowances. Taxes and regional uplifts are excluded.

Railway pricing

Deployment options

Pick the operational tradeoff

Choose based on operating preference, not only the headline price.

EasiestRecommended

Railway

Deploy the console, database, and import worker quickly.

$5-40/month

Good fit

Managed runtime
Worker support
Fast previews

Limitation

Large imports and retained data can raise usage costs.

Open Railway

Cheapest

Vultr

Run the app, worker, and database on one small Vultr VPS with Docker Compose and explicit backups.

$7-25/month

Good fit

Low baseline
Docker portability
Predictable

Limitation

You own backups, worker monitoring, and disk planning.

Deploy on Vultr View the lean VPS guide

More control

DigitalOcean

Separate application, worker, data, storage, and backup responsibilities as the workload grows.

$25-100/month

Good fit

Isolation
Private network
Custom retention

Limitation

Higher operations burden.

Explore DigitalOcean View the separated cloud guide

Start building

Prototype, automate, then deploy

Recommended route

01Vibe-coding builderPrototype the kitchen exception view

Use Lovable to test brand filters, unmatched-item review, menu performance cards, and change approval with kitchen operators.

Open Lovable 02AutomationAutomate scheduled export intake

Use Make only to move supported delivery exports into the import endpoint; normalization and menu decisions stay inside the dashboard.

Open Make 03DeployDeploy order normalization and analytics

Run the console, database, import worker, and scheduled metric jobs together on Railway.

Open Railway

Ghost Kitchen Multi-Brand Delivery Dashboard with Menu Optimizer

Is this worth validating?

Build this if

Avoid this if

Validate first

Why this exists

Customer problem

Who pays

Business model

What do you need next?

What would it take to run?

Build the first paid use case

Who it serves and what it must change

What ships now and what waits

Included

Excluded

Screens, actions, and states

Primary flow

Loading, empty, and error states

Entities and business rules

Business rules

Components, integrations, and controls

Integrations

Data flow

Failure handling

Security

Rate limits

Definition of done for the MVP

Deliverables

Acceptance criteria

Enough technology for the first version

Next.js and TypeScript

PostgreSQL

Node.js worker with a PostgreSQL queue

ECharts

Why this is sufficient

Not required for the MVP

Build, price, and deploy the MVP

Copy this into a builder

Your build prompt is ready

Model the MVP operating cost

Usage assumptions

$5-$40 per month

Included

Not included

Pricing basis

Pick the operational tradeoff

Railway

Good fit

Limitation

Vultr

Good fit

Limitation

DigitalOcean

Good fit

Limitation

Prototype, automate, then deploy

Related ideas

Department Budget vs. Actuals Tracker with Variance Alerts

Kanban Sprint Board for Remote Dev Teams

VendorVault: Supplier Contract & Renewal Operations Hub

Network Monitoring & Latency Console

MissionBoard: Campaign Operations Hub

GymPulse: Boutique Gym Member Retention & Analytics Hub