Case study · Dive school

Club SEC 17.

A 50-year-old dive school in Tipaza, taken off WhatsApp and onto a system it runs itself.

Get a free auditVisit sec-17.com
Sector
Dive school · tourism
Role
Product design · Web development · Analytics
Period
March 2025 — ongoing
The Club SEC 17 reservation page: a full-width underwater hero reading Réservation votre baptême de plongée, with a single booking call to action and a gallery of dive photography below it.
The booking entry point — one screen, one action, real availability behind it.
At a glance

Measured on the live site.

M
Measured — Taken from the live site by our own capture run, on real Chromium.
C
Client-reported — Supplied by the client from their own records. We did not observe it.
0.49 sMLargest Contentful PaintGoogle's “good” threshold is 2.5 s. This is five times inside it.
0.001MCumulative Layout ShiftNothing moves under the reader's thumb while the page loads.
520 KBMPage weight, across 59 requestsThe web median is close to 2.5 MB for the same job.
10MStructured-data types publishedReservation, Offer, Review, Service and six more — machine-readable, not just readable.

Club SEC 17 has taught people to dive off Port de Tipaza since 1974. Its reputation arrived long before its infrastructure did: every reservation, every availability check and every follow-up ran through two personal phone numbers. We built the operating layer that reputation deserved — a self-service booking flow with real capacity behind it, a staff dashboard that replaced memory with a shared record, QR-verifiable certificates, and a consent-tracked photo delivery pipeline. It ships on Next.js, loads its largest element in under half a second, and the club runs it without us.

The brief.

The club's market is French-speaking leisure divers and tourists around Tipaza and Algiers, most of them arriving on a phone from Instagram or word of mouth, booking a first baptême or a P1–P3 certification. The constraint that shaped every decision: this is a cash market with no online payment, so the site's job is not to take money — it is to hold an accurate, confirmable place in a real diary.

Where it started.

There was no digital operations layer at all. Reservations, capacity and follow-up lived across two WhatsApp and phone numbers. Nobody had a shared view of which dates were already full, so on any day two staff members answered messages at once, double-booking was a live risk. Past divers existed only as chat history. Certificates and dive photos were handed over ad hoc. And there was no way to see how anyone had found the club, so every marketing decision was a guess.

Client-reportedC
  • Two personal phone numbers as the entire booking system
  • Capacity tracked by memory, cross-checked by scrolling chat history
  • No structured record of past divers to re-engage
  • Certificates unverifiable once out of the club's hands
  • No analytics — no answer to “where do bookings come from?”

The before state is described from the club's own account of how it worked in March 2025. No archived version of this domain exists from before the engagement, so none of it is presented as something we measured.

What it had to achieve.

  1. 01Move discovery-dive reservations off phone-and-WhatsApp onto a self-service flow the diver completes alone.
  2. 02Give staff one place to see and manage capacity instead of reconstructing it from chat threads.
  3. 03Make a certificate checkable by a third party without the club being in the loop.
  4. 04Put a measurement layer in place so the next decisions are read rather than guessed.
The work

What we built.

Five pieces. Each one replaces something the club was doing by hand, and each one is named by what it took off their plate.

01

Self-service booking with real capacity behind it

The booking route carries per-date capacity limits and detects an existing upcoming reservation on the same phone number, so what a diver sees is the real diary rather than an optimistic form that someone has to reconcile later.

Duplicate detection keys on the phone number rather than an account, because this audience will not create one — the flow has to work for a first-time visitor who arrived from Instagram ninety seconds ago.
ReplacesC

A WhatsApp thread where staff checked availability by memory, and a double-booking risk any time two people answered at once.

0.52 sMLCP on mobile40Mrequests on the mobile build
The same reservation page at phone width: the hero headline, the location, a “+1000 divers trust us” line, and a full-width booking button within thumb reach.
The screen most of this audience actually meets — a 390 px-wide capture of the same route.
02

An admin dashboard that replaced staff memory

Seven areas — reservations, availability, photos, certificates, messages and users — behind one sign-in. The overview answers the two questions that decide a dive day before it starts: how many divers are coming, and who still has to be phoned. Capacity for the next nine days is drawn as one chart, with sea-closed days hatched straight into it, so a date that looks bookable but isn't reads as closed without opening anything.

