Prueba de concepto: la guía del founder no técnico para entender la PoC

Un founder que estábamos conociendo recibió un presupuesto de 35.000 dólares por una PoC. El alcance decía “validar la viabilidad técnica de la plataforma”. Cuatro semanas, tres personas, una presentación final.

Él quería saber qué era una PoC. Yo quería saber por qué el cheque tenía el tamaño de un MVP entero.

Acá vive la confusión. Una PoC, o prueba de concepto (del inglés proof of concept), es un experimento corto y barato que responde a una sola pregunta técnica: “¿esto es posible, y a qué costo?”. No es un producto. No es un prototipo. No es un MVP. Es un ejercicio de reducción de riesgo antes de que comprometas el presupuesto de todo el proyecto. En un proveedor serio dura entre una y tres semanas, cuesta entre 3.000 y 18.000 dólares, y el entregable principal no es código bonito: es conocimiento.

Si sos founder no técnico y alguien te está ofreciendo una PoC, esta guía existe para explicarte qué estás comprando, cuándo tiene sentido pagar, y cuándo la palabra “PoC” se convirtió en una forma educada de cobrarte por el propio aprendizaje del proveedor.

La PoC, en una frase

Una PoC responde a una pregunta técnica que nadie en tu sala puede responder con confianza. Tres ejemplos de cómo se ve esa pregunta, del mundo real:

• “¿Podemos sincronizar los datos del sistema legado de la clínica con nuestra app sin reescribir el legado?”
• “¿Este modelo de IA puede leer las facturas de nuestros proveedores con más del 95% de precisión?”
• “¿La API de Open Banking soporta el caso de uso que le prometimos al cliente piloto?”

Cada una es una pregunta cerrada: la respuesta es “sí”, “no”, o “sí, pero”. La PoC existe para llegar a esa respuesta en días, con código descartable, antes de que el presupuesto del proyecto entero esté en riesgo. Cuando la pregunta no es cerrada (cuando en realidad es “¿el cliente quiere esto?” o “¿el mercado paga por esto?”), no necesitás una PoC. Necesitás otra cosa, y la próxima sección desambigua cuál.

PoC, MVP, prototipo, spike: el mapa rápido

Cuatro palabras, cuatro instrumentos distintos, y el vocabulario del mercado mezcla a todos. El resumen honesto:

• PoC. Valida una hipótesis técnica. Responde “¿esto es posible?”. Código descartable. Audiencia: el equipo de producto y de ingeniería. No va al cliente.
• Prototipo. Valida una hipótesis de diseño. Responde “¿la gente entiende esta interfaz?”. Puede ser estático en Figma o clickeable. Va a usuarios en testing, no a producción.
• MVP. Valida una hipótesis de negocio. Responde “¿alguien lo usa, alguien paga?”. Es un producto chico, pero es producto: va a clientes reales, en el mundo real, con datos reales. Esa es la fase para la cual sirve de preparación la mayor parte del trabajo de product discovery.
• Spike. Es la versión chica de la PoC, generalmente dentro de un sprint, sin entregable formal. El equipo se mete en una cuestión técnica durante 2 a 5 días y vuelve con una recomendación. Martin Fowler describe el patrón en una página, vale la pena leerla.

Cuando alguien te ofrece una PoC y el alcance se lee como “vamos a construir una primera versión del producto”, no estás mirando una PoC. Estás mirando un MVP con el nombre cambiado, y el precio casi siempre lo confirma.

Lo que entrega una PoC seria

La entrega de una PoC útil tiene cuatro componentes, y la falta de cualquiera de ellos es una señal de que el trabajo no se hizo con rigor:

1. Un reporte que dice “sí”, “no” o “sí, pero”. En una o dos páginas. Con la pregunta original arriba y la respuesta en el segundo párrafo. Si necesitás leer 30 slides para entender el veredicto, no es un reporte, es una defensa de presupuesto.
2. El código (o los artefactos) que usaron para llegar a esa respuesta. Aunque sea descartable, queda en tu repo. Lo pagaste; es tuyo. Si el proveedor te dice “el código se queda con nosotros”, es una señal de algo mal, y el mejor momento para descubrirlo es ahora. Ese es uno de los puntos que separa un contrato de desarrollo de software serio de un template bajado de internet.
3. Una lista honesta de lo que quedó afuera. Toda PoC corta esquinas. Performance, seguridad, casos extremos. La entrega tiene que nombrar lo que se salteó, para que nadie lea el “sí” del reporte como “está listo para escalar”.
4. Una estimación actualizada del proyecto que viene después. Rango de horas, rango de riesgo, rango de costo. Toda la razón por la que la PoC existe es que la estimación previa era un cálculo a ojo. Después de la PoC, debería ser menos a ojo.

