Glosario
Qué es un prototipo
Sirve para decidir algo y luego se tira. En cuanto alguien depende de él, deja de ser un prototipo.
Un prototipo es una versión de prueba de un producto, construida para responder una pregunta concreta y pensada para tirarse después.
La frontera con lo demás no tiene que ver con el acabado: un prototipo no tiene a nadie que responda. Nadie está de guardia, nadie ha decidido cuánto puede estar caído, nadie recibe un aviso si deja de funcionar. Un prototipo con datos reales y con clientes entrando sigue siendo un prototipo mientras nadie haya decidido quién lo arregla y en cuánto tiempo cuando falla.
El problema es el día en que deja de serlo sin que nadie lo declare. Empieza con un acceso dado a un cliente para que pruebe y termina con una operación entera funcionando sobre algo que se escribió para tirarse.
Cuándo importa
Importa cuando el prototipo empieza a guardar datos que no se pueden perder. Ahí cambia la naturaleza de lo que tienes, aunque el código sea el mismo. Un prototipo que guarda facturas emitidas ya no admite la respuesta «lo rehacemos si falla», porque hay una obligación detrás.
Las herramientas de generación de código han hecho esta transición mucho más frecuente: se llega antes a algo que funciona, y funciona lo suficiente para enseñárselo a alguien que paga. Sobre ese momento va la nota vibe coding y el primer cliente, y el término está en vibe coding.
Qué hay que decidir para dejar de tenerlo
Cuatro preguntas, y ninguna es técnica del todo. Qué datos no se pueden perder. Qué parte mueve dinero y por tanto tiene que comprobarse sola. Quién se entera cuando algo falla, y por qué vía. Qué pasa si la persona que lo escribió no está disponible esa semana.
Un prototipo puede tener las cuatro sin responder. Un sistema en producción no. Convertir lo uno en lo otro es de prototipo a producción: decidir qué se conserva, qué se aísla y qué se sustituye, en ese orden.
Un prototipo bien usado ahorra dinero
Construir uno para responder una pregunta cara cuesta poco y evita decidir a ciegas. La condición es que la pregunta esté escrita antes de empezar y que haya una fecha para tirarlo.
Nosotros los usamos así en la primera semana del diagnóstico, cuando hay una duda que no se resuelve discutiendo. Se monta algo pequeño, se mira el resultado y se descarta. Lo que queda es la decisión.
Ver también
¿La duda es sobre tu propio sistema?
El diagnóstico la responde con el código delante: qué falla, cuánto cuesta arreglarlo y por dónde entrar.