MF.
ESEN
Volver al portfolio

Estudio de caso / Producto mobile-first · Reglas transaccionales

Kender Club

Descubrir lugares. Canjear beneficios con reglas claras.

Aplicación mobile-first de descubrimiento editorial, comercios asociados y beneficios, con puntos QR/NFC y paneles de gestión.

Tecnologías utilizadas
Angular · NestJS · TypeScript · PostgreSQL · Prisma · JWT · S3

El producto en pantalla

Capturas reales del entorno de desarrollo con datos de prueba. No representan usuarios ni actividad comercial.

Pantalla real de descubrimiento de Kender Club en desarrollo con catálogo de prueba.
Descubrimiento mobile-firstAbrir captura completa
Panel real de resultados de Kender Club en desarrollo con métricas de prueba.
Resultados del partnerAbrir captura completa

El problema

Un catálogo atractivo no basta para operar beneficios: hay que distinguir lugares editoriales de comercios asociados, respetar cupos y períodos de uso, recuperar comprobantes y aislar los datos de cada partner.

Mi participación

Desarrollo la experiencia Angular para consumidores, administración y comercios, junto con el backend NestJS y el dominio PostgreSQL/Prisma. Diseño las reglas de canje, idempotencia, permisos y métricas que sostienen el recorrido comercial.

Qué permite hacer

Descubrimiento con criterio editorial

Una experiencia mobile-first conecta catálogo, detalle de lugares, fotografías, horarios y perks. Los lugares editoriales pueden existir sin partner; el contenido no depende de una transacción comercial.

Del punto físico al comprobante

QR y NFC abren la misma URL de un Point revocable. El backend valida partner, lugar, beneficio, cupo y frecuencia; confirma canje y visita válida en una transacción y permite recuperar el comprobante autenticado.

Gestión y señales comerciales

Admin incorpora comercios, lugares, beneficios y puntos. El panel del partner muestra canjes confirmados y visitas por fuente. Las reseñas requieren autenticación y moderación; no se presentan como prueba de compra ni de visita.

Cómo encajan las piezas

Dos aplicaciones Angular comparten contratos con una API NestJS: consumidor y Admin/Business. PostgreSQL conserva la verdad comercial. Place, Partner, Perk, Point y Redemption tienen identidades y relaciones explícitas. La pertenencia del usuario al partner se verifica en backend; las fotos se gestionan mediante almacenamiento compatible con S3.

Relaciones entre componentes del MVP
  1. Consumidor Angular
    Catálogo · auth · canje
    NestJS API
  2. QR / NFC Point
    URL revocable · token hash
    Redemption
  3. Redemption
    Canje + visita · transacción
    PostgreSQL
  4. Admin / Business
    Roles · pertenencia · métricas
    NestJS → PostgreSQL

Decisiones de ingeniería

Confirmar de forma atómica

La transacción Serializable revalida el Point y las reglas de uso antes de consumir el último cupo. La clave de idempotencia y el fingerprint permiten repetir una petición sin duplicar un canje ni aceptar otra intención con la misma clave.

Separar catálogo editorial y relación comercial

Un lugar puede existir sin partner, mientras beneficios y puntos físicos necesitan una relación comercial válida. Modelo esas entidades por separado y guardo snapshots del beneficio y del comercio al canjear. Así cambiar el catálogo o reasignar un lugar no reescribe el comprobante ni su atribución histórica.

Resolver el acceso desde la membresía

Consumidores, comercios y administración comparten dominio, pero no visibilidad. El backend deriva el partner permitido de la membresía y filtra consultas y métricas por esa identidad. Los comprobantes se recuperan sólo por su propietario; el panel comercial recibe agregados sin emails de consumidores ni tokens físicos.

Dificultades resueltas

Concurrencia y respuestas perdidas

Las pruebas PostgreSQL ejercitan carreras por el último cupo, misma clave simultánea y rollback. Si se pierde la respuesta después del commit, el usuario recupera el comprobante propio en lugar de consumir otro beneficio.

Datos aislados entre partners

Las consultas del panel parten de la membresía del usuario. Los agregados y el historial mantienen atribución comercial sin exponer emails de consumidores ni tokens físicos a otros comercios.

Capacidades demostrables

Un recorrido comercial completo

La confirmación conserva visita, comprobante y términos del beneficio incluso ante reintentos o cambios posteriores del catálogo.

Frontend y dominio verificables

Tests de permisos, privacidad y concurrencia respaldan los estados de error y recuperación. Las cifras mostradas son fixtures de desarrollo, no adopción comercial.