Contexto
Vexa nació junto a una distribuidora real cuya operación dependía de registros en papel, archivos dispersos, cotizaciones en Excel y correo administrado manualmente. El conocimiento cotidiano vivía en una sola computadora y en la memoria de quienes hacían el trabajo.
La oportunidad era mayor que sustituir una hoja de cálculo: el sistema tenía que conservar la operación real y, al mismo tiempo, hacer cada transición lo bastante explícita para validarla, automatizarla y mejorarla.
El problema operativo
Clientes, cotizaciones, pedidos, inventario, entrega, facturación y seguimiento estaban separados. Esa fragmentación dificultaba la trazabilidad y obligaba a repetir información entre herramientas.
Las preguntas más difíciles eran operativas: cuándo una cotización se convierte en pedido, quién puede modificarla, qué debe validarse antes y qué registros posteriores deben actualizarse.
Actores y flujo
Vexa atiende administradores y usuarios operativos con paneles adaptados a permisos. Clientes, proveedores, productos e inventario forman el contexto compartido; cotizaciones, pedidos, logística y facturación forman la cadena principal.
El sistema sigue la operación desde la primera interacción con el cliente hasta el cumplimiento y los reportes, conservando roles y permisos en cada transición.
Solución
Ayudé a modelar el flujo completo como una plataforma modular para clientes, cotizaciones, pedidos, productos, inventario, proveedores, facturación, correo, reportes financieros, punto de venta, logística, usuarios, roles y permisos. El sistema actual incluye una integración implementada con procesos del SAT.
La base actual reconoce tenants para que la implementación validada pueda evolucionar hacia un SaaS configurable sin tratar a cada negocio futuro como una copia idéntica.
Flujo del producto
- Buscar o registrar un cliente.
- Crear una cotización con productos y precios.
- Convertir la cotización aceptada en pedido.
- Coordinar inventario y logística.
- Continuar hacia facturación, reportes y seguimiento.
- Mostrar a cada rol únicamente la información y acciones permitidas.
Arquitectura
La plataforma utiliza Next.js y TypeScript para la interfaz y capacidades de servidor; PostgreSQL, Supabase y Prisma sostienen los datos relacionales. Cloudflare R2 almacena archivos y Vitest apoya la verificación automatizada.
La arquitectura prioriza módulos de negocio y flujos explícitos. El aislamiento por tenant, el acceso por roles y la propiedad de archivos son preocupaciones del sistema, no adornos de la interfaz.
Decisiones técnicas clave
- Representar transiciones operativas como estados validados, no como formularios aislados.
- Mantener permisos cerca de los flujos que protegen y adaptar el panel al rol actual.
- Usar modelado relacional para dependencias comerciales, de inventario y financieras.
- Preparar límites por tenant antes de ampliar el sistema validado como SaaS.
- Auditar consultas y consumo del cliente después de que la primera versión completa reveló patrones de rendimiento.
Mi contribución
Dirigí el desarrollo técnico e implementé aproximadamente 70% del sistema. Traducí procesos reales del cliente a flujos de software, diseñé la arquitectura, coordiné tareas y trabajé en backend, frontend y base de datos.
El trabajo se realizó con una colaboradora. No construí el sistema solo y este caso no incluye información operativa privada del cliente.
Desafío principal
El problema más difícil no fue un framework o una API. Fue convertir una operación informal en estados, permisos, validaciones e interacciones explícitas sin perder el conocimiento práctico que hacía funcionar el negocio.
Resultado y estado actual
Vexa es un sistema operativo validado que sirve como base de un producto configurable. Centraliza la operación que la primera versión buscó modelar; el código permanece privado porque es trabajo comercial.
No se presenta una métrica de eficiencia sin verificar. La evidencia principal es un flujo completo y trazable validado contra una operación real.
Lo que aprendí
Vexa fue mi primer sistema dirigido de forma independiente con intención directa de producción. Me mostró la diferencia entre trabajo para un cliente y trabajo académico, la importancia del descubrimiento y la necesidad de revisar temprano consultas y consumo de APIs.
Qué cambiaría
Definiría antes los patrones de consulta, los límites de servicios internos y presupuestos de rendimiento. La auditoría posterior mejoró consultas, APIs y consumo en cliente; esa disciplina debería comenzar con la arquitectura.
Roadmap
La siguiente etapa es una base SaaS configurable para distribuidoras y negocios comerciales que todavía dependen de procesos manuales fragmentados.
Galería de interfaz
La galería final requiere capturas sanitizadas del dashboard, cliente, cotización, pedido, inventario, reportes, logística y permisos. El sitio reserva sus proporciones sin presentar pantallas inventadas como evidencia.
Recorrido de la demo
La demo grabada presenta el producto en funcionamiento y complementa este caso con evidencia directa de su experiencia operativa. Antes de publicarla de forma definitiva se debe confirmar que todos los datos visibles estén sanitizados y que exista autorización del cliente.
Código y privacidad
El código es privado porque el proyecto evoluciona como producto comercial. Los recursos futuros deberán usar datos de demostración y contar con autorización del cliente antes de publicar la interfaz.