Prueba de concepto vs prototipo: ¿qué construir primero?

Una prueba de concepto, un prototipo y un MVP responden tres preguntas distintas. Paga por construir el equivocado y pasarás semanas demostrando algo que ya sabías.

Un fundador llegó a nosotros el año pasado con un presupuesto firmado para un “prototipo” de su app de logística: cuarenta mil dólares, una versión clicable de cada pantalla. Lo que de verdad le quitaba el sueño era si la app podría traer datos en vivo de tres transportistas cuyos sistemas nadie en su empresa había tocado. Esa no es una pregunta de prototipo. Estaba a punto de pagar para descubrir que sus pantallas se veían bien, mientras lo único capaz de matar la empresa seguía sin probarse.

Esa es toda la trampa de prueba de concepto vs prototipo. Una prueba de concepto responde una pregunta: ¿esto se puede construir de verdad? Un prototipo responde otra: ¿esto tiene sentido para quien lo va a usar? Un MVP responde una tercera: ¿alguien va a pagar por esto? Tres artefactos, tres riesgos, y no son tres tamaños de la misma cosa. El verdadero trabajo del fundador es gastar dinero solo en la pregunta que todavía no sabe responder. Si sabes que la parte técnica es trivial, una prueba de concepto es un desperdicio. Si sabes que la gente lo quiere y sabes que se puede construir, sáltate las dos y construye la cosa.

Aquí tienes cómo distinguirlas, y cómo decidir a dónde debe ir tu dinero primero.

Qué prueba de verdad una prueba de concepto

Una prueba de concepto es un experimento desechable que verifica si un riesgo técnico específico tiene solución. No el producto entero. La única parte que te pone nervioso.

La verdadera prueba de concepto del fundador de logística eran dos semanas de un ingeniero intentando autenticarse contra esas tres APIs de transportistas y normalizar los datos en un solo feed. Un script feo, sin interfaz, sin pantalla de login, nada que un cliente vería jamás. La salida era un sí o un no. Volvió como “sí para dos de ellas, y la tercera exige un plan enterprise de pago”. Esa respuesta valió más que la versión clicable de cuarenta mil dólares, porque cambió el modelo de precios del negocio entero antes de que se escribiera una línea de producto real.

Una prueba de concepto es la elección correcta cuando tu mayor incógnita es una frase que empieza con “podemos siquiera”. Podemos siquiera integrarnos con el sistema de historiales de ese hospital. Podemos siquiera correr este algoritmo de emparejamiento lo bastante rápido para que se sienta instantáneo. Podemos siquiera hacer que un modelo de IA extraiga los campos correctos de un PDF desordenado de forma fiable. Cuando el riesgo es la viabilidad técnica, nada más de lo que construyas importa hasta que esa pregunta tenga respuesta, porque un producto precioso encima de una integración imposible es solo una forma cara de aprender que la integración era imposible.

Lo que una prueba de concepto no es: no es la primera versión de tu producto. La tiras. Reutilizar el código de una prueba de concepto como cimiento es uno de los errores más caros que vemos, porque ese código se escribió para responder una pregunta rápido, no para que un equipo lo mantenga durante tres años.

Qué prueba de verdad un prototipo

Un prototipo verifica si la cosa tiene sentido antes de que alguien la construya en serio. El riesgo que retira no es “esto se puede construir”, sino “esta es la forma correcta para quien lo usa”.

La mayoría de los prototipos no son código en absoluto. Son pantallas clicables, hechas en una herramienta de diseño, que dejan a un usuario real recorrer un flujo y confundirse frente a ti. El valor está entero en presenciar esa confusión mientras cambiar una pantalla todavía cuesta una tarde en vez de un sprint. Si alguna vez te sentaste detrás de alguien usando tu producto y sentiste que se te caía el estómago cuando pasó de largo el botón del que estabas orgulloso, entiendes para qué sirve un prototipo. Mueve esa caída de estómago de después del lanzamiento a antes de que pagaras por construir.

Los prototipos vienen en fidelidades, y la palabra se usa para todas ellas, lo que es parte de la confusión. Un boceto en papel es un prototipo. Un wireframe de cajas grises es un prototipo. Un mockup perfecto y clicable, con la cara exacta de la app terminada, es un prototipo. Están en un espectro que va de “tosco lo justo para probar el flujo” a “pulido lo justo para probar la sensación”, y los más pulidos empiezan a mezclarse con el trabajo de diseño que harías de todos modos. Escribimos sobre dónde cae esa línea en nuestro texto sobre wireframe frente a mockup; en resumen, un wireframe prueba la fontanería y un mockup prueba la pintura.

Un prototipo es la elección correcta cuando tu mayor incógnita es sobre personas, no sobre máquinas. Si entienden el flujo. Si confían lo bastante para meter la tarjeta. Si el onboarding tiene sentido para alguien que no eres tú. Cuando la tecnología es aburrida y trillada pero la experiencia no está probada, ese es el trabajo de un prototipo.

Dónde entra el MVP, y por qué los tres se confunden

La tercera palabra a la que recurren los fundadores es MVP, y pertenece a esta conversación porque responde el riesgo que las otras dos no tocan: el mercado va a pagar de verdad.