Notá lo que no está en la lista: pantallas finalizadas, documentación técnica completa, manual de usuario, video promocional. La PoC no entrega eso. Si la propuesta promete todo eso por 40.000 dólares en cuatro semanas, alguien va a salir decepcionado, y históricamente es el founder.

Cuándo una PoC tiene sentido para el founder no técnico

Hay cuatro escenarios en los que vale la pena gastar plata en una PoC antes del proyecto principal. Fuera de ellos, generalmente es desperdicio:

1. El proyecto depende de una integración que nadie del equipo hizo nunca. Open Banking, ERPs legados de hospital, sistemas de registro público, APIs de obras sociales o aseguradoras. Si la viabilidad del producto depende de que esa integración funcione, y nadie te lo puede garantizar en papel, la PoC sale más barata que descubrir el problema a mitad del proyecto.

2. El caso de uso depende de que un modelo de IA alcance un nivel de calidad específico. “Extraer el dato X del documento Y con 95% de precisión” es una pregunta de PoC. “Construir una plataforma de IA” no lo es. Cuando la viabilidad del producto depende de una métrica cuantitativa de un modelo, validá esa métrica primero, aislada, antes de construir la interfaz alrededor.

3. La arquitectura propuesta tiene una decisión de seis cifras embutida. Microservicios o monolito; base de datos relacional o de grafos; nube A o nube B. Cuando elegir mal al principio sale caro de revertir después, una PoC enfocada en comparar dos caminos paga su propio costo diez veces.

4. Necesitás munición fáctica para una conversación con un inversor o un cliente piloto. “Sí, la integración con el ERP del cliente es viable; acá está el reporte técnico” es un argumento distinto a “creemos que es viable”. Cuando el ciclo comercial está condicionado a una señal técnica, la PoC compra esa señal.

Cuándo “PoC” se transformó en otra cosa

La palabra también se usa con otros significados, y el founder no técnico tiene que reconocer cada uno para no pagar por el equivocado:

PoC como “MVP barato”. El proveedor le llama PoC a lo que es, en la práctica, la primera versión del producto. Generalmente es una forma de bajar el precio de entrada del proyecto, o de cerrar una venta en ciclo corto. No hay problema en comprar una primera versión chica. Hay problema en llamarla PoC, porque el vocabulario cambia las expectativas: la PoC es descartable, el MVP es fundación. Si pensás que estás validando viabilidad y en realidad estás construyendo fundación, vas a usar atajos peligrosos.

PoC como “diagnóstico pago”. Común en proyectos de IA generativa en 2025 y 2026. El proveedor cobra para descubrir si la tecnología que vende funciona en tu caso. En algunos mercados eso es razonable. En otros, es cobrarte por el propio aprendizaje del proveedor. La diferencia está en quién sale dueño del conocimiento al final: vos, o ellos.

PoC como “discovery disfrazada”. Cuando lo que el proyecto realmente necesita es entender el problema del usuario, mapear procesos, hacer entrevistas, y el proveedor lo empaqueta como PoC para evitar la palabra “consultoría”. Es discovery, vale la pena hacerla, pero el vocabulario correcto importa: discovery y PoC tienen entregables y equipos distintos.

El test de cuatro preguntas antes de aprobar una PoC

Antes de firmar, leé el alcance de la PoC propuesta y respondé estas cuatro preguntas. Si no podés responder tres de ellas, parate y devolvé el documento:

1. ¿Cuál es, en una frase, la pregunta que esta PoC responde? Si la respuesta es “validar la viabilidad técnica de la plataforma”, el alcance está vago. Querés “validar si podemos sincronizar datos del sistema X con nuestro sistema Y dentro de un SLA de 5 minutos”. Específica. Cerrada. Verificable.

2. ¿Cuál es el criterio de “sí” y cuál el de “no”? La PoC debería describir, antes de empezar, qué cuenta como éxito y qué como fracaso. “Más del 95% de precisión” es criterio. “Presentar resultados prometedores” no lo es. Sin criterio, cualquier resultado pasa a ser “sí”.

