DEV Community: Jorge Garzón

Dos años después: una empresa familiar de servicio técnico de lavado de coches con su propio ERP y agentes de IA hechos con Claude Code

Jorge Garzón — Fri, 09 Oct 2026 18:42:50 +0000

Somos una empresa familiar pequeña, de segunda generación. Reparamos y mantenemos equipos de lavado de coches (puentes, túneles, boxes de lanzas) para dos de los grandes fabricantes y para clientes propios. Unos pocos técnicos de campo, una oficina y yo llevándolo. Aquí nadie es programador.

(Versión en inglés: https://dev.to/satgarzon/two-years-in-a-family-car-wash-service-company-running-its-own-erp-and-ai-agents-built-with-claude-89a)

Qué hemos construido

Un ERP propio, en producción, que sustituye al programa comercial que usamos durante años. Lleva avisos, partes de trabajo desde el móvil de los técnicos, presupuestos, pedidos, facturas de proveedor, banco, variables de nómina y, desde este mes, la facturación electrónica que se está haciendo obligatoria en España. Las facturas van firmadas y encadenadas; una vez emitida, la propia base de datos impide tocarla.
Un sistema de agentes con Claude Code y un servidor MCP. Leen el buzón, crean avisos a partir de los correos de los fabricantes, cuadran lo que el fabricante aprueba con nuestros partes, preparan pedidos a proveedores y redactan correos (nunca los envían).
Una biblioteca técnica y un «perito» al que los técnicos pueden preguntar. Los manuales y despieces de los fabricantes más nuestro propio historial de averías y arreglos, indexados y enlazados a cada modelo de máquina. Un técnico pregunta desde el móvil «este modelo hace X» y recibe las causas probables, lo que hicimos la última vez en esa misma máquina y la página del manual. Cada respuesta se puede marcar como buena o mala, y las correcciones vuelven a la biblioteca.
Aprobación humana por Telegram. Todo lo que tiene consecuencias (crear un documento, cambiar un precio, mandar algo) me llega al móvil con dos botones. Cada decisión queda registrada: quién, cuándo y resultado.
Un segundo modelo, de otra empresa, que revisa lo que hace el primero y avisa cuando no está de acuerdo.
Una base de procedimientos escritos, unos 1.500, que los agentes tienen que consultar antes de poder escribir nada. Lo obliga la herramienta: sin procedimiento leído, no hay escritura.
Modelos locales en una máquina nuestra para lo barato y repetitivo: leer y clasificar documentos, los índices de la biblioteca, una primera pasada de revisión de código. El criterio se queda en Claude.
Copias de seguridad cuatro veces al día, cifradas, en tres sitios, y cada pocas semanas las restauramos en una máquina limpia para comprobar que sirven.

Qué ha funcionado

Escribir los procedimientos. No para la IA, para nosotros; la IA solo hizo que mereciera la pena. Cada vez que algo salió mal se convirtió en una regla con fecha y motivo, y los agentes leen esas reglas.
El bucle de aprobación. Temía que fuera un cuello de botella y es lo contrario: reviso veinte decisiones al día desde el móvil en unos minutos y nunca pasa nada que me sorprenda.
Producción y pruebas en copias separadas con bases de datos separadas. La única vez que compilamos directamente en producción, un error de sintaxis tiró el sistema un minuto con los técnicos en la calle. Nunca más.
Pruebas automáticas del dinero: numeración por serie, IVA, redondeo al céntimo, comparadas con el SQL real en cientos de documentos al azar.

Qué no funcionó y qué cambiamos

Al principio los agentes actuaban y me lo contaban después. Perdimos un día con una tanda de partes «aprobados» con precios equivocados. Ahora nada que toque dinero se mueve sin un clic humano.
Las sesiones largas. Lo medimos: una sesión de trabajo releía cientos de miles de tokens en cada paso porque arrastraba toda la conversación. Pasamos a una sesión por tema con una nota de traspaso corta, y el mismo trabajo cuesta una fracción.
Dejar que la IA «recuerde» cosas en el chat. Si no está escrito en un procedimiento o un fichero, al día siguiente no existe.
Los modelos locales fuera de su carril. Valen para encargos pequeños y bien especificados; descarrilan con cualquier cosa de más de una página, y darles más contexto los empeora. Los usamos para lo mecánico y nada más.
Lo que aún no teníamos resuelto: hasta esta semana las pruebas del dinero no se ejecutaban solas antes de cada cambio, y no teníamos pruebas de anulaciones, reintentos ni de la cadena firmada. Las añadimos hace unos días; son nuevas y les falta recorrido.

Lecciones para dueños que no programan

El ingeniero de sistemas eres tú. El modelo escribe; tú decides qué significa «correcto» y tienes que saber ver cuándo se equivoca.
Que la IA lea antes de escribir. Procedimientos, documentación por módulo, «qué cambió y por qué». Y que sea obligatorio, no una sugerencia.
Separar «proponer» de «hacer». Todo lo que toca dinero, clientes o producción pasa por una persona.
Copias de seguridad, y restaurarlas. Una copia que nunca has restaurado es una esperanza.
Cuenta con que el mantenimiento es tuyo. Si un cambio rompe algo y diez intentos no lo arreglan, tienes que entender lo suficiente para encontrar el problema.

Una pregunta para vosotros

Los que tenéis lógica de facturación o contabilidad hecha así: ¿cómo la probáis? ¿Tenéis pruebas automáticas de numeración, redondeos y anulaciones, o lo comprobáis a mano? ¿Y cada cuánto restauráis de verdad una copia de seguridad?

Escrito con ayuda del mismo asistente, revisado y corregido por mí.

Two years in: a family car-wash service company running its own ERP and AI agents built with Claude Code

Jorge Garzón — Fri, 09 Oct 2026 18:41:02 +0000

We are a small family business in Spain, second generation. We service and repair car-wash equipment (gantries, tunnels, jet-wash bays) for two of the big manufacturers and for our own customers. A handful of field technicians, one office, and me running it. Nobody here is a programmer.

What we built

Our own ERP, in production, replacing the commercial package we used for years. It handles service calls, work reports from the technicians' phones, quotes, purchase orders, supplier invoices, bank reconciliation, payroll inputs and, since this month, the electronic invoicing regime that is becoming mandatory in Spain. Invoices are signed and chained; once issued, the database itself refuses to let anyone change them.
A set of agents built on Claude Code and an MCP server. They read the mailbox, create service calls from manufacturer emails, draft replies, reconcile what the manufacturer approved against our work reports, prepare supplier orders, and prepare (never send) emails.
A technical library and an "expert" the technicians can ask. The manufacturers' manuals and parts diagrams, plus our own history of faults and fixes, indexed and linked to each machine model. A technician can ask from the phone "this model does X" and get the likely causes, what we did last time on that same machine, and the page of the manual. Every answer can be marked right or wrong, and the corrections go back into the library.
Human approval by Telegram. Anything with consequences (creating a document, changing a price, sending something) shows up on my phone with two buttons. Every decision is logged: who, when, result.
A second model, from a different company, that reviews what the first one did and flags disagreements.
A base of written procedures, about 1,500 of them, that the agents must consult before they are allowed to write anything. The tooling enforces it: no procedure read, no write.
Local models on our own hardware for the cheap, repetitive parts: reading and classifying documents, embeddings for the library, a first pass at reviewing code. Judgement stays with Claude.
Backups four times a day, encrypted, to three places, and we actually restore them to a clean machine every few weeks to prove they work.

What worked

Writing the procedures down. Not for the AI, for us. The AI just made it worth doing. Every time something went wrong it became a rule with a date and a reason, and the agents read those rules.
The approval loop. I was afraid it would be a bottleneck. It is the opposite: I review twenty decisions a day from the phone in a few minutes, and nothing surprising ever happens.
Keeping production and testing in separate copies with separate databases. The one time we built straight on production, a syntax error took the system down for a minute while technicians were on the road. Never again.
Tests for the money logic: numbering per series, VAT, rounding to the cent, checked against the real SQL on hundreds of random documents.

What did not work, and what we changed

Our first approach let the agents act and tell me afterwards. We lost a day to a batch of work reports that were "approved" with the wrong prices. Now nothing with money moves without a human click.
Long sessions. We measured it: one working session re-read hundreds of thousands of tokens on every step because it kept the whole conversation. We switched to one session per topic, with a short hand-over note, and the same work now costs a fraction.
Letting the AI "remember" things in chat. If it is not written in a procedure or a file, it does not exist the next day.
Local models beyond their lane. Fine for small, well-specified jobs; they derail on anything longer than a page, and giving them more context makes them worse, not better. We keep them for the mechanical work, and nothing else.
The thing we still have not fixed: until this week our money tests did not run automatically before every change, and we had no tests for cancellations, retries or the signed chain. We added them a few days ago; they are brand new and need mileage.

Lessons for owners who are not programmers

You are the systems engineer. The model writes; you decide what "correct" means, and you have to be able to tell when it is wrong.
Make the AI read before it writes. Procedures, module docs, "what changed and why". Then make it mandatory, not polite.
Separate "propose" from "do". Everything that touches money, customers or production goes through a human.
Back up, and restore. A backup you have never restored is a hope.
Expect to be the one maintaining it. If a change breaks something and ten prompts do not fix it, you need to understand enough to find the problem.

A question for you

For those of you running invoicing or accounting logic you built this way: how do you test it? Do you have automated tests for numbering, rounding and cancellations, or do you rely on checking by hand? And how often do you actually restore a backup?

Written with help from the same assistant, reviewed and edited by me.