Una prueba de concepto demuestra que se puede construir. Un prototipo demuestra que tiene sentido. Ninguno de los dos demuestra que alguien lo quiere lo suficiente para abrir la cartera. Ese es el trabajo del producto mínimo viable, y es el riesgo que el trabajo de customer development de Steve Blank pone en el centro de todo: un MVP tiene que ser software real, funcionando, usado por clientes reales con dinero real o datos reales en juego. Un prototipo clicable no valida la demanda, porque nadie se juega nada al recorrer una demo. Ya argumentamos que la mayoría de las cosas que los fundadores llaman MVP son demasiado pequeñas para probar nada en nuestro análisis del producto mínimo viable, y esa pregunta de demanda es exactamente lo que un esfuerzo de validación de mercado se construyó para responder.

Los tres se confunden porque pueden solaparse en una sola construcción, y porque los proveedores tienen incentivos para mantener las palabras vagas. Si el mismo experimento de dos semanas demuestra que la integración funciona y se le muestra a tres clientes que dicen “yo pagaría por eso”, hizo el trabajo de una prueba de concepto y de una validación improvisada a la vez. Está bien. El objetivo no es correr tres proyectos separados en una secuencia rígida. El objetivo es saber qué riesgo está comprando de verdad cada hora de gasto, para que no pagues a un diseñador por pulir pantallas cuando tu problema real es una base de datos que no sabes si existe.

Prueba de concepto vs prototipo: ¿qué va primero?

La respuesta honesta: el que ataque tu mayor incógnita. No hay un orden universal, y cualquier proveedor que te dé uno sin preguntar por tu riesgo está vendiendo un proceso, no pensando en tu empresa.

Dicho eso, hay un valor por defecto útil. Cuando un proyecto carga riesgo técnico real, la prueba de concepto va primero, porque no tiene sentido probar si a los usuarios les encanta un flujo que no se puede construir. La viabilidad es la puerta de todo. Cuando la tecnología es corriente (otro CRUD, otro marketplace, otro dashboard) y el riesgo vive entero en si la gente lo va a usar y pagar, puedes saltarte la prueba de concepto y empezar por un prototipo, y luego ir directo a un MVP.

El fallo que más vemos son fundadores corriendo el orden al revés por entusiasmo. El prototipo es la parte divertida. Es visual, se comparte, hace que la idea se sienta real, y se lo puedes enseñar a tu pareja. Así que los fundadores gastan en el prototipo primero, se enamoran de él, y solo descubren el problema de viabilidad meses después, cuando un ingeniero por fin intenta construir la parte difícil. Para entonces hay un diseño precioso al que todos están apegados y un muro técnico que nadie revisó. Ordena tu gasto por riesgo, no por lo que es satisfactorio de mirar.

La prueba de una pregunta para decidir en qué pagar

Aquí está el método que recorremos con los fundadores. Toma unos cinco minutos y es solo una pregunta, hecha con honestidad.

Escribe la única cosa con más probabilidad de matar este proyecto. No una lista. Una frase. Luego mira con qué palabra empieza.

• Si empieza con “podemos construir”: eso es riesgo técnico. Paga por una prueba de concepto.
• Si empieza con “la gente va a entender, confiar o usar”: eso es riesgo de diseño. Paga por un prototipo.
• Si empieza con “alguien va a pagar, existe el mercado”: eso es riesgo de mercado. Paga por un MVP, o por una validación más barata antes de construir nada.
• Si no puedes escribir una frase con honestidad, todavía no tienes una decisión de gasto. Tienes que pensar.

La disciplina está en negarse a gastar en un riesgo que ya retiraste. Si ya te integraste con ese proveedor de pagos en tres proyectos anteriores, “podemos construir los pagos” no es tu riesgo, y una prueba de concepto para eso es teatro. Si diez clientes ya te lo están rogando y le pagan a competidores por una versión peor, “alguien va a pagar” está respondido, y correr una validación larga es procrastinación vestida de rigor.

La regla práctica: construye una prueba de concepto solo cuando tu mayor riesgo sea “esto se puede construir”, un prototipo solo cuando sea “lo van a usar”, y si ya sabes las dos respuestas, deja de probar y construye la cosa de verdad. Eric Ries resumió bien el objetivo de fondo en El método Lean Startup: “La única manera de ganar es aprender más rápido que cualquier otro.” Cada uno de estos artefactos es solo una forma de comprar barato una pieza específica de aprendizaje. Si no está comprando un aprendizaje que aún no tienes, no es barato. Es una factura.

¿Puede un prototipo ser una prueba de concepto?

A veces, y aquí es donde las palabras se solapan de verdad. Un prototipo puede servir de prueba de concepto cuando la parte arriesgada es la interacción misma, no la fontanería detrás de ella.

