Piloto de pago vs PoC vs design partner: ¿qué valida la demanda?

Un piloto de pago aporta la evidencia más fuerte de demanda comercial porque un comprador real compromete presupuesto y prueba el producto en un workflow real. Una prueba de concepto demuestra viabilidad técnica. Un design partner demuestra que un cliente representativo sufre el problema y ayudará a dar forma a la solución. Ninguno de los tres demuestra por sí solo una demanda repetible de mercado.

El nombre que figure en el statement of work no decide lo aprendido. Un cliente puede pagar un PoC porque quiere investigación a medida, no porque quiera comprar el producto futuro. Un design partner puede firmar con entusiasmo y no usar el software. Un piloto puede parecer comercial mientras el founder hace tanto trabajo manual que un segundo cliente no podría recibir el mismo producto.

Esta página responde la decisión comercial entre los tres modelos. Para una definición estricta consulta el glosario de proof of concept. Si aún decides si construir un producto real, empieza por la definición de MVP.

Piloto de pago, PoC y design partner en una tabla

Las guías públicas mantienen la misma frontera. El toolkit de compra innovadora de la Comisión Europea sitúa el PoC en la viabilidad práctica y el piloto en un despliegue limitado dentro del entorno final. La guía PoC-to-scale del Gobierno australiano separa también las métricas: viabilidad técnica para el PoC, usuarios e impacto de negocio para el piloto.

¿Cuál de los tres valida demanda?

Elige un piloto de pago cuando la principal incertidumbre sea la demanda comercial. Es una señal más fuerte que una entrevista, una carta de intención o una beta gratis porque obliga al comprador a tomar una decisión presupuestaria. Solo resulta creíble si paga por un resultado de producto repetible, no por horas del founder ni por un desarrollo a medida.

1. Evidencia del problema: los usuarios objetivo describen el mismo workflow doloroso y un workaround activo.
2. Evidencia de compromiso: el comprador aporta datos, tiempo, revisión de seguridad o acceso de implementación.
3. Evidencia de pago: quien controla presupuesto paga una cantidad relevante y no reembolsable.
4. Evidencia de valor: el uso real mueve una baseline operativa o financiera acordada.
5. Evidencia de conversión: el comprador firma producción o continúa al precio previsto.
6. Evidencia de repetibilidad: varios clientes independientes del mismo perfil de cliente ideal compran por el mismo motivo sin exigir un producto nuevo.

Un piloto de pago puede alcanzar los pasos tres a cinco. Uno solo no alcanza el sexto. “Tenemos un piloto de pago” significa que una cuenta ha mostrado demanda en esas condiciones, no que el mercado está validado. Nuestra guía sobre el minimum credible product explica cómo definir la versión más pequeña capaz de ganar evidencia más fuerte.

¿Qué demuestra realmente una prueba de concepto?

Un PoC debe retirar una incertidumbre técnica antes de gastar presupuesto de producto. ¿Soporta una interfaz legacy el throughput necesario? ¿Alcanza un modelo el resultado acordado con datos representativos? ¿Cabe una construcción criptográfica en el presupuesto de latencia? La respuesta es sí, no o inconclusa frente a una prueba escrita.

Un PoC pagado tampoco demuestra automáticamente demanda de producto. El pago puede indicar que el cliente valora investigación, integración o expertise. No demuestra que comprará el producto resultante a precio de producción. Separa dos compras:

• Fee de viabilidad: pago por responder una pregunta técnica.
• Gasto de producto: pago por usar repetidamente un resultado en el negocio.

Si la incertidumbre está en requisitos, ownership o alcance, suele encajar mejor una fase de discovery de software. No inventes un experimento técnico para hacer que una decisión normal de producto parezca científica.

¿Qué demuestra un design partner?

Un design partner ofrece al equipo acceso recurrente a un workflow real, usuarios reales y un comprador capaz de explicar cómo ocurre la compra. El mejor partner representa al segmento, siente urgencia y tiene capacidad para probar. Son los tres criterios del framework de design partners de Andreessen Horowitz.

Un design partner gratuito puede aportar gran evidencia sobre problema y usabilidad. La evidencia sobre disposición a pagar es débil. Elogios, peticiones de features, entusiasmo ejecutivo y permiso para usar el logo no sustituyen una compra. La cuestión comercial sigue abierta hasta que quien controla presupuesto acepta precio y ruta a producción.

Un design partner de pago puede ser el híbrido temprano más fuerte. El cliente paga, ofrece feedback semanal y ayuda a formar un producto todavía incompleto. Sierra aplicó una versión de alto compromiso con pago, acceso a sistemas y participación recurrente, según el relato de First Round sobre su estrategia. El riesgo es el overfitting. Contrasta cada petición con otros compradores objetivo antes de incorporarla al roadmap central.