The system didn't abolish the phone call — it scheduled it. Confirmation still happens by phone the day before, because that is how the club actually runs; the dashboard's job is to make sure nobody is missed, and to count the attempts when someone doesn't pick up.
ReplacesC

Capacity that existed only in the heads of the two people answering the phones.

7Mareas behind one sign-in9 daysMof capacity without a click
The Club SEC 17 staff dashboard: a left sidebar listing reservations, availability, photos, certificates, messages and users; four counters across the top for today, tomorrow, the next seven days and reservations still to confirm; a nine-day bar chart of divers per day with sea-closed days hatched; a call list for tomorrow; and quick actions for a new reservation, generating certificates and setting the sea state.
The staff overview on a working day — a live diary with real load on it, not a seeded demo.The one diver on tomorrow's call list has had their email address and phone number painted out of this image. Nothing else on the screen is altered.
03

Certificates that verify themselves

Certificates are generated automatically and carry a QR code pointing at a public verification route, so a dive centre or an employer anywhere can confirm a credential without contacting the club.

ReplacesC

Ad hoc documents that nobody outside Tipaza could check.

1Mfield to verify a certificate
The public certificate verification page: a headline reading Vérifier un certificat and a single eight-character code field above a Vérifier button.
One field, no account, no email to the club. The whole verification surface.
04

Watermarked photo delivery, with consent on the record

Dive photos are watermarked and delivered through a token-scoped link, with an explicit consent step recorded per recipient before anything is shared.

ReplacesC

Photos sent by hand over WhatsApp and Instagram, with no record of who agreed to what.

Every delivery link is scoped to one recipient and one set of photographs. There is no public URL to screenshot, and manufacturing one would misrepresent how the pipeline works.

05

The measurement layer

Google Analytics 4 and Microsoft Clarity both run on the live site — counted events alongside session recordings and heatmaps, so the club can see not just how many people reached the booking screen but where they hesitated on it.

ReplacesC

No analytics of any kind, and therefore no way to tell a good decision from a lucky one.

2Manalytics tools live
Architecture

How the system works.

Three flows, one record. Everything a diver touches writes to the same reservation store the staff dashboard reads, and both ends of the booking flow report to the measurement layer.

How the SEC 17 system fits togetherA diver reaches the booking page, which checks per-date capacity and looks for a duplicate reservation on the same phone number. Available bookings are written to the reservation store; full dates and duplicates are sent back to the booking page. The staff dashboard reads that same store, and produces two things: a certificate carrying a QR code, which anyone can check on the public verification route, and watermarked photographs, delivered over a token-scoped link with recorded consent. The booking page and the reservation store both report to the measurement layer, Google Analytics 4 and Microsoft Clarity.Public verification/verifyToken link + consentCertificate + QRWatermarked photosDiverBooking page/bookingCapacity + duplicate checkReservation storeStaff dashboardGA4 · Microsoft Clarityavailablefull or duplicate

Carries a reservationObserves onlyScroll the diagram sideways to follow the whole flow.

Evidence

The numbers.

Taken from the live site by our own capture run, on real Chromium, on the date at the foot of this page. Every row carries the method that produced it.

Measurements taken from the live site, each against its public threshold where one exists.
MetricMeasuredBenchmark
Largest Contentful Paint — desktop0.49 sMGood < 2.5 s
Largest Contentful Paint — mobile0.52 sMGood < 2.5 s
Cumulative Layout Shift0.001MGood < 0.1
Time to first byte197 msMGood < 800 ms
Page weight520 KBMMedian site ≈ 2.5 MB
Images served through an optimising pipeline67 of 69M
Structured-data types published10M
Security headersHSTS + CSPM
How each number was obtained
Largest Contentful Paint — desktop
Headless Chromium at 1440×900, PerformanceObserver on the live site.
Largest Contentful Paint — mobile
Headless Chromium at 390×844 on a 2× device pixel ratio — the device class most of this audience arrives on.
Cumulative Layout Shift
Accumulated over the full load, excluding shifts that follow user input.
Time to first byte
Navigation timing, served from Vercel's edge.
Page weight
Sum of transferred bytes across 59 requests on the home page.
Images served through an optimising pipeline
Counted from rendered image sources; 67 also carry responsive srcset and lazy loading.
Structured-data types published
JSON-LD @type values across the crawled pages: SportsActivityLocation, Reservation, ReserveAction, Offer, Service, Review, Person, PostalAddress, AdministrativeArea, EntryPoint.
Security headers
Present on the live response, alongside HTTPS across the whole domain.
What changed

