A sample model of what an operational hub can do
Scorcher Bay — a working demonstrator built to help a new food entrepreneur face the questions that decide whether the business survives.
Runs in the browser. Demo data only — no real business figures.
A new entrepreneur should leave a screen slightly less confident than they arrived, and know exactly which specialist to ring.
Sec. 01
Context and operating scale
A person launching a packaged food product faces a fragmented journey: product development, raw materials, batch production, shelf life, pricing, labels, food-safety requirements, packaging, orders, markets, and finance and business planning.
The information all exists. It is rarely presented as one pathway, and almost never in an order that matches the sequence in which the decisions actually arrive.
Scorcher Bay was built as a working answer to that — on my own time, outside the scope of any job, as a demonstrator rather than a product for sale.
Sec. 02
The real problem
The failure mode is not usually one bad decision. It is meeting eleven areas one crisis at a time, each with its own vocabulary, its own authority and its own software, and never seeing how they connect.
Costing gets done after the recipe is fixed. Shelf life gets tested after the label is printed. Compliance arrives as a surprise. Each of those is recoverable on its own; together they exhaust people before the product reaches a market.
The harder problem is that a new entrepreneur often does not yet know which questions are the dangerous ones. A tool that only records answers is no help. It has to prompt the question early enough to matter, and make it uncomfortable to skip.
Sec. 03
My role
- Mapped the end-to-end food-business pathway
- Sequenced the questions in the order the decisions actually arrive
- Designed 21 screens across finance, production, operations, resources and knowledge
- Wrote the compliance-oriented reference content
- Built the working demonstrator
- Made the product-boundary decision that separates this from a chef's recipe system
Sec. 04
What I designed
The model runs entirely in the browser, with the business's data held on the device rather than on a server — a deliberate choice for someone who has not yet decided what their business is, let alone whom they trust with it. Twenty-one screens sit in five groups:
- Overview — Roadmap and Finance: the pathway itself, and what the numbers have to look like
- Production — Recipes, COGS, Batches, Shelf Life and Planner: the questions that decide whether a product is viable
- Operations — Inventory, Orders, Markets, Labels and Contacts: the questions that decide whether it reaches anyone
- Resources — Ingredients, Directory, Documents and Kitchen: the things people waste weeks hunting for
- Knowledge — Techniques, Import and a data guide: reference held next to the work rather than in a separate manual
Sec. 05
How it was used
It is a sample model, and the more useful demonstration is how far it bends. The pathway, the fields, the thresholds and the reference content are all specific to one kind of food business; almost none of that is structural.
The same shape holds for a brewery, a bakery, a spice blender or a central production kitchen — the sequence of questions changes, the sequencing itself does not. That adaptability is the point of showing it.
Building it also produced the more valuable result: a boundary. Costing, inventory and commercial-yield complexity should not be deeply embedded in a chef's everyday recipe system. Scorcher Bay and The Spicy Noodle share culinary domain knowledge but serve different people, and keeping them apart protects both.
Sec. 05b
Designed to make you argue with it
The useful part is not the record-keeping. It is that the model asks the uncomfortable question at the point where the answer is still cheap to change.
COGS sits directly beside the recipe, so the cost of a formulation is visible while the formulation is still an opinion. Shelf life is framed around what evidence would actually support a claim, not around a number someone would like to be true. Labels and compliance appear as part of production, not as a final step. The pH, acidity, hot-fill and fermentation references are there so a person can check their own assumptions rather than take the tool's word for it.
A new entrepreneur should leave a screen slightly less confident than they arrived, and know exactly which specialist to ring.
Sec. 06
Inside the model
Six screens from the working demonstrator, captured in a demo workspace. Every figure shown is representative demo data — no real company financial or production results appear, and none should be read as such. Click any screen to see it full size.
Sec. 07
Relevance by outcome
What it demonstrates
- End-to-end workflow and pathway mapping
- Operational product design across 21 connected screens
- Compliance-oriented content structure
- Commercial logic tied to production decisions
What it is for
- Surfacing the dangerous questions before they are expensive
- Giving a new entrepreneur a sequence rather than a pile
- Making costing visible while the recipe is still changeable
- Keeping reference material next to the decision it informs
How far it customises
- The pathway order is content, not structure
- Thresholds and reference values are per-business
- Screens can be removed for operations that do not need them
- The same frame suits brewing, baking, blending or central production
Judgement demonstrated
- Product boundary decisions
- Distinguishing the chef's workspace from the operator's
- Resisting the pull to merge two products that look adjacent
- Refusing to let a prototype pose as a compliance authority
Sec. 08
Evidence ledger
Each statement on this page sits at one of five levels. Measured means recorded and quantified at the time. Documented means a retained artefact or record exists. First-person account means it rests on Ciarán's own testimony with no external corroboration. Inferred means it is reasoned from the design rather than shown by data. Not claimed means the page is explicitly not asserting it, and says why. Nothing is published above the level its evidence supports.
A working demonstrator exists and is available for inspection.
The 21 screens, five groups and pathway structure described on this page.
Data is held on the device rather than on a server.
The product-boundary decision separating chef tools from business tools.
That the model helps a new entrepreneur make better decisions.
Design intent. No user has been observed working through it.
Public business outcomes or client adoption.
None. It is a demonstration model, not a deployed product.
Compliance content as authoritative legal guidance.
Requires independent specialist review. Presented as reference content only.
Sec. 09
Reflection and next iteration
The compliance content needs a specialist before it carries weight in any jurisdiction, and the model says so on screen. A demonstrator should not pretend to be a legal reference.
The structure underneath it is the transferable part: sequence the questions in the order the decisions arrive, and surface the dangerous ones while the answers are still cheap to change. That holds for any operation bringing a product to market.
Sec. 10