Cuándo no construir software

Buena parte de las solicitudes que recibimos empiezan igual: alguien describe un sistema que quiere que construyamos. Rara vez empiezan describiendo un problema. La diferencia importa más de lo que parece, porque un sistema mal elegido cuesta lo mismo que uno bien elegido y no resuelve nada.

La pregunta que hacemos primero

¿Qué pasa hoy, exactamente, cuando ese sistema no existe? Quién lo hace a mano, cuántas veces por semana, cuánto tarda, y qué cuesta cuando sale mal. Si nadie sabe responder eso, no hay un problema medido: hay una intuición. Y las intuiciones son caras de programar.

A veces la respuesta revela que el proceso lo ejecuta una persona quince minutos al mes. Ahí no hay software que justificar. Otras veces revela que tres personas dedican dos días completos a copiar datos entre dos sistemas que ya existen — y eso se resuelve con una integración, no con una plataforma nueva.

Las tres señales de que sí

Primero: el trabajo es repetitivo y tiene reglas claras. Si puedes escribir las reglas, se pueden programar. Segundo: el volumen crece y la única forma de absorberlo hoy es contratar. Tercero: el error tiene costo — plata perdida, clientes que se van, sanciones. Cuando aparecen las tres, construir es la decisión barata.

Decir que no también es servicio

Hemos rechazado proyectos donde lo honesto era decir que una hoja de cálculo compartida bastaba. Perdimos la facturación y ganamos algo mejor: ese cliente volvió después con el problema real, el que sí valía la pena resolver. Un proveedor que te vende siempre no está diagnosticando.