Entregué el software de un concesionario de carros usados en Barranquilla cinco días antes de la fecha prometida, y lo logré quitando cosas, no agregándolas. Separé el proyecto de una plataforma más grande, borré campos que nadie en el negocio iba a mirar y le pedí a la IA el plan antes que el código. Este es el caso completo, con las tres decisiones que lo salvaron y lo que le pediría a cualquiera que esté por contratar algo parecido.
El problema: una plataforma más grande de lo que el cliente necesitaba
A finales de octubre tenía un compromiso con un concesionario de carros usados en Barranquilla: su sitio con catálogo, citas y panel de administración para el 20 de noviembre. Lo que llevaba construido no era eso. Era una plataforma pensada para manejar muchos concesionarios a la vez, más ambiciosa de lo que este cliente necesitaba y, por lo mismo, más lenta de terminar.
Ese es el error clásico cuando construyes software: confundir lo que podría servirle a todo el mundo con lo que le sirve a quien tienes en frente. Un concesionario pequeño no necesita una plataforma que soporte diez sucursales. Necesita la suya, funcionando, antes de la fecha.
Decisión 1: separar el proyecto en lugar de arrastrarlo
La primera decisión fue separar. Guardé la versión multi-concesionario en su propio repositorio, intacta, y empecé uno nuevo dedicado solo a este cliente.
No se perdió nada. La plataforma grande sigue ahí para cuando tenga sentido retomarla, y el proyecto del cliente dejó de cargar con complejidad que no iba a usar. Menos código que mantener significa menos cosas que se pueden romper y menos tiempo explicando por qué algo tarda.
Cuando alguien te vende un software “que hace de todo”, vale la pena preguntarte si ese “todo” es tuyo o es el catálogo de funciones del que lo vende.
Decisión 2: quitar los campos que nadie iba a mirar
La segunda decisión apareció probando el formulario de vehículos. Tenía campos de tipo, cilindraje y tracción. Al llenarlo como lo haría el dueño, desde el celular y carro por carro, vi algo claro: en ese negocio nadie mira esos datos para vender un usado.
Los quité de la pantalla y también de la base de datos. Esto último es lo que mucha gente deja a medias. Si escondes un campo pero lo dejas en la base, queda una columna sin uso que confunde al siguiente que lea el código y abre la puerta a errores. Borrarlo de verdad es parte del trabajo.
No los borré de la conversación con el cliente. Quedaron anotados en una lista de mejoras futuras que puede contratar el día que de verdad los necesite. Quitar una función no es cerrarse a ella, es no cobrártela hoy.
Decisión 3: pedirle a la IA el plan antes que el código
En este proyecto el código lo escribe un agente de IA y yo pruebo y decido cada paso. La tercera decisión fue sobre cómo usar esa herramienta sin que me pasara por encima.
Antes de reorganizar todo para aplicar el diseño aprobado, no le pedí al agente que lo hiciera. Le pedí solo el plan: qué archivo va dónde, qué componentes ya existen y en qué orden conviene hacerlo. En ese plan, escrito en texto plano, encontré un problema que en medio del código me habría costado horas: el horario de atención iba a quedar guardado en dos lugares, y el módulo de citas no habría sabido cuál de los dos usar. Se corrigió en un párrafo, antes de escribir una sola línea.
Leer el plan antes del código es la diferencia entre atrapar un problema cuando es una frase y atraparlo cuando ya son cincuenta archivos. Si quieres entender por qué la IA necesita a una persona revisando cada paso, lo cuento en detalle en por qué cada función de un software la prueba una persona.
El resultado: cinco días antes de la fecha
Las cifras son del proyecto:
| Hito | Fecha | Estado |
|---|---|---|
| Base de datos y acceso cerrados | 31 de octubre | Listo |
| Panel de vehículos con catálogo | 1 de noviembre | Listo |
| Fecha prometida al cliente | 20 de noviembre | Entregado antes |
El núcleo quedó cerrado el 1 de noviembre, cinco días antes de la fecha que había prometido, para un compromiso del 20. El margen no salió de trabajar más horas, salió de tener menos cosas que construir.
Qué preguntar antes de contratar el software de tu concesionario
Si estás por encargar el software de tu concesionario, estas preguntas te ahorran meses:
- ¿Esto que me vendes es para mi negocio o es una plantilla con cosas que no voy a usar? Un proyecto dedicado se moldea a tu forma de vender; una plantilla te obliga a adaptarte tú.
- ¿Qué pasa con las funciones que hoy no necesito? La respuesta correcta es “las dejamos anotadas y las contratas cuando quieras”, no “te las instalo ya por si acaso”.
- ¿Quién revisa lo que entrega la herramienta antes de que yo lo vea? Si nadie prueba carro por carro como lo harías tú, lo vas a descubrir con un cliente en frente.
- ¿Cuándo entra en producción y con qué margen? Una fecha sin margen es una fecha que se va a correr.
En SedeOps trabajamos con dos modelos para concesionarios: un sitio con catálogo y filtros sobre una base probada, y un software dedicado con panel, citas y las funciones que el cliente pida. En ambos casos la regla es la misma: entregar lo tuyo funcionando, no un catálogo de cosas por si acaso. Para el despliegue usamos Vercel, que genera una vista previa de cada cambio antes de que entre en producción, y evitamos cargar el proyecto con más de lo necesario, una idea cercana al producto mínimo viable de la gestión de producto.
¿Tienes un concesionario y quieres algo así?
Si manejas un concesionario y quieres un sitio o un software dedicado que entregue lo que de verdad usas, escríbenos por WhatsApp y te cuento cómo lo haríamos para tu caso. También puedes ver qué hacemos en SedeOps, leer cómo conectamos dominios en producción o contarnos tu caso.
Sobre el autor. Alexander García es fundador de SedeOps, agencia de desarrollo de software e inteligencia artificial en Barranquilla, Colombia. Puedes seguirlo en LinkedIn.
Escrito por Alexander García con apoyo de herramientas de IA, revisado y verificado por el autor.