Ciarán KeoghCulinary systems

A financial command centre for a mobile working life

A private scenario-planning tool built around contract income, runway, allocation, actuals and recoverable records.

Independent buildArchived private build. A sanitised visual and description are published; the underlying personal data is not.

Audience

Personal planning · portfolio evidence

Operating scale

Single-user tool · multi-year scenarios

Period

July 2026

Confidentiality

Private source and assumptions. Public case study removes vessel, employer and financial specifics.

Sanitised dark-interface maritime financial planning dashboard with private figures removed.
A private scenario-planning tool built around contract income, runway, allocation, actuals and recoverable records.
The useful part was not predicting the future. It was forcing every assumption into the open where I could change it.

Sec. 01

Context and operating scale

Yacht and private-service work can make ordinary personal planning unusually fragmented. Income may arrive through contracts, home and work can sit in different jurisdictions, shore periods create a different expense pattern, and the documentation trail matters almost as much as the projection.

I wanted one place to test assumptions without turning a spreadsheet into another opaque dependency. The result was a single-file planning application designed to keep the model understandable and the records recoverable.

Sec. 02

The real problem

Most financial calculators answer one narrow question. This needed to connect cash runway, contract assumptions, reserves, allocation, career costs, milestones and actual outcomes without pretending any projection was certainty.

  • Separate assumptions from outcomes
  • Make conservative/base/optimistic paths visible together
  • Keep private information on the device
  • Export the underlying records in ordinary formats
  • Keep compliance/documentation tasks alongside the financial model rather than in memory

Sec. 03

My role

  • Defined the planning model and the boundaries of what it should not claim
  • Built the interface and scenario logic as a self-contained web application
  • Added local persistence, import/export and actual-vs-projection tracking
  • Kept legal/tax language framed as planning prompts rather than filing advice
  • Created a public-safe portfolio capture with private contract, vessel and financial information removed

Sec. 04

What I designed

The useful design decision was not a particular return assumption. It was making the assumptions editable and visible, then keeping the outputs, milestones and action list downstream of the same inputs.

  • Scenario controls for starting position, contract income, living pattern, protection and allocation
  • Base, conservative and optimistic projection paths
  • Milestone radar and actual-vs-projection tracking
  • A staged action map for protection, documentation, runway and long-term automation
  • Local save plus JSON/CSV export so the application is not the only place the information exists

Sec. 05

How it was used

Built for my own highly mobile working pattern. It is a planning instrument, not a financial product and not a public calculator.

The portfolio version deliberately removes all numbers and identifiers that could expose a vessel, employer, contract or personal balance sheet.

Sec. 07

Relevance by outcome

What it demonstrates

  • Turning a messy personal decision into an explicit model
  • Local-first data and ordinary-format recovery
  • Scenario thinking rather than false precision
  • Privacy boundaries designed into the presentation

Why it belongs here

  • It is outside the culinary domain but uses the same pattern: identify friction, model the decisions, build the tool
  • It was created because a real change in working pattern produced a real information problem
  • It tests whether the method transfers beyond kitchens

Honest limits

  • Single-user tool
  • Financial and tax outputs are assumptions, not advice
  • The private original is not published
  • No claim that projections predict future results

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 single-file planning application was built with editable scenarios, local saving, JSON/CSV export and actual-vs-projection tracking.

Evidence level: Documented

The published screenshot is a sanitised archive capture derived from the private build, with contract, vessel and personal figures removed.

Evidence level: Documented

The tool improves financial outcomes.

It is a planning aid used by one person. No outcome claim is made.

Evidence level: Not claimed

Sec. 09

Reflection and next iteration

This one is deliberately narrower in public than it is in private. A portfolio does not need access to the underlying numbers to show the design problem.

The recurring lesson is the same as the kitchen work: make the state visible, make the next decision explicit, and keep an escape route from the software itself.

Sec. 10

Related work

Next

Does this describe a problem you recognise?