← Todos los posts

3 de mayo de 2026

AdrenalinaRD: cómo construí una plataforma de rifas con pagos online

Stack, decisiones de arquitectura y aprendizajes de construir end-to-end una plataforma con CMS, sistema de roles e integración de pagos UEPAPAY — mano a mano con Luis Angel Garcia Louis.

SoftwareNext.jsCaso de éxito

El reto

Construir desde cero una plataforma para gestionar rifas con tres bloques duros: pagos online seguros, panel administrativo con manejo de usuarios y roles, y un CMS personalizado para que el cliente pudiera publicar y administrar contenido sin tocar código.

Lo construí mano a mano con Luis Angel Garcia Louis, un desarrollador con quien trabajo desde hace años. Cada decisión técnica importante de este proyecto pasó por los dos.

Stack y decisiones

El stack final fue:

  • Next.js en App Router — para tener SSR donde lo necesitábamos (páginas de rifa indexables) y SSG donde no.
  • Node.js + Express en backend para los endpoints de pagos y la integración con UEPAPAY.
  • MySQL como motor de datos. La estructura: usuarios, roles, rifas, tickets, transacciones.
  • API UEPAPAY — el desafío más grande. Es la pasarela de pago dominicana que aceptaba el cliente.

Luis lideró buena parte de la integración con UEPAPAY y la lógica de transacciones; yo me concentré en el frontend, el CMS y la arquitectura general. La división se mantuvo flexible: cuando uno tropezaba en su lado, el otro entraba.

Lo que aprendimos juntos

1. Pagos: la prioridad es la trazabilidad

Cada transacción tiene un trail de eventos: "creada", "redirigida", "callback recibido", "ticket emitido". Si algún paso falla, el sistema sabe en qué punto reintentar o devolver dinero. La paranoia con la tabla de auditoría nos salvó múltiples casos.

2. CMS personalizado > CMS genérico

Pensamos en usar Strapi o Sanity. Decidimos construir el panel a medida porque el cliente necesitaba flujos muy específicos (publicar rifa, asociarla a un evento, generar QR de tickets). Un CMS genérico habría obligado a forzar el modelo de datos. Hacerlo a medida nos costó un mes más, pero el cliente lo opera sin pedir ayuda hace meses.

3. Roles desde el día 1

Empezamos con dos roles (admin, cliente). Hoy hay seis. Cada uno con permisos granulares. Si no hubiéramos diseñado el sistema con permisos por capability desde el inicio, refactorizarlo después habría sido doloroso.

4. Trabajar en pareja paga

La parte que más me llevo no es técnica. Es lo que se construye cuando dos personas se reparten un proyecto con confianza: las decisiones se discuten, los errores se atrapan antes de producción, y la calidad de cada commit sube porque sabes que alguien más va a leerlo. Si vas a construir algo no trivial, no lo hagas solo.

Resultado

La plataforma está en producción en adrenalinard.com desde 2024. Procesa pagos en vivo. El cliente publica rifas y eventos sin intervención técnica.

Lo que más rescatamos del proyecto: cuando construyes algo end-to-end con un compañero al que respetas, aprendes dónde no comprometer. Auditoría de pagos, roles bien diseñados y CMS específico al dominio. Los tres se justificaron en producción — y los tres se diseñaron entre los dos.

Crédito y agradecimiento permanente a Luis Angel Garcia Louis. Cada vez que se hable de AdrenalinaRD, es con él.

Comentarios pronto — Disqus pendiente de configuración