Estudio de viabilidad: las cinco pruebas, y cómo hacerlas en un día
Un estudio de viabilidad pregunta si una idea puede funcionar antes de gastar dinero en averiguarlo. Las cinco dimensiones estándar, qué evidencia necesita cada una y dónde la plantilla clásica falla con el software.
Actualizado 2026-09-05 · 12 min de lectura
Un estudio de viabilidad es una evaluación estructurada previa al compromiso que comprueba si una iniciativa propuesta es construible técnicamente, viable económicamente, permitida legalmente, dotable de personal y planificable — produciendo una decisión de seguir, revisar o parar antes de comprometer capital.
Datos clave
- El marco clásico de viabilidad es TELOS: Technical, Economic, Legal, Operational, Scheduling — cinco pruebas independientes, cualquiera de las cuales descalifica.
- Las unit economics de SaaS en etapa temprana tienen dos suelos muy usados: una relación LTV/CAC de 3.0 para considerarse sana y en torno a 1.5 como el punto por debajo del cual el payback es aritméticamente imposible.
- Un payback de CAC de 18 meses es el referente común en etapa temprana; pasados unos 36 meses el modelo deja de ser un negocio.
- Al combinar varias estimaciones de tamaño de mercado, INITE Studio descarta los valores a más de 3σ de la mediana a partir de cuatro fuentes, y marca el conjunto como obsoleto cuando los años de publicación abarcan más de cinco.
Qué decide realmente un estudio de viabilidad
Un estudio de viabilidad es una evaluación estructurada previa al compromiso que comprueba si una iniciativa propuesta es construible técnicamente, viable económicamente, permitida legalmente, dotable de personal y planificable — produciendo una decisión de seguir, revisar o parar antes de comprometer capital.
Las palabras que hacen el trabajo son previa al compromiso. Todo aquello para lo que sirve un estudio de viabilidad ocurre antes de que se mueva el dinero. Hecho después, el mismo análisis se convierte en un ejercicio de justificación, porque quien lo hace ya tiene una posición que defender.
Esa es también la diferencia con un plan de negocio. Un plan de negocio asume que la iniciativa debe existir y describe cómo funcionará. Un estudio de viabilidad tiene permitido — de hecho, la obligación — de concluir que no debería. Un estudio que no puede producir un "parar" no es un estudio.
Las cinco pruebas
El marco estándar es TELOS: Technical, Economic, Legal, Operational, Scheduling. Cinco pruebas independientes, y el sentido de la estructura es que cualquiera de ellas descalifica. Una iniciativa que puntúa brillantemente en cuatro y falla la quinta no es viable en cuatro quintas partes. Es inviable.
1. Técnica: ¿se puede construir?
No "¿es teóricamente posible?". Si puede construirlo la gente que realmente vas a tener, con tecnología que existe hoy, a una calidad que el mercado aceptará.
La versión honesta de esta prueba pregunta tres cosas. ¿Cuál es el componente más difícil, y lo ha lanzado alguien? ¿De qué depende el sistema que tú no controlas — una API, una fuente de datos, un proveedor de modelos, una licencia? ¿Y qué le pasa al producto cuando esa dependencia cambia sus condiciones?
La última pregunta es donde la mayoría de los estudios de viabilidad de software son flojos. Un producto construido sobre la plataforma de otro hereda sus decisiones de precio y su calendario de deprecación.
2. Económica: ¿cuadra la aritmética?
Es la prueba que mata más iniciativas, y la que más a menudo se sustituye por una hoja de cálculo que crece un 20% al mes porque la celda de arriba lo hacía.
Como mínimo necesitas tres cifras y su relación: cuánto cuesta adquirir un cliente, cuánto vale un cliente a lo largo de su vida y cuánto tarda el payback. Dos suelos muy usados:
- LTV/CAC de 3.0 es la definición común de sano. En torno a 1.5 es el punto por debajo del cual el payback se vuelve aritméticamente imposible una vez contabilizados churn y margen.
- Un payback de CAC de 18 meses es el referente estándar en etapa temprana. Pasados unos 36 meses, el modelo ha dejado de ser un negocio.
No son leyes. Son los umbrales que la mayoría de los inversores te aplicarán, lo que los convierte en los umbrales que conviene probar antes de que lo haga otro.
La mitad de tamaño de mercado de la prueba económica tiene su propio modo de fallo. Un solo informe de analista no es evidencia; es una estimación con una fecha de publicación y una metodología que no puedes ver. Combinar varias es mejor, pero solo si tratas el desacuerdo con honestidad: descartando valores desbocados y considerando obsoleto un conjunto de estimaciones publicadas con años de diferencia en lugar de promediar sobre un mercado que cambió. La implementación de INITE Studio descarta lo que se aleja más de 3σ de la mediana a partir de cuatro fuentes, y marca un conjunto cuyos años de publicación abarcan más de cinco.
3. Legal: ¿está permitido?
La prueba más barata de saltarse y la más cara de fallar, porque un problema legal descubierto después del lanzamiento rara vez se arregla iterando.
Tres preguntas. ¿Está la actividad en sí licenciada o restringida en tus mercados objetivo? ¿Qué datos vas a conservar, y qué régimen los gobierna? ¿Y la propiedad intelectual de quién toca el producto — datos de entrenamiento, contenido extraído, un proceso protegido de un competidor?
Para cualquier cosa que toque salud, dinero, empleo, menores o datos personales, esta prueba pasa al principio de la cola. En esos dominios la respuesta regulatoria determina el diseño del producto, y no al revés.
4. Operativa: ¿puedes hacerlo funcionar?
Un producto que funciona en una demo y no se puede operar es inviable. Esta prueba pregunta quién hace el trabajo una vez que la cosa existe: soporte, moderación, fraude, onboarding, la lenta acumulación de casos límite.
La trampa específica de los productos de IA es que la demo es autónoma y el sistema en producción no lo es. Si cada caso ambiguo necesita un humano, el coste operativo por cliente es una línea de plantilla, no una línea de cómputo — y escala linealmente con los clientes, que es la forma de un negocio de servicios vestido con los márgenes de uno de software.
5. Calendario: ¿sobrevive el plazo a las dependencias?
La más débil de las cinco tal como suele practicarse, porque normalmente se responde con un diagrama de Gantt dibujado hacia atrás desde una fecha deseada.
La versión útil pregunta cuál es la cadena genuinamente serial más larga del proyecto: las cosas que no se pueden paralelizar por muchas personas que añadas. Una aprobación regulatoria, un plazo de entrega de hardware, una integración con un socio, un ciclo de ventas estacional. Y luego pregunta qué le pasa a la prueba económica si esa cadena se alarga un 50%, porque suele hacerlo.
Dónde falla la plantilla clásica con el software
Las cinco pruebas se formalizaron para proyectos de capital — plantas, puentes, adquisición de sistemas. Dos de sus supuestos no se transfieren.
El estudio no es una puerta única. En un proyecto de capital la viabilidad se evalúa una vez porque el compromiso es irreversible. Los compromisos de software son escalonados, lo que significa que la viabilidad debería reevaluarse en cada etapa — y los pesos deberían cambiar. Que el equipo pueda construirlo importa mucho más cuando ya hay producto que cuando solo había una idea.
Por eso la auditoría de INITE Studio pondera sus lentes por etapa en lugar de aplicar una fórmula fija. En etapa de idea, el encaje problema-solución lleva el 35% del peso y la tracción el 5%, porque no hay tracción que medir y fingir lo contrario solo añade ruido. En etapas posteriores la distribución se desplaza hacia la evidencia que ya existe.
El resultado suele ser un número, y un número no es una decisión. La mayoría de las plantillas terminan en una puntuación o una calificación. Una puntuación sin umbral es una opinión con decimales.
El remedio es escribir las condiciones de fallo antes de reunir evidencia: la métrica concreta, el valor concreto y la fecha para la que debe ser cierto. Comprometerse de antemano con esas condiciones es lo que convierte la eventual parada en una decisión y no en una discusión, porque quien tiene que aceptarla ya aceptó las reglas.
Por la misma razón vale la pena ser explícito sobre qué requiere un resultado positivo. La auditoría de INITE Studio solo devuelve GO cuando se cumplen cuatro condiciones a la vez: una puntuación compuesta de al menos 80, cero banderas rojas, una confianza media entre lentes de al menos 0,6 y ninguna contradicción sin resolver entre lentes. Si falta una, el veredicto es REFINE o KILL — no porque la idea sea mala, sino porque todavía no hay una respuesta con confianza.
Lo que no es: cuatro artefactos vecinos
La mitad de la confusión sobre los estudios de viabilidad viene de cuatro documentos que se solapan con ellos y responden a preguntas distintas.
| Artefacto | Pregunta que responde | Cuándo se hace | ¿Puede terminar en "no"? |
|---|---|---|---|
| Estudio de viabilidad | ¿Puede funcionar esto siquiera? | Antes del compromiso | Sí, ese es el objetivo |
| Plan de negocio | ¿Cómo operará y crecerá esto? | Tras decidir seguir | No, estructuralmente |
| Investigación de mercado | ¿Qué quieren los compradores y qué existe? | Alimenta al estudio | Es un insumo, no un veredicto |
| Due diligence | ¿Son ciertas las afirmaciones de alguien? | Antes de una transacción | Sí, sobre la iniciativa de otro |
| Prueba de concepto | ¿Funciona la parte técnica difícil? | Dentro de la prueba técnica | Solo sobre una dimensión |
Los dos que más a menudo se sustituyen son el plan de negocio y la prueba de concepto, y ambas sustituciones son caras del mismo modo: responden a una pregunta más estrecha y se tratan como si hubieran respondido la amplia. Un prototipo que funciona prueba la prueba técnica y no dice nada sobre la económica, la legal ni la operativa. Un plan pulido prueba que alguien sabe escribir.
Quién lo hace, y el conflicto que nadie nombra
Un estudio de viabilidad lo suele encargar la persona que quiere que el proyecto salga adelante. Eso es un conflicto estructural, y es la razón por la que tantos estudios concluyen que el proyecto es viable.
Tres defensas prácticas.
Escribe las condiciones de parada antes de reunir evidencia. Una vez que conozcas las cifras, elegirás umbrales que las cifras ya superan. Veinte minutos dedicados primero a los umbrales son el control de sesgo más barato disponible.
Dale una dimensión a alguien que no quiere el proyecto. Las pruebas legal y operativa son las dos que más a menudo se dan por buenas, y son las dos donde un lector sin motivación aporta más.
Registra qué cambiaría la respuesta. Un estudio que dice "seguir" sin declarar qué evidencia lo volcaría a "parar" no ha sido falsable en ningún momento, lo que significa que nunca fue una prueba.
Los patrones de fallo
Seis que se repiten, y cómo se ve cada uno desde fuera:
| Patrón | Cómo se manifiesta |
|---|---|
| Puntuación sin umbral | "Viabilidad: 7,4/10". Ningún valor declarado a partir del cual la respuesta es no |
| Cuatro de cinco | Pasar las pruebas fáciles y tratar la fallida como un riesgo a gestionar |
| Prototipo como prueba | La prueba técnica pasa; las otras cuatro nunca se hicieron |
| Tamaño de mercado prestado | Una cifra de analista, sin fecha de publicación, sin segunda fuente |
| Calendario dibujado hacia atrás | El plan parte de una fecha de lanzamiento en lugar de las dependencias |
| El estudio se hace tras la contratación | El compromiso ya está tomado; el documento es una justificación |
El cuarto merece una nota, porque es el que más se parece a trabajo. Una sola cifra de mercado publicada es una estimación con una metodología que no puedes inspeccionar. Dos cifras que discrepan informan más que una que no lo hace, y un conjunto publicado con años de diferencia describe varios mercados distintos en vez de uno.
Un ejemplo trabajado
Un equipo quiere construir una herramienta de informes de cumplimiento para clínicas en tres países europeos. Ejecuta las cinco pruebas en el orden que puede terminar el estudio antes.
Legal, primero, porque el dominio está regulado. Datos de pacientes dentro del alcance significa RGPD más normativa nacional de datos sanitarios que difiere en los tres países objetivo. El hallazgo no es "esto es ilegal": es que el producto necesita una historia de residencia de datos por país, y eso cambia la arquitectura. Coste de descubrirlo ahora: una tarde. Coste de descubrirlo tras construir: la arquitectura.
Económica, segundo. Digamos unas 9.000 clínicas del tamaño adecuado en los tres mercados, un ACV plausible de 4.000 €, y una venta que necesita una persona en el proceso. Eso es un SAM cercano a 36 M€ y un CAC que no tiene forma de autoservicio. Con 4.000 € de ACV y un 70% de margen bruto, el beneficio bruto mensual por cliente ronda los 233 €, así que un payback de 18 meses admite un CAC de unos 4.200 € todo incluido — que una venta de campo superará cómodamente, y una venta interna quizá pueda cumplir. La prueba no falla: te dice que la restricción es el canal, y ahora el canal hay que demostrarlo, no suponerlo.
Técnica y operativa juntas. La lógica de informes es tratable. La pregunta operativa es quién resuelve los registros ambiguos — y en un producto de cumplimiento, un registro ambiguo no se puede resolver automáticamente. Eso es una cola de revisión humana, que es una línea de plantilla que escala con los clientes.
Calendario al final. La cadena serial es el trabajo de residencia de datos por país más al menos un cliente de referencia por mercado antes de que firme el segundo. Vuelve a hacer la prueba económica con esa cadena un 50% más larga y mira si el plan de financiación sigue cuadrando.
El veredicto aquí no es seguir ni parar. Es revisar: el producto es viable con una venta interna y un modelo de coste con cola de revisión, e inviable con los supuestos de autoservicio con los que arrancó el equipo. Ese es el resultado útil más común, y un estudio que solo puede decir sí o no no puede producirlo.
Hacerlo en un día
Para un producto de software, la secuencia que funciona:
- Escribe primero las condiciones de parada. Antes de cualquier evidencia. De tres a cinco, cada una con métrica, umbral y fecha. Lleva veinte minutos y determina si el resto es honesto.
- Prueba legal primero si el dominio está regulado. Puede terminar el estudio, y es la única prueba que no se arregla construyendo de otra forma.
- Prueba económica segunda. LTV/CAC, payback y un tamaño de mercado montado con varias fuentes dejando el desacuerdo a la vista en lugar de promediarlo.
- Técnica y operativa juntas. Interactúan: el atajo técnico suele aparecer como coste operativo.
- Calendario al final, contra la cadena serial, y luego repite la prueba económica con el plazo un 50% más largo.
- Escribe la decisión, no la puntuación. Seguir, revisar o parar, y la evidencia concreta que lo cambiaría.
El último paso es el que se cae, y es todo el objetivo. Un estudio de viabilidad existe para que una decisión sea barata de revertir y cara de maquillar.
Preguntas frecuentes
- ¿Cuál es la diferencia entre un estudio de viabilidad y un plan de negocio?
- Un estudio de viabilidad pregunta si la iniciativa debería existir. Un plan de negocio asume que sí y describe cómo operará. El estudio va primero y tiene permitido terminar en un no; un plan de negocio que termina en un no ha fracasado como plan de negocio.
- ¿Cuánto debería durar un estudio de viabilidad?
- Para un producto de software, días en lugar de meses. El estudio tradicional de varias semanas existe porque reunir evidencia solía ser lento. Lo que aún lleva tiempo real es el trabajo legal y operativo cuando el dominio está regulado.
- ¿Qué hace fracasar a un estudio de viabilidad?
- Producir un número en lugar de una decisión. Un estudio que reporta una puntuación pero no nombra el umbral a partir del cual la respuesta es no ha registrado una opinión, no ha hecho una prueba.
- ¿Es lo mismo que una due diligence?
- No. La viabilidad se estudia antes del compromiso y pregunta si la cosa puede funcionar siquiera. La due diligence se hace antes de una transacción y verifica afirmaciones que ya hizo otra persona.
- ¿Necesito un estudio de viabilidad para un producto de software pequeño?
- Necesitas las cinco preguntas respondidas. Puede que no necesites el documento. El modo de fallo en productos pequeños es saltarse las pruebas económica y legal porque la técnica resultó fácil.