analytics
Portafolio de Iván
Proyectos chevron_right JoGym

Sistema en producción · v1.5.0

fitness_center Gestión de gimnasio install_mobile PWA instalable notifications_active Web Push history_edu Changelog con SemVer

JoGym: el gimnasio en una PWA, con miembros, pagos y check-in por QR

Un gimnasio llevaba su control de miembros y pagos a mano. Hoy tiene una aplicación instalable con check-in por código QR, seguimiento de morosidad, recordatorios y purga de datos personales a petición.

Cifras clave

v1.5.0

versión en producción, verificable desde el servicio

10-ago-2026

fecha de entrada en producción

QR

check-in de miembros desde el teléfono

GDPR

purga de datos personales a petición

Stack

React 18Vite 5MUI 6Tailwindvite-plugin-pwahtml5-qrcodeExpress 5PostgreSQL 17JWT en cookieweb-push
schema

Un día en el mostrador

Todo el flujo diario cabe en un teléfono: el miembro llega, se registra, el sistema sabe si está al corriente y quién debe.

  1. qr_code_scanner Entrada

    Check-in por QR

    El miembro escanea y queda registrado, sin libreta ni hoja de cálculo.

  2. payments Pagos

    Estado de la membresía

    El sistema sabe quién está al corriente y desde cuándo.

  3. notification_important Cobranza

    Morosidad y recordatorios

    Los avisos salen por WhatsApp y por notificación push, sin perseguir a nadie de memoria.

  4. insights Dirección

    Métricas del negocio

    Asistencia y estado de las membresías, para decidir con datos y no con impresiones.

  5. delete_forever Datos

    Purga a petición

    Los datos personales de un miembro se pueden eliminar cuando lo pide.

store

Contexto

El negocio es un gimnasio que llevaba miembros, pagos y asistencia entre libretas y hojas de cálculo. Cada mes había que reconstruir a mano quién estaba al corriente, y la respuesta variaba según quién la reconstruyera.

Quien iba a usar el sistema todos los días no es una persona técnica y trabaja de pie, en el mostrador, con gente esperando. Eso descartaba cualquier solución que exigiera una computadora, una capacitación larga o un manual.

El encargo incluía además algo que no siempre se pide y aquí sí: poder borrar los datos personales de un miembro cuando lo solicite.

report

El problema

Si el sistema no cabe en el mostrador, no se usa; y si no se usa, el control vuelve a la libreta.

La mayor amenaza para un sistema de gestión pequeño no es un fallo técnico, es el abandono. Cualquier fricción —abrir la laptop, esperar una carga, buscar un registro entre pestañas— hace que la persona vuelva al papel el día que hay prisa. Y el día que hay prisa es todos los días.

El segundo problema era el de la confianza en lo desplegado. Cuando alguien reporta que «algo no funciona como ayer», hace falta saber con certeza qué versión está corriendo en ese momento, y no deducirlo.

Y el tercero fue de infraestructura: la publicación del sitio pasa por un túnel administrado de forma remota, donde la configuración local no tiene ningún efecto. Editar el archivo que parece el correcto no cambia nada, y el síntoma es un servicio sano que sencillamente no aparece.

rule

Decisiones clave

01 Aplicación instalable, no sitio web

Se construyó como PWA instalable, con lectura de códigos QR desde la cámara del teléfono y notificaciones push nativas del navegador.

psychology Porque el uso real ocurre de pie y con una mano. Una aplicación que vive en la pantalla de inicio del teléfono se abre en un segundo; un enlace guardado en el navegador, no se abre.

02 La versión desplegada se puede preguntar

El servicio expone su versión y el sistema mantiene un registro de cambios disciplinado, con versionado semántico, que se corresponde con lo que está corriendo.

psychology Sin eso, diagnosticar es adivinar. Poder preguntar «¿qué versión eres?» y recibir una respuesta fiable convierte una discusión sobre impresiones en una comprobación de treinta segundos.

03 Borrar de verdad cuando alguien lo pide

Existe una purga de datos personales de un miembro, pensada como derecho del titular y no como una limpieza técnica.

psychology En un negocio pequeño los datos de la gente se acumulan sin plan y nadie sabe dónde quedaron. Construir la salida desde el principio evita tener que improvisarla el día que alguien la reclama.

04 Aprender cómo se publica de verdad el servicio

La publicación pasa por un túnel administrado en remoto: la configuración local no publica nada y hay que modificarla por su interfaz de administración, respaldando antes el estado actual.

psychology Es la clase de detalle que no aparece en ninguna guía y cuesta una tarde entera la primera vez. Quedó documentado en el procedimiento de despliegue para que la segunda vez cueste cinco minutos.

construction

La solución

La interfaz es React con Vite, empaquetada como PWA instalable, con lectura de códigos QR en el navegador. El backend es Express sobre PostgreSQL, con sesión por token en cookie y notificaciones push.

Las funciones cubren el ciclo completo del gimnasio: alta y baja de miembros, registro de pagos, check-in por QR, seguimiento de morosidad, recordatorios por WhatsApp, métricas de asistencia y purga de datos personales a petición.

La disciplina de entrega es tan importante como el código: registro de cambios con versionado semántico y versión consultable en el servicio, para que cada despliegue sea verificable en vez de anunciado.

emoji_events

Resultados

lightbulb

Lo que aprendí

Que en software para negocios pequeños, la competencia no es otro sistema: es la libreta. Y la libreta gana siempre que la aplicación tarde más de unos segundos en estar lista.

Que un registro de cambios sirve para algo solo si se puede contrastar con lo desplegado. Mientras la versión no sea consultable, el changelog es una intención.

Y que la infraestructura ajena tiene reglas invisibles. Descubrir que la configuración local del túnel no publica nada costó tiempo una vez; escribirlo en el procedimiento hizo que no volviera a costarlo.