Contexto / Problema

Una financiera mexicana de préstamos personales operaba su proceso de ventas enteramente por WhatsApp, hojas de cálculo y papel. Solicitudes llegaban por mensajes, documentos se fotografiaban de forma informal, y la aprobación dependía de llamadas telefónicas. El resultado: solicitudes perdidas, tiempos de respuesta inconsistentes, y cero trazabilidad ante fraudes.

El problema raíz no era tecnológico — era de proceso. Antes de escribir una sola línea de código, dediqué las primeras dos semanas a mapear cada paso del flujo con el director y los asesores de campo. Eso reveló 5 roles distintos con necesidades completamente diferentes, y un proceso de 7 etapas entre la solicitud inicial y el desembolso.

Decisiones técnicas

React + Node.js por la velocidad de desarrollo y el ecosistema maduro para sistemas de negocio. Prisma para type-safety en las consultas de base de datos — crítico cuando hay lógica de estados complejos (solicitud → verificación → aprobación → entrega → cobranza). Supabase para auth y almacenamiento de evidencias fotográficas con acceso controlado por rol.

El sistema de roles fue la decisión más importante: 5 tipos de usuario (asesor, verificador, gerente, administrador, cobranza) con vistas y permisos completamente distintos. Evalué RBAC con bibliotecas existentes pero la lógica de negocio era suficientemente específica como para implementar un sistema propio más simple y auditable.

Railway para el despliegue del backend por su facilidad de configuración y su integración nativa con GitHub. La decisión de separar Supabase (auth + storage) de Railway (API + MySQL) fue deliberada: Supabase maneja el almacenamiento de evidencias con URLs firmadas de corta duración, añadiendo una capa de seguridad a los documentos de los clientes.

Implementación destacada

Flujo de solicitud digital

Cada solicitud genera un UUID único. El asesor de campo captura datos del cliente, fotografías de documentos (INE, comprobante de domicilio), y la geolocalización del punto de entrega. Toda la evidencia se almacena de forma inmutable en Supabase Storage con políticas de acceso por rol — solo el gerente y el área de cumplimiento pueden acceder a los documentos originales.

El formulario fue diseñado para condiciones reales de campo: conexión inestable, pantallas pequeñas, y usuarios no técnicos. Cada sección se guarda de forma incremental para no perder datos si la conexión se interrumpe a mitad de captura.

Verificación en campo

El módulo genera un enlace de acceso único (con expiración de 24 horas) para el verificador. Este confirma la visita con evidencia GPS timestamped. El sistema detecta si la ubicación del verificador difiere de la declarada por más de 200 metros — control antifraude que redujo las visitas falsas a cero en los primeros 30 días.

App móvil

Para asesores en campo desarrollé un MVP en React Native que funciona offline con sincronización cuando hay conexión. La sincronización usa una cola de eventos local que se procesa en orden al recuperar conectividad, garantizando que no se pierda ninguna solicitud iniciada sin internet.

Máquina de estados

Cada solicitud tiene un campo status con valores definidos como enum en Prisma. Las transiciones válidas están codificadas explícitamente — no puede pasar de verificacion_pendiente a desembolsado sin pasar por aprobado_gerencia. Esto hace el sistema completamente auditable y previene manipulación de estados por errores de UI.

Resultado / impacto

En 5 meses de operación: 691 solicitudes procesadas, cero papel, cero WhatsApp para operaciones internas. El tiempo promedio de aprobación bajó de 2 días a 4 horas. El área de cobranza redujo el tiempo de reconciliación de pagos de 3 días a menos de 1 hora gracias a los reportes automatizados.

Desafíos no planeados

El mayor desafío fue la adopción interna. Los asesores de mayor antigüedad resistían el cambio. La solución fue un dashboard que muestra el ranking de solicitudes procesadas por asesor en el mes — la gamificación simple aumentó la adopción más que cualquier capacitación formal.

Aprendizajes

El diseño de flujos de estados complejos requiere máquinas de estado explícitas, no simples columnas de status en la base de datos. La inversión en modelar bien el proceso antes de codificar redujo la cantidad de refactorizaciones a menos de la mitad de lo proyectado inicialmente. Un sistema de negocio bien mapeado se convierte en código predecible — sin ese mapa, cada nuevo requerimiento rompe algo.