A mobile-first jet-ski rental experience with structured WhatsApp requests, per-unit availability logic, fleet operations, and a D1-backed administration model.
Portfolio showcase only. The client source repository remains private. This repository contains no customer records, production credentials, database exports, confidential commercial documents, or proprietary source code.
Paname Jet is a product for a seasonal water-sports operator at Marina de Saïdia, Morocco. It combines a public mobile experience with the foundations of a booking, fleet, and operations system.
The current customer journey is intentionally honest: official packages and prices have not been supplied, so the site does not invent them or present automated booking as active. It captures a structured request and opens WhatsApp for manual confirmation by the owner.
The private implementation also contains a D1-backed booking engine, physical-unit availability, maintenance windows, operational checks, audit records, and an administration PWA. Those paths remain dormant until commercial and legal inputs are validated.
Jet-ski rental operations involve more than a date and time. The business must coordinate enquiries, physical machines, preparation buffers, maintenance, customer checks, and on-site payment. A brochure site cannot prevent scheduling conflicts; a generic calendar does not model several units of the same machine.
- Present only verified business and fleet information.
- Fall back to a structured WhatsApp request while offers are incomplete.
- Model each physical jet-ski as a bookable operational unit.
- Check reservations and maintenance periods with a ten-minute buffer.
- Provide administration workflows for planning, status, fleet, checks, and maintenance.
- Persist structured operating data in Cloudflare D1.
- Customers: discover the fleet and request availability from a phone.
- Owner/manager: confirm requests and monitor daily planning.
- Operations staff: manage arrivals, briefings, preparation, sessions, returns, and maintenance once accounts are configured.
- Responsive public experience.
- Verified location, contact, schedule, and fleet models.
- Structured manual WhatsApp request.
- PWA manifest, icons, and service worker.
- Private owner-only Sites deployment.
- Offer selection and price snapshots.
- Per-unit calculated slots.
- D1 booking creation.
- Customer booking reference/access link.
- D1-backed administration workflows.
- Online payment or deposit.
- Automatic booking confirmation.
- Production push notifications.
- Electronic signature capture.
- Validated rental contract content.
- Eight-step reservation journey that activates only for validated offers.
- Per-unit fleet model: four YAMAHA VX-C units and one YAMAHA FX SVHO 1800.
- Reservation and maintenance overlap checks.
- Ten-minute operational preparation buffer.
- Last-departure rule at 19:30.
- Booking lifecycle and limited customer lookup link.
- On-site identity and contract check fields.
- Fleet create/edit/status/maintenance/archive workflows.
- Audit records for booking and fleet operations.
- Fictional browser-local demonstration environment.
- Missing business data is a product constraint. No price, duration, deposit, or legal term is fabricated.
- The live CTA follows the real operating process. WhatsApp remains the confirmation channel until the owner validates automation inputs.
- Availability is physical. A fleet model can have several units; bookings and maintenance block individual machines.
- Operations need turnaround time. The availability engine includes a preparation buffer.
- Demo and operating data are separated. The public demonstration uses fictional browser-local records; D1 is the structured persistence path.
flowchart LR
Customer[Mobile customer] --> Public[Next.js public experience]
Public --> WhatsApp[Structured WhatsApp request]
Public -. validated offers .-> API[Route handlers]
Admin[Authenticated admin PWA] --> API
API --> D1[(Cloudflare D1)]
API --> Availability[Availability engine]
Availability --> D1
D1 --> Bookings[Bookings and checks]
D1 --> Fleet[Fleet and maintenance]
D1 --> Audit[Audit log]
The private application uses Next.js-compatible components through Vinext/Vite and produces a Cloudflare Worker-compatible build. D1 access stays behind one helper and uses prepared statements.
See Architecture Notes.
| Area | Stored data |
|---|---|
| Bookings | Customer contact, assigned unit, schedule, status, integer-cent snapshots, capability token |
| Fleet | Individual unit, model, capacity, status, bookable flag, archive state |
| Maintenance | Blocking time window, reason, and state |
| Operating checks | Identity and contract verification state |
| Audit | Actor, action, entity, time, and metadata |
| Local roles | Development-only seeded role |
Indexes match the implemented queries: unique booking reference/access token, unit/start uniqueness, maintenance-window lookup, and model/availability lookup.
flowchart TD
Request[Model, date, duration] --> Units[Load bookable units]
Units --> Busy[Load bookings and maintenance]
Busy --> Buffer[Apply ten-minute buffer]
Buffer --> Free{Free unit?}
Free -->|Yes| Assign[Assign first ordered unit]
Free -->|No| Conflict[Return conflict]
- Platform-provided identity for the hosted administration.
- Owner-only Sites access policy at the time of this portfolio audit.
- Server-side identity checks on admin pages and APIs.
- Production-disabled local fallback with environment-provided credentials.
- Prepared D1 statements and bound parameters.
- High-entropy customer capability tokens.
- Limited reservation projection on the customer lookup endpoint.
- Git exclusions for environment files, local D1 state, raw client assets, and confidential commercial documents.
- Hosted identity is authentication, not business authorization; an explicit operator allowlist is required before changing the owner-only access boundary.
- Booking capability tokens are stored in plaintext.
- Public booking needs rate limiting and bot protection before activation.
- Overlap detection is check-then-insert and needs stronger concurrency guarantees.
- PII retention and deletion procedures are not yet documented.
See Security and Privacy.
- Representing five physical units across two fleet models.
- Combining reservations, maintenance, and preparation buffers.
- Keeping the product useful without inventing missing prices.
- Separating a public fictional demo from D1-backed operating data.
- Preserving a safe authorization boundary around the administration.
| Decision | Why |
|---|---|
| D1 + Drizzle migrations | Durable relational state close to the Worker runtime |
| Integer cents | Exact future price/deposit snapshots |
| Per-unit fleet records | Supports real capacity, assignment, and maintenance |
| Prepared statements | Explicit parameter binding |
| WhatsApp fallback | Matches current operations while commercial data is incomplete |
| Capability lookup link | Limited customer access without a full account system |
The screenshots contain no customer names, phone numbers, booking records, credentials, commercial prices, or maintenance notes.
The private implementation was verified on 28 August 2026 with:
- ESLint;
- TypeScript checking;
- a production Vinext build;
- 7 passing product-structure and rule tests;
- Git whitespace validation;
- Gitleaks scanning of the exact committed tree.
The current tests are mainly structural. Database-backed concurrency, authorization, and browser end-to-end coverage remain future work.
AI accelerated implementation, debugging, content verification, and documentation. Product constraints, architecture, data modeling, security review, and acceptance remained human-controlled. Missing prices, specifications, and legal terms were deliberately left unpublished.
The private repository identifies Moad as its sole contributor. Repository evidence supports ownership of the public experience, product-state decisions, availability model, D1 schema, APIs, administration interface, deployment setup, and verification. Client discovery, live usage results, and final handover scope are not documented in Git and are intentionally not claimed.
TO CONFIRM WITH MOAD: packages, durations, and official MAD prices.TO CONFIRM WITH MOAD: inclusions, group/private-event conditions, and equipment terms.TO CONFIRM WITH MOAD: validated contract, waiver, and legal notices.TO CONFIRM WITH MOAD: operator accounts and production authorization policy.TO CONFIRM WITH MOAD: PII retention/deletion policy.
- Add explicit operator authorization before changing site access.
- Make overlapping booking creation race-safe.
- Hash and expire capability tokens.
- Add rate limiting, bot protection, and notification delivery.
- Add integration and end-to-end tests.
- Activate booking only after commercial and legal validation.
This public repository intentionally excludes implementation code and operating data. Paname Jet names, logos, and fleet imagery belong to their respective owners and are shown only to document the delivered product.