SISTEMA OPERATIVO DE BAMPE360

Vender, ejecutar, facturar, cobrar. Un expediente, un historial.

BAMPE360 gestiona proyectos de reforma integral. Llega un lead, se convierte en presupuesto, el presupuesto se convierte en expediente, el expediente se factura bajo la normativa fiscal española, y alguien reclama el cobro. Nada de eso es inusual. Lo inusual es hacerlo con un equipo de una a cinco personas no técnicas, repartidas entre dos contextos muy distintos: personal de oficina que necesita datos densos y precisos en un escritorio, y un jefe de obra subido a una escalera con el móvil, registrando una foto y siguiendo adelante.

Las herramientas genéricas de CRM más facturación resuelven las piezas. No resuelven lo que realmente importa a esta escala: cada pieza tiene que apuntar al mismo expediente, con un historial que nadie puede editar en silencio, y la numeración fiscal nunca puede tener un hueco. Eso último no es una preferencia. Es la ley.

• Problema de negocio: la empresa no podía gestionar su ciclo completo a través de un sistema conectado con historial de auditoría
• Problema de usuario: dos personas muy distintas necesitan los mismos datos en formas completamente diferentes
• Problema de producto: los sistemas que resolverían esto están construidos para una escala y una sofisticación técnica que este equipo no tiene

Qué lo hizo difícil

• La corrección fiscal no es negociable. Las series de facturas deben ser correlativas y sin huecos bajo escrutinio regulatorio real (VeriFactu, AEAT). Una decisión de arquitectura equivocada aquí no es un bug, es un incumplimiento normativo
• Dos personas, un solo sistema. Escritorio primero para la oficina y móvil primero para el equipo de obra no es una nota a pie de página responsive. Cambia qué datos son densos y cuáles son un resumen, y qué cuenta como un buen valor por defecto
• Usuarios no técnicos, consecuencias reales. Cada acción irreversible (borrar un cliente, anular una factura) necesitaba una confirmación que una persona no técnica realmente entiende, no un modal que repite la etiqueta del botón
• Sin sistema previo y sin base de usuarios que entrevistar sobre la marcha. La especificación tenía que validarse contra el dominio, la ley fiscal española y los flujos de trabajo de la construcción, antes de que fuera seguro diseñar una sola pantalla
• Todo tenía que quedar configurable. Flujos de estado, plantillas de documentos, formatos de numeración, campos personalizados: todo en la base de datos y editable desde el producto, para que un cambio de flujo de trabajo nunca tuviera que esperar a un desarrollador

Lo que asumí, y lo que no

Asumí el producto de principio a fin: planteamiento del problema, modelo de dominio, arquitectura de información, el sistema de diseño extraído de la marca ya existente de la empresa, la jerarquía de cada pantalla, y el listón de calidad que el trabajo tenía que superar antes de entregarse. El código lo escribió ingeniería asistida por IA (Claude Code) bajo esa dirección. Cada decisión de arquitectura, producto y diseño fue mía, y revisé y filtré el resultado contra un marco de calidad que escribí antes de que empezara el proyecto: ponderado entre UX, UI, arquitectura, accesibilidad, rendimiento y seguridad, nada se entregaba por debajo de 95 sobre 100, con accesibilidad y seguridad exigidas al 100.

Lo digo así de claro porque es la forma real del rol. Saber dirigir la ejecución de IA hacia un producto bien arquitectado, accesible y seguro en vez de una demo rápida es la habilidad que se demuestra aquí, no algo que esconder detrás de un "trabajamos juntos".

• Asumí: el modelo de dominio (qué es un Expediente y por qué todo cuelga de él), el sistema de diseño, la jerarquía de información de cada pantalla, las decisiones sobre numeración fiscal y confianza en la IA, y el visto bueno o no de cada puerta de calidad
• La IA ejecutó bajo mi dirección: la implementación, las refactorizaciones, y los scripts de verificación que demostraban que cada puerta se superaba
• No hubo equipo humano de producto ni de ingeniería. Eso convierte la historia de colaboración en algo más inusual que "funcionó bien con el equipo de ingeniería"

Una factura nace sin número. Solo lo recibe cuando se emite.

Por qué: la normativa fiscal española exige que la serie de facturas sea correlativa y sin huecos. Si el número se asignara al crear el borrador, cada borrador cancelado quemaría un número y rompería esa correlatividad.

