ENGAGEMENT

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.

Última revisión: 2026-06-02 porKevin Riedl wiki ↗

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.

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.

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.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Un PoC responde si algo es técnicamente posible y es para tu propio equipo; se desecha. Un MVP responde si alguien usará y pagará por el producto y se lanza a usuarios reales. Confundir ambos es como los equipos acaban lanzando código desechable como su cimiento de producción.
No debería. El código de un PoC se escribe para demostrar que una cosa funciona, sin manejo de errores, pruebas ni seguridad. Lanzarlo como producción significa heredar todos esos atajos como tu cimiento. Usa el PoC para tomar la decisión y luego construye lo real correctamente sobre una base limpia.
Solo cuando existe un riesgo técnico real que conviene eliminar primero: una integración no probada, un objetivo de rendimiento exigente, una afirmación criptográfica o algorítmica novedosa. Si el riesgo es de producto o de mercado en lugar de técnico, quieres una fase de discovery o un MVP, no un PoC.