Proof of Concept
Una construcción desechable que responde una pregunta: ¿es esto técnicamente posible? No es un producto, no es un MVP, no es algo que lances a usuarios.
Una prueba de concepto existe para eliminar un riesgo técnico específico. ¿Puede este modelo alcanzar la latencia que necesitamos? ¿Funcionará realmente esta integración contra el sistema heredado? ¿Podemos demostrar la criptografía antes de diseñar un producto a su alrededor? Un PoC responde «¿es esto posible?» y nada más. Se construye rápido, se juzga por si funciona y luego se desecha.
La distinción que más cuesta a las empresas es PoC frente a MVP frente a prototipo. Un PoC responde «¿es esto técnicamente posible?» y va dirigido a tu propio equipo. Un prototipo responde «¿se siente bien?» y va dirigido al diseño y la usabilidad, a menudo sin backend real alguno. Un MVP responde «¿alguien lo usará y pagará por ello?» y es un producto real, lanzado a usuarios reales, solo acotado a la versión más pequeña que valga su tiempo. Tienen audiencias distintas, listones de calidad distintos y definiciones de terminado distintas, y la diferencia se proyecta directamente sobre dónde estás respecto al PMF.
El error común y caro es lanzar un PoC como si fuera producción. El código que demostró que algo era posible se escribió para demostrar que algo era posible: sin manejo de errores, sin pruebas, sin revisión de seguridad, atajos por todas partes. Cuando la demo impresiona a alguien y se decide «simplemente lanzarlo», heredas todo eso como tu cimiento. El movimiento honesto es tratar el PoC como la respuesta a una pregunta y luego construir lo real correctamente.
Una forma de que esa disciplina aguante bajo presión: escribe la única pregunta que el PoC existe para responder antes de empezar, y los criterios de un sí o un no. «¿Puede este modelo clasificar tickets de soporte con un 90 % de exactitud sobre nuestros últimos 500 tickets?» es una pregunta con un veredicto claro. Sin esa pregunta escrita, un PoC muta calladamente en un medio-producto, el equipo lo sigue puliendo porque «casi funciona», y te has deslizado a construir V1 sobre cimientos desechables sin que nadie lo decidiera. La pregunta escrita es también lo que te protege del tirón del coste hundido de lanzar el código desechable: una vez respondida la pregunta, el PoC ha hecho su trabajo y se ha ganado su borrado, por bonita que se viera la demo.
Wavect hace un PoC cuando existe un riesgo técnico genuino que vale la pena eliminar antes de comprometerse con una construcción. La mayoría de los proyectos no necesitan uno; necesitan una fase de discovery que acote el trabajo. Te diremos cuál de los dos casos tienes.