3. ¿Qué te queda a vos al final? ¿Código, reporte, datos, o sólo una presentación? ¿Quién es dueño del código? ¿Dónde está almacenado? Si el proveedor no responde estas preguntas de forma directa, la PoC se está vendiendo como servicio, no como entregable.

4. Si la PoC da “no”, ¿qué cambia en tu próximo paso? Si la respuesta es “seguimos igual”, no necesitás una PoC. Necesitás coraje para empezar y disciplina para ajustar el rumbo. Una PoC sólo tiene sentido si su resultado te puede hacer parar.

Cuánto cuesta, cuánto tarda, quién la debe hacer

Rangos honestos, de lo que vemos en proveedores serios para software custom en 2026:

• Duración. Una a tres semanas. Arriba de cuatro, ya no es PoC, es proyecto. Abajo de una, probablemente es spike y ni siquiera necesitaría presupuesto separado.
• Costo. Entre 3.000 y 18.000 dólares, con la mayor parte de los casos sanos entre 6.000 y 12.000. PoCs de 30.000 dólares o más existen (integraciones complejas, regulación), pero la vara de justificación sube rápido.
• Equipo. Una a tres personas. Típicamente un ingeniero senior que toma las decisiones técnicas, eventualmente un especialista (seguridad, IA, datos), y medio tiempo de una persona de producto que escribe el reporte.
• Quién debería hacerla. Idealmente el mismo equipo que va a tocar el proyecto entero después, o un equipo que va a entregar la recomendación a otro equipo para ejecutar. Quien hizo la PoC tiene el contexto; quien sólo leyó el reporte va a inventar la mitad de lo que creía saber. Es una de las razones por las que staff augmentation rara vez es el modelo correcto para una PoC: el contrato termina y el conocimiento se va con la persona.

Si tu propuesta cae afuera de esos rangos, preguntá por qué. La respuesta puede ser legítima (regulación bancaria, integración con sistema federal, equipo especializado). O puede ser que estás pagando un MVP al precio de una PoC, y el vocabulario fue calibrado para lo que entraba en el presupuesto.

Preguntas frecuentes

¿PoC y prueba de concepto son lo mismo?
Sí. PoC es la sigla en inglés de proof of concept, traducida como “prueba de concepto”. El mercado tech hispano usa las dos formas, a veces en la misma frase. No hay diferencia de significado.

¿Qué significa POC fuera del contexto de software?
La sigla aparece en otros lugares y ensucia la búsqueda. En construcción, “POC” puede ser una medida de avance de obra (percentage of completion). En medicina, es “punto de atención” (point of care). Esta guía trata sólo de la PoC de software.

PoC, MVP o prototipo: ¿por cuál empezar?
Depende de la pregunta que necesitás responder. Si la duda es técnica (“¿esto es posible?”), empezá por la PoC. Si la duda es de diseño (“¿la gente entiende esto?”), empezá por el prototipo. Si la duda es de mercado (“¿alguien paga?”), saltá directo al MVP. Ninguno de los tres es “anterior” al otro: son instrumentos para preguntas distintas.

¿Puedo saltar la PoC e ir directo al proyecto?
Sí, y en la mayoría de los casos es lo que tiene sentido. La PoC sólo vale cuando hay una incertidumbre técnica real que puede matar el proyecto y que sale caro descubrir después. Si tu producto es una versión de algo que ya existe, en un stack conocido, la PoC se vuelve teatro de proceso.

¿Cuánto dura una PoC de IA?
La misma regla que las demás: de una a tres semanas para responder una pregunta específica y cerrada. PoCs de IA que duran dos meses generalmente no están validando una hipótesis; están construyendo un producto sin decir que lo es.

¿El código de la PoC va a ser la base del producto?
No, y esa es la parte más difícil de aceptar. El código de la PoC está optimizado para velocidad de respuesta, no para mantenimiento. La mayor parte se va a tirar cuando el proyecto empiece. Lo que se queda es el aprendizaje, registrado en el reporte y en la cabeza de la gente involucrada. Si un proveedor te promete que el código de la PoC “se va a aprovechar al 80% para el producto”, desconfiá: o la PoC se va a convertir en un MVP mal hecho, o el producto va a heredar atajos que parecían baratos en el momento y se quedan caros para siempre.