Manuel Uicab

El problema

Una empresa automotriz gestionaba sus líneas de crédito para agencias de forma manual y fragmentada. El proceso involucraba múltiples actores — operadores, representantes legales, asesores, administrativos y validadores — sin un sistema centralizado que controlara los estados, validara las reglas de negocio ni garantizara la trazabilidad del proceso completo.

Lo que construí

Desarrollé el frontend de un sistema integral de gestión de créditos que unifica todo el flujo — desde la requisición inicial hasta la firma digital del contrato. Cuatro decisiones técnicas definieron el proyecto:

Control de estados y actores — Diseñé un sistema de permisos y estados que determina qué puede ver y hacer cada actor en cada momento del proceso. Un operador de agencia nunca ve lo que ve un validador interno, y viceversa. El flujo no avanza si los estados no están resueltos correctamente.

Reglas de negocio diferenciadas — Las lógicas de validación, aprobación y generación de solicitudes son distintas para créditos de unidades nuevas, seminuevas y refinanciamientos. Cada tipo tiene su propio conjunto de reglas implementadas de forma que el sistema las aplica automáticamente según el contexto.

Firma digital con servicio externo — La firma ocurre en el portal del proveedor externo. De nuestro lado implementé la generación y regeneración de documentos, el envío al servicio, la recepción de documentos firmados vía webhooks y la asignación automática al crédito correspondiente.

Integración con CRM — El sistema está conectado en todo momento al CRM de la empresa, sincronizando información de agencias, líneas de crédito y estados de las solicitudes.

El resultado

Un proceso que antes era manual, propenso a errores y sin trazabilidad, se convirtió en un flujo digital controlado de extremo a extremo — con validaciones automáticas, auditoría de estados y firma legal integrada.

El problema

Una empresa necesitaba digitalizar su proceso de subastas de activos — vehículos, inmuebles y bienes varios — en una sola plataforma que sirviera a audiencias completamente distintas: el equipo administrativo que gestiona los activos y los participantes externos que pujan en las subastas.

Lo que construí

Desarrollé el frontend de un sistema multi-audiencia que unifica la landing pública, el panel administrativo y el portal de participantes bajo una misma base. Dos decisiones técnicas definieron el proyecto:

Gestión de audiencias — En lugar de construir aplicaciones separadas, implementé un sistema de sesión con tipado de usuario y validadores que determina qué portal renderizar según el rol. Simple por dentro, invisible para el usuario.

UI de alta complejidad con estado compartido — La vista principal de subastas fue el reto más exigente: un layout de dos columnas donde la columna izquierda muestra una tabla de activos con un control en el footer para cambiar entre subastas activas — reemplazando el contenido completo de la tabla — y la columna derecha muestra el detalle del activo seleccionado. Ese detalle es completamente dinámico: su estructura cambia según si el activo es un vehículo, un inmueble o un bien general. Diseñé la arquitectura de componentes para que el estado compartido entre columnas fuera predecible y el cambio de tipo de activo no generara inconsistencias visuales ni de datos.

El resultado

Un sistema que unifica dos audiencias con necesidades opuestas en una sola plataforma, con una interfaz administrativa capaz de manejar múltiples tipos de activos y subastas simultáneas sin perder coherencia visual ni funcional.

El problema

La versión existente del sistema de gestión de tareas presentaba problemas que afectaban tanto la experiencia del usuario como el mantenimiento del código. Las interfaces eran lentas — páginas que mostraban la misma información realizaban consultas individuales por cada presentación en lugar de una consulta global. La navegación estaba mal distribuida y la experiencia no resistía la comparativa con herramientas similares del mercado. Retroalimentación de clientes potenciales y usuarios internos confirmó lo que el código ya mostraba: era necesario reconstruir, no parchear.

Lo que estoy construyendo

Tras un proceso de diagnóstico con el área de diseño — que incluyó sesiones de retroalimentación, uso interno y análisis comparativo con aplicaciones similares — se tomó la decisión de hacer un rediseño completo: nueva interfaz, nueva navegación y nueva arquitectura.

En el lado técnico experimenté con múltiples enfoques antes de tomar una decisión. Evalué arquitecturas desde las más simples hasta Atomic Design y Clean Architecture. El resultado fue una arquitectura propia — una mezcla de Screaming Architecture y Vertical Slices — centrada en features como unidad principal de organización. Cada feature es autónoma, coherente y fácil de localizar. Los principios SOLID, DRY y YAGNI guían cada decisión de implementación.

Esta misma arquitectura se convirtió en el estándar interno de la empresa para proyectos React — la diseño y mantengo, y hoy la adopta todo el equipo frontend.

Estado actual

En desarrollo activo. Estimado de lanzamiento: 2 meses. El proceso de construcción — incluyendo las decisiones de arquitectura, los experimentos descartados y los aprendizajes — será documentado como contenido técnico en el blog.