Contrapartida: los borradores siguen siendo totalmente editables y cancelables, pero en el momento en que una factura se emite queda bloqueada. Nada de anulaciones, solo una factura rectificativa formal más adelante. Menos flexibilidad tras la emisión, a cambio de una garantía que no se puede saltar por accidente.

Resultado: la secuencia de numeración es atómica y sin huecos incluso bajo emisión concurrente. El único caso límite legítimo, un hueco real por un fallo grave del proceso, queda registrado como su propio evento auditable en vez de desaparecer en silencio.

El copiloto solo propone. Nunca ejecuta, y nunca ve más de lo necesario.

Por qué: es un equipo pequeño y no técnico que maneja el dinero y los datos personales de otras personas. Un agente autónomo que se equivoca de vez en cuando es un pasivo. Un copiloto que se equivoca de vez en cuando y siempre es revisable es una funcionalidad.

Contrapartida: cada sugerencia de IA, una alerta de riesgo o un borrador de correo de seguimiento, necesita un clic humano para volverse real. Es un copiloto más lento y menos mágico de lo técnicamente posible.

Resultado: los correos de clientes, los NIF y los números de teléfono nunca salen del servidor hacia el proveedor de IA. Solo salen nombres y roles. Cada invocación queda en la misma línea de auditoría que una acción humana, con coste y duración asociados. El copiloto puede equivocarse sin que la confianza en el resto del sistema se vea afectada.

Una tabla de entidades con roles, no tablas separadas de cliente, proveedor y subcontrata

Por qué: en este negocio la misma empresa es a menudo cliente en un expediente y subcontrata en otro. Tablas separadas significan registros duplicados, o un cambio de esquema cada vez que aparece un rol nuevo.

Contrapartida: más lógica de validación vive en la capa de aplicación en vez de estar impuesta por la estructura de la tabla. Un coste real, aceptado de forma deliberada.

Resultado: una sola entidad puede tener varios roles sin duplicación, y eso fue lo que hizo posible "configuración antes que código" desde el principio. Los campos personalizados extienden el modelo sin una migración. Una decisión estructural, no una preferencia de modelado de datos.

La pantalla de inicio responde "qué me necesita hoy"

No es un panel de gráficos. Es una respuesta ordenada por urgencia. Un administrador ve las tareas atrasadas y una incidencia crítica antes que nada, y el texto dice qué pasó y dónde, no solo que pasó algo. Debajo, el siguiente paso que el negocio debería dar, y una lista de progreso para un equipo que nunca había tenido un sistema como este.

El CRM previo es deliberadamente delgado. Su único trabajo es llevar una oportunidad hasta un presupuesto. Todo lo que viene después vive en el objeto que de verdad importa.

Un objeto en el centro: el Expediente

Todo apunta de vuelta a un único registro de expediente. El CRM, el presupuesto, la factura, la incidencia, la foto de la visita a obra. La máquina de estados en el medio no es decorativa: una transición que no es válida para la plantilla de ese expediente no se puede disparar, ni desde la interfaz ni desde la capa de servicio de debajo.

El bloque económico muestra facturado, margen real, porcentaje ejecutado y cobro pendiente. La alerta "margen real por debajo de lo previsto" saca a la luz el único número que de verdad quita el sueño en un negocio de reformas.

El editor de presupuestos: versionado, por secciones, bloqueado al aceptarse

La pantalla más compleja del producto, a propósito. Margen calculado en vivo línea a línea, secciones para organizar el alcance, historial de versiones completo, y un bloqueo total en el momento en que se acepta una versión. Se ve exactamente qué se prometió al cliente, de forma permanente. Aceptar un presupuesto crea el expediente automáticamente, así que el traspaso de ventas a ejecución no tiene ningún paso manual que se pueda olvidar.

Studio: si es un dato de negocio, no vive en el código

La identidad fiscal de la empresa, su propia credencial de IA (validada, guardada cifrada, nunca vuelta a mostrar), usuarios, roles, plantillas de flujo de trabajo, plantillas de documentos, formatos de numeración y reglas de automatización viven todos aquí, editables sin un despliegue. El propio subtítulo de la pantalla es el principio: la configuración prevalece sobre el código.

El mismo espacio de trabajo, al alcance del pulgar

El perfil de jefe de obra no es una nota a pie de página de un media query. El espacio de trabajo que muestra KPIs y una máquina de estados en escritorio se colapsa a una sola columna en el móvil, con el estado del expediente y las alertas justo arriba, porque ahí es donde de verdad se usa.

