Resumen Ejecutivo
HIXION cotizó $148K por 8 módulos en 16 semanas. En 26+ semanas de desarrollo, el scope original quedó al 62-78% de completitud. Durante el proceso se descubrieron 7 funcionalidades esenciales para el negocio (CxC, CxP, Saldos, Slots, etc.) que no eran previsibles desde la propuesta. Se absorbieron 54 adiciones de scope sin proceso formal de change request. El cliente percibe la plataforma como “no lista” porque 10 bugs en funcionalidad core pesan más que todo lo construido.
No hay contrato firmado (solo propuesta PDF verbal). Sí hay NDA firmada. No hay definición escrita de “Done.”
Timeline: Prometido vs Real
Inicio del proyecto
Propuesta Roibotic (ahora HIXION). $148K + IVA, 16 semanas, 8 módulos. Acuerdo verbal sin contrato.
5 sesiones de avance (R1–R5)
54 adiciones de scope absorbidas sin objeción. Se descubre que el negocio es 5-8x más complejo que la propuesta. Fórmulas financieras corregidas en R4 (noviembre). Se construyen CxC, CxP, Saldos como necesidad emergente.
Vacaciones HIXION (16 días)
Pausa completa del desarrollo.
Fin planeado (semana 16)
No completado. Múltiples módulos parciales. Migración de datos no construida. DEVELOPMENT_MODE aún activo.
Reunión de “entrega”
Abel reporta 68 items. 30+ action items generados. De los 68 items, solo 12 (17.6%) son scope original pendiente. 23 (33.8%) son requests nuevos.
Hypercare informal
Fixes reactivos sin protocolo formal. Migración de datos ejecutada (parcial). Esquemas de pago refinados. Nuevo desarrollador (Vlad variable).
+2 meses de la fecha planeada
17 bugs críticos reportados por Abel. 5 corregidos (Codex + Cursor). 9 ambigüedades de negocio bloqueantes. Sesión de Discovery pendiente con Abel.
Historial de Sesiones — Timeline Detallado
Análisis sesión por sesión de 9 reuniones entre septiembre 2025 y febrero 2026. Por cada sesión: reglas de negocio definidas por Abel, scope absorbido por HIXION, citas textuales, mutaciones detectadas y procesos fantasma descubiertos.
Propuesta Inicial
Abel Salazar · Ángel Cadena · Luis
- IVA obligatorio: “Tiene que ser a fuerza con IVA”
- Control diario manual en Excel de mantenimientos e ingresos por vehículo
- Costos diferenciados: reparaciones vs ingresos por renta
- Módulo financiero para flujo de efectivo (no estaba en propuesta original como tal)
- Tracking de gastos de mantenimiento integrado
— Abel sobre su proceso actual con Excel
1ª Sesión de Avances — Gestión de Flotillas
Abel · Armando (hermano) · Ángel · Vladimir · Luis
- Número de motor obligatorio en registro de vehículos: “Tiene que ser a huevo”
- Documentos digitales siempre disponibles “en caso de que se ocupe”
- Relaciones de datos cruzadas entre módulos (conductores ↔ vehículos ↔ socios)
- Panel de control GPS con acceso por credenciales
- Sistema de asignación conductor ↔ vehículo
- Estructura de cortes semanales
2ª Sesión de Avances — Revisión de Funcionalidades
Abel · Armando · Santiago · Ángel · Vladimir · Luis
- Monto fijo obligatorio en esquema de pago; porcentaje como opcional
- Historial de cambios debe guardarse siempre
- Mantenimientos registrables desde múltiples rutas (sección mantenimiento O gastos de unidad)
— Abel admitiendo que no probó la plataforma entre sesiones
3ª Sesión — Sistema Financiero
Abel · Santiago · Ángel · Vladimir
- Ganancias de Uber se extraen directo del CSV, no se calculan manualmente
- Diferenciación entre ganancias de plataforma vs pagos directos
- Lógica de reembolsos implementada
— Abel sobre por qué no confía en ningún sistema automático
- Integración directa de ganancias Uber desde CSV
- Lógica de reembolsos
4ª Sesión — Mantenimiento y Gastos
Abel · Santiago · Ángel · Vladimir · Luis
- TODAS las salidas de efectivo deben asignarse a un fondo o centro de costos
- Cuentas separadas obligatorias: banco vs efectivo
- Modelo de fondo de inversión: egresos atribuidos a inversionistas, “no pueden quedar volando”
— Abel comparando la plataforma vs su proceso manual (fricción UX)
- Abel pide consolidar revisión + pago + registro en UNA sola vista en lugar de módulos separados
5ª Sesión — Reportes y Detalles
Abel · Santiago · Ángel · Vladimir · Luis
- Conductor asignado debe aparecer en revisión semanal
- Doble baja obligatoria (dual entry)
- Gastos extras atribuidos a persona específica: “a quién le estoy pagando estos gastos extras”
- CxC y CxP emergen como necesidad — Abel gestiona 86+ cuentas de cobro
- Costos de accidentes compartidos con flexibilidad por caso
- Centros de costos necesarios para atribución de gastos
6ª Sesión — Pre-Entrega
Abel · Armando · Ángel · Vladimir
- Cuentas separadas obligatorias: banco y efectivo
- Deudas se deducen de la cuenta correspondiente
- Jerarquía de cuentas: empresa → sub-cuentas por socio → fondos
— Abel expresando frustración crítica sobre la dirección del proyecto
- Cargos adicionales por transacción
- Comisión automática de plataforma (3% para vehículos sourced)
- CxC y CxP vinculados a cuentas reales
Reunión de Retroalimentación y Entrega
Abel · Vladimir
- Alertas de mantenimiento: amarillo 30 días, rojo 7 días antes de vencimiento
- Umbrales de kilometraje: amarillo 58,500 km, rojo 8,000 km
- Reparaciones/multas deducibles del corte semanal del socio
- Si corte semanal insuficiente → crear cuenta por cobrar automáticamente
- Renta vs otros cargos (multas, mantenimiento) como líneas separadas
- Comisión 3% automática para income sourced por plataforma
- Vista default: últimos 15 días, scroll hacia atrás en bloques de 15
- Máx 50 registros por página, preferencia de PDF para reportes
- Sistema de alertas por kilometraje
- Upload múltiple de fotos por mantenimiento
- Tracking de proveedores por gasto
- Módulo de multas con búsqueda por municipio
- Cálculos automáticos de flujo en ventana de 15 días
- Corrección de transacciones erróneas
- Gestión de CxC con indicadores de estatus
- Modal detalle de CxP por socio con filtro de fechas
Checkpoint — Validación Final
Abel · Armando · Ángel · Vladimir · Luis
- “Semana” = semana del AÑO, no del mes. Discrepancia en cálculos de corte que sesiones anteriores no capturaron.
- Múltiples datos que “parecen equivocados” según Abel
— Abel sobre discrepancias de datos en la plataforma
- Asignación batch de conductores
- Status en tiempo real (activo/inactivo)
- Búsqueda multi-criterio (unidad, placas, conductor, socio)
- Orden alfabético en CxC
Patrón detectado en las 9 sesiones
A pesar del desarrollo de la plataforma, Abel continúa 7 procesos manuales en paralelo (verificación de ganancias, reconciliación Excel, tracking de deudas, categorización de gastos, routing de pagos, checkout multi-paso, distribución de reportes). Esto indica desconfianza fundamental en la precisión del sistema — no resistencia al cambio.
Cada sesión reveló procesos que Abel ya hacía manualmente, no features nuevas que inventara. El sistema necesita reemplazar estos procesos fantasma para lograr adopción real.
La cita que resume todo
— Abel Salazar, Sesión 3 — La razón por la que no adopta ningún sistema automático
Mientras Abel no confíe en que los números de la plataforma son 100% correctos, seguirá con su Excel en paralelo. Los bugs de integridad contable (BUG-17, BUG-07/12) refuerzan esta desconfianza.
Scope Original — 56 Features Cotizadas
M1: Autenticación y Configuración
62.5%M2: Dashboard Ejecutivo — $28K
68.8%M3: Procesamiento Financiero Core — $35K
80%M4: Gestión Operativa de Flotilla — $22K
87.5%M5: Administración de Socios — $25K
83.3%M6: Sistema de Alertas — $20K
44.4%M7: Gestión de Inventario — $12K
~70%M8: Migración de Datos Históricos — $6K
10%Funcionalidad Emergente del Negocio
Estas 7 funcionalidades no eran previsibles desde la propuesta. Se descubrieron durante el desarrollo al entender cómo opera realmente el negocio de Abel. No son scope creep — son componentes esenciales sin los cuales la plataforma no funcionaría para su operación real.
| # | Funcionalidad | LOC | Por qué es esencial |
|---|---|---|---|
| 1 | Cuentas por Cobrar (CxC) | ~4,000 | Abel gestiona 86+ cuentas activas, 190+ deudas individuales con 10% interés semanal |
| 2 | Cuentas por Pagar (CxP) | ~1,500 | Espejo de CxC para deudas con proveedores y socios |
| 3 | Saldos / Cuentas Bancarias | ~3,500 | Abel maneja 4+ cuentas (Efectivo, Banorte, BBVA, Hey Banco). Sin esto, el flujo de efectivo no tiene sentido |
| 4 | Sistema de Slots | ~400 | 98+ vehículos requieren control físico de estacionamiento |
| 5 | Fondo Siniestro por Socio | ~500 | Optimización de siniestros: pago seguro > costo reparación = utilidad para el socio |
| 6 | Catálogo de Vehículos | ~800 | Marcas, modelos, años necesarios para fichas técnicas |
| 7 | Pagos No Asignados | ~500 | Detección de depósitos que no corresponden a ningún corte |
| Total | ~11,200 |
— Abel Salazar, sesión de avance
La lección
Cuando el negocio real es un fondo de inversión disfrazado de flotilla, ningún discovery de 2 sesiones lo va a capturar completo. Estas funcionalidades emergieron porque se necesitaban para que la plataforma sirviera — no porque Abel las pidiera como “extras.”
68 Items de Abel — Clasificados
El dato clave
Solo el 17.6% del feedback de Abel corresponde a scope original pendiente. El 33.8% son requests completamente nuevos que nunca estuvieron en la propuesta. Sin embargo, Abel percibe TODO como “cosas que faltan” porque nunca se le comunicó qué estaba dentro y fuera del scope.
Esto no es culpa de Abel — es una falla de comunicación de HIXION. Sin contrato firmado, no hay documento al que referir para separar scope de requests nuevos.
Los 12 items de scope pendiente (responsabilidad HIXION)
- Vista admin de flujo de efectivo (completitud ~85%)
- Dashboard filtrado por socio
- Diseño de reporte de corte por socio
- Workflow completo de cierre de corte
- Sync corte → flujo de efectivo
- Desglose de flujo por concepto (renta vs multas)
- CRUD de vehículos (bug al agregar)
- Error crítico de BD al guardar movimientos
- Refresh de asignación de conductor
- Bug de búsqueda en CxC
- Desactivar DEVELOPMENT_MODE
- Módulo de migración de datos (cotizado $6K, 90% pendiente)
Gap de Complejidad: Propuesta vs Realidad
El patrón subyacente
La propuesta asumió un negocio de renta de autos. La realidad es un fondo de inversión micro-financiero con flotilla como activo subyacente. La complejidad real es 5-8x mayor que lo estimado. Esto no es culpa de Abel ni de HIXION — es un descubrimiento legítimo que requirió iteraciones para entender.
Conclusiones y Plan de Acción
Lo que HIXION hizo bien
- Construyó funcionalidad emergente esencial (CxC, CxP, Saldos) sin escalar costos
- Motor de cálculos de cortes funcional y verificado en producción
- Absorbió complejidad 5-8x mayor sin renegociar precio
- Módulo financiero core al 80% — el más robusto de todos
Lo que HIXION hizo mal
- Nunca dijo “no” a adiciones de scope (52 de 54 aceptadas sin objeción)
- No firmó contrato — todo basado en acuerdo verbal y PDF de propuesta
- Equipo no entendió el negocio antes de construir (discovery insuficiente)
- DEVELOPMENT_MODE = true en un sistema financiero con datos reales
- 0 tests en 100K+ líneas de código financiero
- Migración de datos cotizada ($6K) y apenas construida (10%)
- Nunca comunicó al cliente qué era “extra” vs “scope”
- Bugs en funcionalidad core al momento de “entrega”
- No había proceso formal de change request
Plan de Acción Inmediato
- Sesión de Discovery con Abel — Usar el Discovery Session Framework. Entender los 12 procesos reales paso a paso.
- Clasificar TODOS los hallazgos con la Matriz (BUG / GAP / MUTACIÓN / FANTASMA / MEJORA)
- Completar los 12 items de scope original pendientes (sin costo adicional)
- Corregir los 10+7 bugs críticos (sin costo, hypercare)
- Definir “Done” por escrito y acordarlo con Abel
- Crear contratos operativos para cada proceso crítico (reglas confirmadas por ambas partes)
- Evaluar los 23 requests nuevos como posible Fase 2 (cotizar por separado)
— Angel Cadena, CEO HIXION — Abril 2026
Lección para HIXION
El problema no fue técnico. El problema fue de traducción de negocio. Para futuros proyectos:
- Contrato firmado con definición de scope, proceso de change request, y criterios de aceptación
- Discovery profundo antes de cotizar — no confiar solo en sesiones de avance
- Comunicar cada extra que se construya fuera del scope original
- Decir “no” o “eso es Fase 2” cuando una adición excede el scope
- Tests desde el día 1 en cualquier sistema financiero
- Nunca entregar con DEVELOPMENT_MODE activo