Before → After.

Seven capabilities, as the club described them in March 2025 and as they stand on the live site today.

  • Taking a booking

    BeforeCPhone and WhatsApp, manually cross-checked

    AfterSelf-service form with real capacity behind it

  • Knowing a date is full

    BeforeCStaff memory and chat history

    AfterPer-date limits enforced at submission

  • Double-booking risk

    BeforeCLive whenever two people answered at once

    AfterDuplicate detection on the phone number

  • Record of past divers

    BeforeCWhatsApp scrollback

    AfterStructured reservations in a staff dashboard

  • Certificates

    BeforeCAd hoc, unverifiable outside the club

    AfterGenerated with a QR code and a public verification route

  • Photo delivery

    BeforeCManual sends, no consent record

    AfterWatermarked, token-scoped, consent recorded

  • Behavioural analytics

    BeforeCNone

    AfterGA4 and Microsoft Clarity live

Every entry in the before column is the club's own account, not something we measured — no archived version of this domain exists from that period. Every entry in the after column is observable on the live site today.

Details

Craft details.

Built for a thumb, not a desk

The audience arrives on a phone from Instagram. The mobile build ships 40 requests, has no horizontal overflow, and holds layout shift at zero while it loads.

Machine-readable, not just readable

Ten JSON-LD types including Reservation, Offer and ReserveAction mean a search engine can present the club as a bookable business rather than a page about diving.

Fast because of what is not there

520 KB across the whole home page, against a web median near 2.5 MB — with 67 of 69 images going through an optimising pipeline with responsive sources and lazy loading.

French-first, properly declared

The document declares its language, which is what lets a screen reader pronounce it and a search engine target it — a detail that is invisible until it is missing.

In a diver's words
Plonger fi SEC 17 kanet une aventure inoubliable! L'eau kanet cristalline ou les guides kanou yaarfou chaque détail du site.
Isak Bourahla — Plongeur certifié P2

Where it stands.

  • The club takes reservations without a person mediating every one of them.
  • Capacity is enforced by the system rather than remembered by staff.
  • A certificate issued in Tipaza can be checked from anywhere.
  • Two measurement tools are live, so the next round of decisions has data underneath it.

Conversion and booking-volume deltas are deliberately absent from this document. They need a tracked baseline running over a full season, and that data does not exist yet. When it does, it goes here as a measured number — not as an estimate.

What's next.

The engagement is ongoing. These are the three things in front of it.

  1. 01Define the conversion events in GA4 so booking starts, completions and abandonment are counted rather than inferred.
  2. 02Read a full season of Clarity recordings against the booking screen and cut whatever causes hesitation.
  3. 03Add alt text to the remaining gallery images — 45 of 69 currently ship without it.
Screens

The same system, on a phone.

The staff dashboard at phone width: the four counters stacked two by two, the call-back alert, and the nine-day capacity chart, all reachable without a horizontal scroll.
The staff overview at 390 px. The counters restack and the capacity chart stays whole.
The certificate verification page at phone width, with the code field and Vérifier button filling the screen.
Certificate verification at 390 px — the same single field, no account, no app.
The staff sign-in screen at phone width, the crest and both fields centred in a single card.
Staff sign in from the boat, on the same phone the diver booked from.

About this document

M
Measured — Taken from the live site by our own capture run, on real Chromium.
C
Client-reported — Supplied by the client from their own records. We did not observe it.
  • Live measurements taken 27 August 2026.
  • Captured with headless Chromium at 390×844 (mobile) and 1440×900 (desktop), motion disabled. The staff dashboard was captured separately, from an authenticated session, at the resolution it is worked at.
  • The capture run was read-only: only GET requests were issued, form submission was disabled in the page, and no data was created, changed or deleted on the client's system.
  • Personal data is kept out of these screenshots two ways. On the public pages it was replaced with placeholders in the page before the capture. On the staff dashboard one diver's contact details were painted out of the image afterwards, and the shot says so where it appears. The layout and the behaviour shown are real; the personal details are not.
  • Nothing here is composited, recoloured or rearranged. The only edits to any image are those redaction blocks and one crop to its subject.
  • Measurements describe the live site on the capture date and will drift as the site changes.

That's one of four. The rest are on the way back.

Back to all workVisit sec-17.com