¿Cuándo es válido un piloto de pago como evidencia de demanda?

Suma un punto por cada condición. Seis o siete puntos producen evidencia comercial útil. Cuatro o cinco ofrecen una señal mixta. Tres o menos se parecen más a una demo, consultoría o experimento subvencionado.

La Agencia Espacial Europea describe el piloto como prueba con clientes del mercado objetivo y en un entorno operativo real para confirmar la propuesta de valor. Ese es el listón correcto. El pago mejora la señal, pero la realidad operativa separa el piloto del teatro pagado. Consulta la distinción de ESA entre estudios PoC y proyectos piloto.

¿Cómo elegir?

No ejecutes los tres por costumbre. Empieza con el instrumento más pequeño que resuelva la incógnita de mayor riesgo. Si una tecnología probada soporta el workflow, omite el PoC. Si el producto ya sirve el workflow, omite la co-creación gratis y pide un piloto de pago o un contrato de producción.

¿Qué debe incluir el acuerdo?

Este brief comercial va antes de la redacción legal. No es asesoramiento jurídico. Un profesional debe adaptar IP, protección de datos, responsabilidad y procurement a las partes y jurisdicción.

1. Pregunta de decisión: una frase que nombre lo que debe demostrar el engagement.
2. Alcance y exclusiones: workflow, usuarios, datos, integraciones, volumen y lo que queda fuera.
3. Compromisos del cliente: sponsor, owner operativo, tiempo, datos, security review y frecuencia de feedback.
4. Plan de evidencia: baseline, métricas, instrumentación, muestra y owner del readout.
5. Condiciones comerciales: fee, pagos, gastos, precio o mecanismo futuro y crédito al rollout.
6. Frontera de producto: producto estándar, configuración y entregables bespoke por separado.
7. Derechos: IP previo y nuevo, datos, aprendizaje agregado, confidencialidad y referencias.
8. Exit gate: fecha final, reunión y opciones exactas: convertir, una iteración o parar.

En un build de software, acompáñalo de un statement of work claro. Si se usan datos personales o regulados, no pospongas seguridad y responsabilidades de datos hasta producción.

Tres ejemplos, tres veredictos

1. El banco paga 20.000 € por un PoC de integración

El proveedor demuestra que su motor lee un formato legacy con el rendimiento necesario. El banco compra ingeniería especializada. Veredicto: viabilidad técnica y demanda del servicio probadas; demanda del producto no probada.

2. Cinco design partners participan gratis cada semana

Cuatro usan el prototipo repetidamente y describen el mismo workaround doloroso. Veredicto: problema y dirección de producto respaldados. La disposición a pagar sigue abierta. Ofréceles el mismo piloto acotado, no cinco roadmaps personalizados.

3. Tres equipos compran el mismo piloto de seis semanas

Cada uno paga desde el presupuesto previsto, usa el mismo producto y mide el mismo resultado. Dos convierten al rango acordado y uno para por falta de volumen. Veredicto: hay demanda repetible temprana en el segmento de alto volumen. La pérdida mejora el ICP.

"Un PoC demuestra que la máquina puede funcionar. Un design partner demuestra que el problema merece atención. Un piloto de pago demuestra que un comprador gastará dinero para cambiar un workflow real. La demanda repetible empieza cuando otro comprador hace lo mismo sin pedirte que te conviertas en otra empresa."

¿Cuánta demanda es suficiente?

• Un piloto de pago: evidencia de demanda a nivel de cuenta.
• Varios pilotos similares: hipótesis de demanda a nivel de segmento.
• Conversiones al precio previsto: validación comercial temprana.
• Uso continuado, renovación o expansión: evidencia de valor duradero.
• Venta y entrega repetibles: ruta creíble hacia el product-market fit.

La disposición a pagar importa porque demanda sin economía viable no crea negocio. La guía de pricing y packaging de Andreessen Horowitz conecta disposición a pagar con demanda y retorno esperado. Prueba el modelo comercial pronto para que un piloto descontado no oculte un precio de producción inaceptable.

Cuando un piloto de IA ya tenga datos operativos representativos, usa el scorecard para cancelar o escalar un piloto de IA. En software convencional puedes adaptar su lógica de baseline, coste, adopción, fiabilidad y payback.

Fuentes y metodología

Esta comparación es un modelo original de Wavect basado en la incertidumbre que reduce cada engagement. Las definiciones y fronteras de procurement se comprobaron el 22 de julio de 2026 con la Comisión Europea, el Gobierno australiano y ESA. Las afirmaciones sobre design partners y disposición a pagar se contrastaron con Andreessen Horowitz y First Round. La escalera de evidencia y el test de siete condiciones son frameworks de Wavect, no estándares universales.