Skip to content
Restaurant Forecasting is live with file-based onboarding.Request access
OpenfluidOpenfluid
About Openfluid

Forecasting built around the decision that follows.

Openfluid is building operational forecasting software for teams that still translate reports into preparation, purchasing and inventory decisions by hand. Restaurant Forecasting is the first live product. Retail Forecasting is the next domain under design.

Restaurant Forecasting liveRetail Forecasting coming soonEvidence over inflated claims
Openfluid principle

The forecast should show its work.

Data cutoff, scope, assumptions, operating rules and human changes should remain visible from prediction to outcome.

The operating gap

Why the product exists.

Restaurants already have sales reports, POS dashboards and inventory records. The difficult work begins after visibility: deciding tomorrow’s expected demand, how much to prepare, which ingredients to buy and where a likely excess deserves intervention. Those decisions often live in spreadsheets, chat messages and manager judgement. Openfluid is designed to connect them without pretending that one model can replace operating context.

What we are building

A forward-looking decision layer

Forecasts, transparent rules, exception review, operator overrides and outcome measurement across connected restaurant data.

What we are not claiming

A fully autonomous restaurant operator

The current product does not eliminate data work, guarantee savings or automatically understand waste that was never recorded.

How we work

Principles shaping the product.

01

Begin with a named decision

The user, deadline, horizon and action are defined before model selection.

02

Prefer a visible baseline

A complex method should outperform a simple seasonal forecast on the target series and period.

03

Keep rules outside the model

Buffers, lead times and batch sizes remain explicit and changeable without retraining demand.

04

Record human judgement

Overrides are preserved with reasons so local knowledge becomes evidence rather than hidden correction.

05

State data boundaries

Sales are not preparation; potential excess is not actual waste; a prototype is not a customer result.

06

Expand by proven workflow

Restaurant Forecasting comes first. Retail is a distinct product problem, not a relabelled page.

Product status

Where Openfluid stands today.

Live

Restaurant Forecasting

Revenue, order, menu-demand, preparation, ingredient, waste-risk and Forecast Chat workflows are represented using a synthetic three-outlet dataset.

See product →
Coming soon

Retail Forecasting

Store-SKU demand, replenishment and transfer planning are being scoped with potential design partners.

See product direction →
In development

Production foundations

Connector scope, security controls, model evaluation and deployment architecture will be established through pilot requirements.

Review platform approach →
Open questions

Questions we are still testing.

Daily adoption

Which recommendation format earns trust in a kitchen or purchasing review without adding another dashboard ritual?

Minimum data

How far can useful preparation and inventory planning go before actual prep, stockout and waste capture become mandatory?

Economic value

Which outcomes can be measured credibly during a pilot without overstating causality?

Horizontal platform

Which forecasting capabilities can be reused across industries and which operating models must remain domain-specific?

Build the evidence with us.

Restaurant operators can bring one recurring planning problem and a sample export. Retail teams can apply for the design-partner programme.

Start a conversation →