De Excel a una plataforma en producción: el caso real de Disrover
Caso real: cómo Disrover SpA pasó de operar en Excel a una plataforma en producción con Laravel y Filament. Stack técnico, decisiones y resultados.

Este post documenta un proyecto real en producción. No es teoría ni opinión: es el caso de una empresa que pasó de operar en Excel a una plataforma web que hoy se usa todos los días para vender, cobrar y gestionar inventario.
El problema que había que resolver
Disrover creció. El volumen de ventas aumentó. Los vendedores necesitaban registrar ventas en terreno. Los administradores necesitaban reconciliar pagos, gestionar inventario y generar reportes. Todo esto se hacía en Excel.
Excel funciona para operaciones pequeñas. Pero cuando tienes múltiples vendedores, cientos de clientes y miles de transacciones mensuales, Excel se vuelve un cuello de botella. Los errores se multiplican. La información se desactualiza. No hay trazabilidad real.
La solución no era agregar más hojas de cálculo. Era construir una plataforma que reemplazara Excel completamente.
El problema ya no era eficiencia: era control, trazabilidad y riesgo operativo.
La solución: una plataforma web
Construí Disrover como una plataforma web completa. Los vendedores usan sus teléfonos como punto de venta móvil. Los administradores gestionan inventario, ventas, pagos y reportes desde cualquier navegador.

La plataforma maneja todo el ciclo: desde la creación de productos hasta el registro de ventas, el seguimiento de pagos, la gestión de inventario y la reconciliación de caja. Todo integrado. Todo trazable.
Stack técnico
El stack fue elegido para maximizar claridad, velocidad de entrega y mantenibilidad, no para optimizar currículum ni tendencias.
- Backend: Laravel 12.x, PHP 8.2+ con strict typing, MySQL 8.0+
- Admin Panel: Filament 3.3+ (CRUD completo, widgets, formularios)
- Frontend: Laravel Blade, Tailwind CSS, Alpine.js, Livewire
- Infraestructura: Laravel Forge (deploy automático), DigitalOcean (VPS), Redis (cache y sesiones)
- Almacenamiento: AWS S3 (logos, avatares, documentos)
- Testing: Pest (TDD), PHPUnit, PHPStan Level 5, Laravel Pint
- Documentos: DomPDF (facturas, boletas, guías), Laravel Excel (exportaciones)
Todas las decisiones técnicas fueron validadas con el uso real. No hay tecnología por tecnología.
Arquitectura y calidad
El proyecto sigue principios de Clean Architecture y TDD:
- Repository Pattern para abstracción de datos (código nuevo)
- Service Layer para lógica de negocio compleja
- Policy-based authorization con permisos granulares por rol
- Validación multi-capa: UI, backend, modelos y políticas
- Strict typing en código nuevo (PHP 8.2+ con declare(strict_types=1))
- Testing con Pest: 279 tests pasando, cobertura alta en módulos críticos
- PHPStan Level 5 para análisis estático
- Activity logging completo para auditoría
El código legacy (MVP inicial) usa patrones más simples. El código nuevo sigue estándares más estrictos. Esta evolución es intencional: primero resolver el problema, luego mejorar la estructura.
Ejecución
El desarrollo inició en abril de 2025. El MVP estaba en uso en junio de 2025, aproximadamente dos meses después. Desde entonces, la plataforma ha evolucionado según los requerimientos reales de uso.
No construí todo de una vez. Construí lo esencial primero: productos, ventas, pagos básicos. Luego agregué lo que realmente se necesitaba: reportes, reconciliación de caja, metas y comisiones.
El objetivo no era 'construir una plataforma', sino reemplazar Excel sin frenar la operación diaria.
Este enfoque permitió validar la solución rápidamente y ajustar según feedback real, no según supuestos.
Decisiones técnicas
Por qué no app móvil inicialmente
Los vendedores usan la plataforma web en sus teléfonos. Funciona bien porque está optimizada para móvil. Una app nativa podría ser útil más adelante, pero primero necesitaba validar que la solución funcionaba. Una app nativa es posible para 2026, dependiendo del presupuesto y la necesidad real.
Por qué no microservicios
Microservicios agregarían complejidad sin beneficio real para este caso. La aplicación es monolítica por diseño: más simple de mantener, más fácil de desplegar, más rápido de desarrollar. Cuando la complejidad lo justifique, se puede refactorizar. Pero no antes.
Por qué no BI pesado
La plataforma tiene reportes básicos que cubren las necesidades actuales. No construí un sistema de BI complejo porque no se necesita todavía. Cuando se necesite, se puede agregar. Construir lo que no se necesita es desperdicio.
Uso real
La plataforma está en uso diario:
- 6 vendedores registrando ventas en terreno
- 2 administradores gestionando inventario, pagos y reportes
- 1 sysadmin monitoreando la infraestructura
- 554 clientes registrados en el sistema
- Uso intensivo de lunes a viernes, menor uso los fines de semana

Estos números no son proyecciones. Son uso real, medido mes a mes.
Lo que la plataforma hace
La plataforma cubre todo el ciclo operativo:
- Gestión de productos: categorías, precios múltiples (normal, mayorista, especial, RAPEL), control de stock global y por vendedor
- Ventas: registro con documentos (facturas, boletas), folios automáticos, validación de stock en tiempo real, restricciones por tiempo y rol
- Pagos: múltiples métodos (efectivo, cheque, transferencia, crédito), pagos parciales, seguimiento de saldos pendientes
- Inventario: stock por vendedor y sucursal, transacciones atómicas con locking, registro de mermas
- Compras: gestión de proveedores, recepción de mercadería, pagos a proveedores
- Metas y comisiones: metas individuales por vendedor y producto, cálculo automático mensual (2% base + bonos variables), tracking en tiempo real, sistema de notificaciones
- Reportes: reconciliación de caja, análisis de ventas, exportación a Excel multi-hoja, generación de PDFs profesionales
- Dashboard: 8 widgets con métricas clave, filtros por período y vendedor, personalización por rol


Resultados
Excel ya no es el sistema principal. La plataforma web lo reemplazó completamente. Los vendedores registran ventas en tiempo real desde sus teléfonos. Los administradores tienen visibilidad completa del inventario, pagos y reportes. Las comisiones se calculan automáticamente cada mes. La operación pasó de reactiva a predecible.
La plataforma maneja períodos operativos específicos (26 del mes actual al 25 del siguiente), calcula IVA 19% automáticamente, genera documentos PDF profesionales y exporta datos a Excel con formato empresarial.
No construí esto para demostrar tecnología. Lo construí para resolver un problema real. Y funciona todos los días.
El modelo de soporte es claro: correcciones de bugs están incluidas. Nuevo alcance se factura por separado. Esto mantiene el proyecto sostenible y evita scope creep.
Si estás en Excel y tu operación ya creció
Si tu operación sigue dependiendo de Excel y el volumen ya no lo soporta, podemos evaluarlo con criterio técnico y de negocio. No todos los casos necesitan software a medida, pero cuando Excel se convierte en riesgo, postergar la decisión suele salir más caro.
Disrover es un ejemplo concreto de cómo se hace. Puedes conocer más sobre la plataforma en disrover.com. Si te interesa explorar algo similar para tu operación, puedes contactarme por WhatsApp.
Visitar disrover.comConoce más sobre la plataforma Disrover y sus características principales
Contactar para una conversación inicialAbre WhatsApp para agendar una llamada de discovery y evaluar si tu caso se beneficia de una solución similar