An application that knows who may dive, and how deep

Fitness to dive has an end date, and the binder does not know it

Most clubs keep members in a spreadsheet: one row per person, their level, their membership, the date of their medical clearance. That is accurate the moment it is written. The trouble comes later: fitness to dive is not a fact that stays true, it is a state that changes on its own with the calendar. Nobody goes back over the row on the day the clearance runs out.

And it is trickier than a simple overdue date, because three dates compete for the same person — the medical clearance, the season's membership, sometimes a qualification's validity. The one that decides is the nearest, and it is not always in the same column. Reconstructing “who is clear on Saturday” from the spreadsheet means reading three columns per row with a calendar at hand: it gets done once at the start of the season, and never again.

An application re-reads nothing: it compares dates to today's date. The list of members whose validity is about to lapse is computed every time the screen is opened, with nobody maintaining it.

An outing is not a list of names

An ordinary trip sheet lines up first names and a meeting time. It leaves out what matters: who is supervising, who dives with whom, and what the resulting group may do. That last point is neither the average nor the sum of the levels — the most limiting one governs, and it changes the moment someone drops out the night before.

Modelling an outing as a free-text field loses exactly that. Modelling it as an object — a date, a site, a supervisor, attached participants — lets the screen show the real composition, and recompose it when someone is missing.

• An outing carries its date, its site, its supervisor and its participants.
• Each participant is an existing member, with the level held in their record — never a name typed again.
• The group's most limiting level is visible on the outing, without the application inventing a rule to derive it.

Club equipment has an identity, not just a quantity

“Twelve cylinders” is not usable information on the day one of them is due for inspection. What matters is that cylinder: its number, its last inspection date, the person it is currently lent to. A stock that counts quantities alone can answer none of those three questions.

It is the same distinction as between a model and an individual item: two identical regulators stop being interchangeable as soon as one is out and the other is being serviced. Each piece therefore carries its own row, its own lending history and its own inspection due date.

What the application is NOT

The most useful thing to say up front is where it stops — it saves you expecting what it does not do.

• It computes no dive planning: no tables, no stops, no decompression. It is not a dive computer, and it replaces neither club procedures nor the supervisor's judgement.
• It queries no federation: membership and level are entered by the club, never verified online against a third party.
• It sends no email and no SMS: it displays the deadlines coming up, the follow-up stays in your hands.
• It reads no certification card and no barcode: levels are picked on screen.
• It does not work offline — which matters for this activity, because the deck of a boat is precisely where the network is missing. Dive groups are put together before leaving.
• There is no separate member portal: rights are global (administrator, user, read-only), and a read-only account sees the whole application, not just its own record.

Your data stays yours

Whatever is entered can be retrieved from the Settings screen, as JSON or CSV, dataset by dataset. A member list exported as CSV opens in a spreadsheet, sorts, prints for a general meeting and goes into a grant application.

Lists filter and sort, and a trash lets you restore a row deleted by mistake — handy when data entry rotates between volunteers who each take a shift once a month.