Digamos que tu apuesta es una forma radicalmente más simple de registrar un gasto, un gesto en vez de un formulario. Construir una versión funcional de ese gesto y ponerla frente a usuarios prueba tanto la viabilidad (“podemos hacer que esta interacción funcione con fluidez”) como el deseo (“la gente de verdad lo prefiere”). Un artefacto, dos riesgos retirados. Pero lo inverso rara vez se cumple: una prueba de concepto casi nunca es un prototipo, porque una POC suele ser un script sin cabeza, sin interfaz para que nadie reaccione. Prueba que el motor arranca. No dice nada sobre si alguien quiere conducir el coche.

La trampa es suponer que el solapamiento siempre existe. La mayoría de las veces no. La mayoría de los riesgos técnicos viven en el backend, invisibles, y la mayoría de los riesgos de usabilidad viven en el frontend, y probar uno no te dice nada del otro. Supón que son separados hasta que puedas explicar con claridad por qué, en tu caso específico, son lo mismo.

Cuánto debe costarte cada uno, en semanas y no en features

Los fundadores preguntan cuánto cuesta esto, y la respuesta útil está en tiempo y alcance, no en una cifra de dinero, porque la cifra de dinero es solo el tiempo multiplicado por una tarifa que puedes consultar en nuestro análisis de cuánto cuesta de verdad una aplicación.

Una prueba de concepto debe ser pequeña y rápida: de días a dos o tres semanas, un ingeniero, una pregunta. Si alguien te cotiza dos meses por una prueba de concepto, o está probando demasiadas cosas a la vez o está construyendo tu producto a escondidas y llamándolo POC. Rebate. Una prueba de concepto que toma dos meses dejó de ser una prueba de concepto.

Un prototipo escala con la fidelidad. Un flujo clicable tosco para probar un solo recorrido son unos días de diseño. Un mockup pulido de la app entera son varias semanas, y en ese punto deberías preguntarte si estás prototipando o simplemente haciendo la fase de diseño de la construcción real antes de tiempo, lo cual suele estar bien mientras sepas que es eso lo que estás pagando.

Un MVP es el caro, porque es software de verdad, y su costo es una conversación entera aparte. El error es dejar que un MVP se disfrace de prototipo en una cotización, o que un prototipo se disfrace de MVP. Cuando el número se siente demasiado grande para la palabra, la palabra suele estar equivocada.

El error que quema más dinero

El error más caro es el que el fundador de logística casi comete: pagar por retirar el riesgo que no tienes mientras ignoras el que sí tienes. Un prototipo precioso de una app cuya integración central resulta ser imposible. Una prueba de concepto sólida para un producto técnicamente difícil que en realidad nadie quiere. Un MVP completo construido antes de que alguien verificara si la parte difícil se podía construir.

La razón de que esto pase siempre es que el riesgo divertido y el riesgo real suelen ser riesgos distintos. El divertido es visual y se comparte. El real a menudo es aburrido, enterrado en un backend, o sentado en una pregunta incómoda sobre si a los clientes les importa. Los proveedores, comprensiblemente, prefieren venderte el divertido. Tu defensa es la prueba de una pregunta y la disposición a gastar tu primer dólar en la incógnita que de verdad te asusta, incluso cuando es la parte menos fotogénica de toda la idea. Esa es la diferencia entre un socio y una caja negra: un socio pregunta qué riesgo estás retirando antes de cotizarte, y te aparta de la respuesta cara-pero-satisfactoria cuando está equivocada.

Preguntas frecuentes

¿Cuál es la diferencia entre una prueba de concepto y un prototipo?
Una prueba de concepto verifica si algo se puede construir (viabilidad técnica). Un prototipo verifica si tiene sentido usarlo (diseño y usabilidad). Una POC suele ser un script desechable sin interfaz; un prototipo suele ser pantallas clicables sin backend funcionando. Retiran riesgos distintos y rara vez son intercambiables.

¿Qué va primero, una prueba de concepto o un prototipo?
El que ataque tu mayor incógnita. Por defecto, cuando el proyecto tiene riesgo técnico real, la prueba de concepto va primero, porque no tiene sentido probar si a los usuarios les gusta un flujo que no se puede construir. Cuando la tecnología es corriente y el riesgo está todo en la adopción, puedes saltarte la POC y empezar por un prototipo.

¿Cuál es un ejemplo de prueba de concepto?
Un experimento de dos semanas donde un ingeniero escribe un script feo para verificar si tu app puede autenticarse contra tres sistemas externos y unir sus datos en un solo feed. Sin login, sin diseño, sin producto. La salida es un sí o no sobre la única pregunta técnica que podría matar el proyecto.

¿Puede un prototipo ser una prueba de concepto?
Sí, cuando la parte arriesgada es la interacción misma y no el backend. Construir y probar un gesto nuevo demuestra a la vez que funciona y que la gente lo quiere. Pero una prueba de concepto casi nunca es un prototipo, porque la mayoría de las POC no tienen interfaz para que nadie reaccione.

¿Dónde encaja un MVP frente a una POC y un prototipo?
Un MVP es software real, funcionando, usado por clientes reales, y responde el riesgo de mercado que los otros dos no tocan: si alguien va a pagar. Una prueba de concepto demuestra que se puede construir; un prototipo demuestra que tiene sentido; un MVP demuestra que el negocio funciona. La mayoría de lo que los fundadores llaman MVP es en realidad un prototipo o una primera versión reducida.