Coco Aventura
The whole operation of a beach club with cabins, from booking to end-of-shift cash count.
I built the system that runs Coco Aventura, a beach club with rental cabins. It replaced notebooks and spreadsheets with one place that holds the entire day: who is sleeping where, who came in on a day pass, what sold, and how much should be in the till at close.
- My role
- Architecture, backend and front end
- Sector
- Turismo / Balneario y cabañas
- Scope
- App web
- 4 months
- Project duration
- 5 modules
- Operational modules shipped
- 4 streams
- Revenue reconciled per shift
- 2 registers
- Points of sale in parallel
Stack
- React (Vite)
- Material UI
- TypeScript
- Node.js
- Express
- MongoDB
Screens
Screenshots from the live system.
App web
Calendario, reservaciones y check-in
La parrilla de ocupación por cabaña y día, con el color marcando el estado de pago de cada estancia. El alta de reservación calcula la tarifa según fechas, tipo de cabaña y número de personas, y bloquea los empalmes. El check-in del día entrega brazaletes y registra el vehículo, y el mapa de cabañas muestra en tiempo real cuáles están ocupadas y por quién.
App web
Covers, day pass y eventos
El registro de quienes entran sólo por el día. Cada partida toma el precio de la tarifa vigente — el sistema rechaza cualquier otro — y va sumando el total del turno hasta que el cover se cierra. Los eventos con precio propio, como una noche de espuma, se cobran con su propio color de brazalete para distinguirlos en la puerta.
App web
Punto de venta, tiendita y rentas
Dos cajas trabajando a la vez: el punto de venta de la playa y la tiendita. Se cobra tocando el producto, se descuenta inventario en el momento y no deja vender lo que ya no hay. Las rentas de camastros y sombrillas llevan su registro diario con el resumen de lo cobrado.
App web
Brazaletes, compras y cierre de caja
El libro de brazaletes por color y por día: lo que había, lo que se usó, lo que se resurtió y en manos de quién quedó — bodega, tiendita o cada recepcionista. Las compras a proveedores entran a inventario con su ticket, y el corte de turno concentra reservaciones, covers, rentas y ventas del día para conciliar efectivo, tarjeta y transferencias contra lo que hay en la caja.
App web
Tarifas, cabañas y control de accesos
Las tarifas se configuran por servicio y temporada, con precios distintos entre semana, en fin de semana o en fechas concretas, y el calendario muestra cuál aplica cada día. Junto al catálogo de cabañas y tipos de servicio están los horarios del personal y los roles, donde se define módulo por módulo quién puede ver, crear, editar y borrar.
The problem
Coco Aventura is several businesses sharing one property: overnight guests in cabins, visitors who come in for the day only, a small store, and lounger and umbrella rentals. Each one ran on its own notebook or spreadsheet. Money arrives through four separate channels — bookings, day passes, rentals and store sales — and the till still has to balance at the end of every shift.
What I built
I built the system around an occupancy grid: one row per cabin, one column per day, color showing whether a stay is paid in full, held with a deposit, or unpaid. Creating a booking resolves the applicable rate on its own from the dates, cabin type and party size, and refuses to put two guests in the same cabin on overlapping dates. From there I closed the gaps where cash leaks: day-pass entries accept only the current day's rate, both registers deduct stock at the moment of sale and won't sell what isn't there, and wristbands run on a per-color ledger with transfers between storeroom, store and each receptionist. The shift close pulls bookings, day passes, rentals and sales into a single reconciliation of cash, card and transfers against what is physically in the drawer. Access is role-based, with view, create, edit and delete defined module by module.
Technical decisions
- 01
The occupancy grid is the main screen
Instead of a booking list, I made the calendar the primary screen: cabins down, days across, color encoding payment status. One view answers who is arriving, who is leaving and what is still free — which is what the front desk needs to know all day.
- 02
Price comes from the rate table, not the user
Rates are configured per service and season, with different prices on weekdays, weekends and specific dates, and a calendar showing which one applies each day. Day-pass entry rejects any amount other than that day's active rate, so nobody at the gate charges too much or too little.
- 03
One cabin, one guest, no overlaps
Creating a stay resolves the rate on its own from dates, cabin type and party size, and blocks two guests from holding the same cabin on overlapping dates. The cabin map closes the loop, showing in real time which ones are occupied and by whom.
- 04
Wristbands tracked by color and custody
I modeled wristbands as inventory with an owner: received into the storeroom, transferred to the store, handed out to the front desk, deducted as they are issued. The ledger balances per color, per day and per staff member. Priced events, like a foam night, go out on their own color so the gate can tell them apart.
- 05
One shift close, four revenue streams
The close pulls the day's bookings, day passes, rentals and sales together to reconcile cash, card and transfers against the money actually in the drawer. That is where the system stops being a record and becomes a control.
Next project
GRI Admin
Residential upkeep run off loose paper — now a system that proves what got done.