Business systems & digital transformation

From paper and disconnected spreadsheets to seven integrated production systems

Organisation: Mare Blu Tuna Farm Ltd
Sector & market: Aquaculture — Malta
Role: Administration OfficerFunctional scope: Business Systems & Digital Transformation Lead
Period: Jul 2023 – Present

A farming operation whose regulatory obligations and cost truth were the same events written down twice — once on paper for the authorities, once in spreadsheets for management — and reconcilable to neither. Rebuilt around a single operational record.

Headline figures

7systems in daily production use

Basis: Web, desktop and Android, on two PostgreSQL databases

500+bait containers tracked end to end each year

Basis: Shipment, port arrival, discharge, warehouse, consumption and empty return — with demurrage, plugging, storage and inland haulage cost

85%faster supplier payment processing

Basis: Fourteen hours to two hours, through workflow redesign and automation

€200–500Kestimated external replacement cost

Basis: Independent estimate for procuring the delivered scope externally
Frame: Avoided replacement cost, not a cash saving.

The starting point

Tuna farming is a regulated operation before it is a commercial one. Every fish that enters a cage, every transfer between cages, every harvest and every kilogram of bait consumed has to be documented for the authorities — and the same events determine stock, cost and margin.

In practice those two obligations were being served twice over. Operational events were written on paper at sea and on the pens, then re-keyed on shore into spreadsheets that had grown up one at a time, each owned by a different person and none of them speaking to the others. Bait arriving in refrigerated containers was tracked in one place, its consumption in another, its cost in a third.

The result was predictable: two versions of the same event that drifted apart, reconciliation work that consumed the people who should have been running the farm, and no single place anyone could go to answer what the operation actually had, had used, or had spent.

Diagnosis

The instinct in this situation is to build reports. That would have produced faster access to the same divergent numbers, because the divergence was created upstream of any report.

The unit that mattered was not the report. It was the operational event. A feeding, a caging, a transfer, a harvest, a container unloaded — each of these is simultaneously a regulatory record, a stock movement and a cost. Recording them once each for three different purposes guaranteed they would disagree.

So the architecture had to invert. Capture the event once, at the place and moment it happens — which on a tuna farm means on a tablet, on a boat, with no connectivity — carrying its author and its timestamp. Then let regulatory documentation, stock, costing and management reporting all become views of that same record rather than separate books.

That decision has a consequence people usually resist: if the record is the evidence, it cannot be deleted. Events can be voided or reversed, and the correction is itself a record with its own author and date. What looks like an inconvenience is the whole point — it is what makes the system defensible to an auditor and to the operation itself.

Mandate and scope

Contractual roleAdministration Officer. The systems work was delivered as functional scope, not as a separate job title.
OwnedOperating model and functional architecture; business rules; data models and structures; reporting formats; platform choices; the permissions and access model; QA and validation criteria; the direction of debugging and correction; deployment, training, support and production acceptance. The operational and regulatory knowledge the systems encode is mine.
AI assistanceClaude was used to accelerate code implementation, evaluate technical alternatives, refactor, debug, run verification checks and draft technical documentation. It did not define what the systems do or decide whether they were fit for production.
Not ownedCommercial decisions of the farm, and the fishing and husbandry operations themselves.

The operating model

The architecture is the diagnosis made concrete: one capture point per event, one record, four readings. Commercial terms, supplier identities and regulatory case detail are omitted.

Implementation

Systems in production

Feeding App v3Daily feeding operations and consumption against stock.
Captain AppOffline capture at sea, synchronised on return to shore.
Supervisor AppSeven read-only live views across both databases.
Caging AppCaging, transfers, releases and harvesting, with authority reporting.
Bait ControlContainer logistics, unloading, consumption, FIFO costing and landed cost.
Controlled StockRestricted-access register for regulated items, with full movement history.
Reports ViewerWeb reporting portal — 39 reports across five access roles.

Before

Events written on paper at sea, re-keyed on shore — two records of one thing
Spreadsheets grown one at a time, each owned by a different person, none reconciled
Bait arrival, consumption and cost tracked in three separate places
No attribution: no reliable way to say who recorded what, or when
Supplier payment processing taking a full working day and a half

After

Offline capture on tablets at sea, synchronised on return — one record, at source
Seven systems on two PostgreSQL databases, in daily use by 22 people
Container tracked end to end, with FIFO costing and landed cost in the same record
Void and reverse instead of delete; author and timestamp retained on every event
Supplier payment processing at two hours

The systems were rolled out into a working farm, not a pilot. That set the constraints: nothing could require connectivity the boats do not have, nothing could be slower than the paper it replaced, and every screen had to make sense to someone whose job is fish, not software.

Five access profiles were defined against how the operation is actually run rather than against the org chart, and I ran the training, the support and the production acceptance myself. Adoption is what the work is measured on — twenty-two people using it every day is the result. The code is not the deliverable.

Results

Measure	Before	After	Basis of measurement	Result
Operational record	Paper and isolated spreadsheets	One operational and regulatory source	Seven systems on two PostgreSQL databases, in daily production use	7
Supplier payment processing	14 hours	2 hours	Workflow redesign and automation	−85%
Reporting	Compiled on request	39 web reports, standing	22 named users across five access roles	39
Capture at sea	Paper, re-keyed on shore	Offline entry, synchronised on return	Three Android applications	3
Bait supply chain	Three disconnected records	End-to-end, with landed cost	Shipment, port, discharge, warehouse, consumption and empty return; demurrage, plugging, storage and inland haulage	500+/yr
Record integrity	Deletable, unattributed	Void or reverse only	Author and date retained on every operational event	—
External replacement	Procurement path	Built in-house	Estimated external cost of procuring the delivered scope — avoided replacement cost, not a cash saving	€200–500K

What I carry forward

Capture the event once, where it happens. Everything downstream — regulatory, stock, cost, management — is a view, not a second book.
A record you can delete is not evidence. Void and reverse, and keep the author and the time. The friction is the control.
Design for the boat, not the office. Offline was the normal case here, not the edge case, and treating it that way decided the architecture.
Adoption is the deliverable. Twenty-two people using it daily is the result; shipping the code was the easy half.

Scope and measurement note

Figures reflect systems in production use at Mare Blu Tuna Farm Ltd as at the date of writing. The €200,000–€500,000 range is an estimate of what procuring the delivered scope externally would have cost; it is presented as avoided replacement cost and not as a cash saving.

I retained ownership of the functional architecture, operating logic, business rules, data models, reporting formats, platform choices, QA, deployment, training, support and production acceptance. Claude was used to accelerate code implementation, technical alternatives, refactoring and debugging.

This case study describes system architecture and delivery method. Omitted by design: supplier identities, commercial terms, procurement values, quota and regulatory case detail, and the specifics of the security configuration — encryption standards, backup schedule and retention windows are described by their existence, not their settings.