What a custom iteration looks like
Using a superyacht galley as a worked example of shaping a chef-first system to one operation.
Generic software makes the operation adapt to the tool. That is backwards, and it is why most kitchen software is abandoned within a season.
Sec. 01
Context and operating scale
Eight builds established an architecture: find, build, learn, tools, with culinary knowledge held next to the work and complexity kept underneath the interface.
That generality was deliberate — it had to hold across a restaurant, a production kitchen and a galley. But no chef works in the general case. They work in one operation, with specific equipment, specific standards and a specific set of things that go wrong.
The next step is the focused version: an iteration built around one operation. This page works that through on a superyacht galley, because it concentrates every constraint at once.
Sec. 02
The real problem
Generic software makes the operation adapt to the tool. That is backwards, and it is why most kitchen software is abandoned within a season.
The specific problem this example turns on: recipes, approved preparations, equipment knowledge and galley procedures stay attached to the person who created them. When that person rotates off, the operation loses its culinary memory and the relief chef rebuilds it from conversation and guesswork — in front of the owner.
The same shape appears elsewhere. A seasonal resort loses it every autumn. A multi-site group loses it every time a head chef moves. The galley is just the version where it happens fastest and hurts most.
Sec. 03
My role
- Framing the problem from the chef's side rather than the management company's
- Defining the boundary a custom build must not cross
- Setting the questions that have to be answered before any build starts
- Establishing the architecture the iteration would be built on
Sec. 04
What I designed
Worked through on the galley example, a focused iteration would carry:
- An operation-owned recipe library
- Approved preparations, held with the operation rather than the individual
- Equipment-specific notes tied to the actual kit
- Standard procedures written for the people who follow them
- Relief and incoming-chef onboarding
- Structured handover rather than a verbal one
- Controlled templates where a group wants consistency
- Explicit privacy and access rules
- Offline use as a baseline, not a feature
What it must not become
- Procurement software
- Accounting software
- Inventory bureaucracy
- A manager's surveillance dashboard
- One generic recipe book imposed across every site
Sec. 05
How it was used
Nothing is deployed. This is a direction with a worked example attached, and the page says so plainly.
It is published because the questions below are the ones a client would need to answer with me, and the people who can answer them — operations directors, captains, head chefs, owners' representatives — are the people this site is trying to reach.
The first engagement is more likely to be a narrow pilot than a platform: one operation, one handover problem, one measurable before-and-after.
Sec. 06
What a custom build has to answer first
- What knowledge is trapped in one person's head today?
- Who owns the library: the chef, the operation, the owner or the management company?
- What must stay personal, and what must stay with the operation?
- Which data is too sensitive to centralise?
- What makes a handover genuinely useful rather than merely complete?
- Which standards should be optional templates and which should be requirements?
- How should this behave offline, or on a poor connection?
- What would count as proof that it worked?
Sec. 07
Relevance by outcome
Financial relevance
- Less rework during a handover period
- Fewer provisioning errors from unclear preparations
- A shorter unproductive period after a chef changes
Compliance relevance
- Allergen and dietary information that survives a handover
- Traceable approved preparations
- Standards recorded where the work happens
Employee relevance
- An incoming chef who starts with the operation's actual standards
- Less pressure on the outgoing chef to write everything down at the last moment
- Onboarding that does not depend on one person being available
Why the galley is the useful example
- Every constraint at once: small team, no space, exacting standards
- Handover happens every rotation, not every few years
- Failure is visible to the owner immediately
- If the design holds here, it holds in easier environments
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.
The architecture the iteration would build on exists across eight preserved builds.
The problem framing, boundary and questions on this page.
That custom iterations are a current direction of the practice.
The superyacht galley as a worked example.
Illustrative. Not a client engagement, and no vessel or owner is involved.
Any deployment of any product to any operation.
None exists. Deliberately not claimed.
Client results.
None exist. Deliberately not claimed.
Sec. 09
Reflection and next iteration
I have the operational experience and the architecture. What makes a custom iteration work is the operation itself — its equipment, its standards, the specific handover that keeps going wrong.
A first engagement would be narrow: one operation, one problem, and a measurable before-and-after agreed before anything is built. That last part is the lesson from earlier work, where the results were real and the measurement was not mine to keep.
Sec. 10