Lo que costó de verdad "terminarlo"

La hoja de ruta presupuestaba diez fases de dos a seis sesiones de trabajo cada una. Esa estimación asumía que el cuello de botella era el tiempo de implementación. Con ejecución de IA no lo fue: las fases cero a nueve se entregaron en dos días y la empresa empezó a gestionar expedientes reales con ello. Así que el plan cambió. En vez de una secuencia lenta y cautelosa, concentrar la velocidad en una V1 completa, y luego dedicar una pasada aparte y específica a encontrar lo que la velocidad se había saltado. Esa pasada ocurrió tres semanas después. No fue un pulido, fue el plan.

Un sistema construido rápido por una sola persona dando dirección no tiene un segundo par de ojos natural, y la autorrevisión se le escapa de forma fiable lo que una pasada adversarial sí detecta. Así que la auditoría se ejecutó como tres lentes independientes, accesibilidad y diseño, seguridad, rendimiento y calidad, cada una calificando el trabajo como si fuera de otra persona. Ese es el patrón de colaboración real de este proyecto: no consenso, sino verificación adversarial antes de dar nada por terminado.

Dos hallazgos cambiaron cómo pienso los arreglos. La pantalla más lenta, cobros, ya usaba la optimización obvia; el problema no era cómo cargaba sino cuánto. Cargaba los datos de las seis pestañas en cada petición para que las insignias pudieran mostrar contadores. Desacoplar lo barato (un contador) de lo caro (filas completas) fue el arreglo. Y a una tabla de datos primitiva compartida le faltaba un nombre accesible, copiado en 56 pantallas. Eso no eran 56 problemas. Era un problema duplicado 56 veces, arreglado una vez, en la primitiva.

• Encontrado y cerrado antes de cualquier usuario externo: una fuga de datos cross-tenant en vivo en la línea de tiempo de actividad, varias brechas IDOR donde un ID adivinado llegaba al objeto de otro tenant, un bug de año de factura calculado en UTC en vez de la hora de Madrid, y una condición de carrera en la numeración de facturas
• Un historial de migraciones desincronizado entre desarrollo y producción, reconciliado sin una sola operación destructiva
• Null-safety estricta activada en todo el código de producción, con 387 arreglos reales, cada uno una guarda en vez de un error silenciado
• Cinco archivos de servicio de 1.700 a 1.800 líneas descompuestos en módulos enfocados, con un diff de exportación que tenía que volver vacío para contar como terminado
• Una puerta de lint de CI que llevaba en rojo en silencio, puesta en verde. Una puerta rota antes de tus tests significa que los tests posteriores nunca se ejecutaron de verdad

Medido, cualitativo, y lo que no voy a afirmar

Medido: las diez fases planificadas se entregaron en dos días frente a una hoja de ruta de 35 a 45 sesiones. 56 de 56 tablas de datos cumplen los criterios de nombre accesible de WCAG, arregladas en la primitiva. Cero brechas conocidas de cross-tenant o IDOR tras la revisión de seguridad. 347 tests automatizados y una puerta completa (typecheck, typecheck estricto, lint, lint de diseño, build) exigida antes de que cualquier cambio se entregue.

Cualitativo: el producto es el sistema operativo real de BAMPE360 para gestionar expedientes, en uso diario, no un piloto. El fundador no tuvo que elegir entre "lanzar algo usable ya" y "construirlo bien", porque el enfoque de dos fases entregó ambas cosas sin fingir que eran la misma fase.

Lo que no voy a afirmar: no hay una línea base con la que medir (sin sistema previo, sin test A/B, sin embudo de adopción) y ningún artefacto de investigación de usuarios que valide la división en dos perfiles más allá del conocimiento directo del equipo que lo usa. Eso es un hueco real, no un redondeo.

Rápido y riguroso no estaban en tensión. Eran dos fases.

El instinto inicial era que ir rápido y construir con rigor tiraban en direcciones contrarias, y el arreglo fue dejar de tratarlos como una sola fase. Una V1 completa en dos días solo se sostuvo porque el refuerzo estaba presupuestado, era adversarial, y tenía su propio listón que superar.

La decisión de numeración fiscal es la prueba más clara de que esto no se construyó a base de intuición. Equivocarse en la correlatividad no es un ticket de bug, es un incumplimiento normativo. Esa es exactamente el tipo de restricción que obliga a entender el dominio en vez de aplicar el patrón genérico de un flujo de facturación cualquiera.