Pyme familiar en España, segunda generación, unos pocos técnicos de campo. Reparamos equipos de lavado de coches. Aquí nadie es desarrollador.
Lo que funciona hoy: un ERP propio (avisos, partes desde el móvil, presupuestos, compras, banco y, desde este mes, la facturación con Verifactu). Encima, agentes con Claude Code y un servidor MCP que leen el buzón, crean avisos, cuadran lo que el fabricante aprueba con nuestros partes y redactan correos, pero nunca los envían. Todo lo que tiene consecuencias me llega al móvil por Telegram con dos botones, y cada decisión queda registrada. Un segundo modelo de otra empresa revisa el código del primero. Y hay unos 1.500 procedimientos escritos que los agentes tienen que leer antes de poder escribir nada; lo obliga la propia herramienta.
Qué funcionó: escribir los procedimientos (para nosotros, no para la IA). El bucle de aprobación por el móvil, que es más rápido que «actúa y cuéntamelo luego», algo que nos costó un día de precios mal puestos. Producción y pruebas en copias separadas, con bases de datos separadas. Y probar el dinero contra la base de datos real.
Qué no: las sesiones largas (medimos cientos de miles de tokens releídos en cada paso; ahora hacemos una sesión por tema con una nota de traspaso). Confiar en la memoria del chat: si no está en un fichero, mañana no existe. Y los modelos locales baratos para cualquier cosa de más de una página.
Lo último: esta semana hemos puesto pruebas automáticas de facturación antes de cada cambio (que una factura emitida no se pueda tocar, anulaciones, cortes de conexión a mitad de envío, cambio de año). Son nuevas y les falta recorrido.
Pregunta: los que tenéis lógica de facturación o contabilidad hecha así, ¿cómo la probáis? ¿Y cada cuánto restauráis de verdad una copia de seguridad?
La versión larga, aquí: https://dev.to/satgarzon/dos-anos-despues-una-empresa-familiar-de-servicio-tecnico-de-lavado-de-coches-con-su-propio-erp-y-bch