MVP de IA SaaS: qué construir primero con presupuesto fijo

El año pasado nos llegó un fundador con una lista de veintidós funciones. Su presentación a inversores las prometía todas y le quedaban nueve meses de caja. La lista era buena; el problema era el orden. Seis de esas funciones dependían de una pieza de lógica que nadie había probado todavía, y esa pieza estaba programada para el quinto mes. Si no funcionaba, todo lo construido antes iba a la basura.

De ese problema de orden trata en realidad el desarrollo de un MVP de SaaS con IA. No se trata de con qué rapidez escribe usted código, sino de qué código escribe primero y de qué aprende la semana siguiente a publicarlo.

Casi todos los equipos lo hacen al revés. Construyen el producto entero y después se lo enseñan a alguien. Para cuando llegan usuarios de verdad, buena parte de lo construido está sin usar. Y lo único que había que cambiar se decidió en la primera semana, enterrado bajo todo lo que se apiló encima.

Nuestro argumento es sencillo. Elija la única función sobre la que se sostiene o se cae su modelo de negocio. Constrúyala bien, sobre una infraestructura que le convenga conservar, y póngala delante de un grupo cerrado de usuarios reales antes de construir nada más.

La forma cara de descubrir que su hoja de ruta estaba equivocada

Hay tres patrones que aparecen una y otra vez, y los tres cuestan meses.

El primero es la hoja de ruta escrita antes de las pruebas. Las funciones quedan fijadas en un documento de planificación, la construcción sigue al documento y nada del documento se cuestiona hasta el lanzamiento. Entonces llegan los datos de uso. Buena parte del conjunto de funciones resulta ser peso muerto en el primer año. No es que fallen. Es que nadie las abre.

El segundo es la sorpresa al enviar el producto. Un equipo termina la construcción, lo manda a una tienda de aplicaciones o lo entrega a quien revisa el cumplimiento normativo, y descubre que su forma de recoger, guardar y mover los datos de los usuarios no se sostiene. El tratamiento de datos no es una pantalla que se añade al final. Es una decisión de esquema que se toma la primera semana, y deshacerla obliga a tocarlo todo.

El tercero es el prototipo sobre el que no se puede construir. Algo se monta deprisa para enseñárselo a los inversores. Funciona, y entonces el equipo intenta añadir la segunda función. Los atajos que se tomaron en el modelo de datos o en la estructura de permisos resultan ser carga estructural. La reconstrucción cuesta más que la construcción original.

Lo mismo se ve desde dentro. A quien programa le gusta construir. Con un encargo poco definido, entregará más de lo que nadie pidió. Después el equipo dedica un sprint a sacar funciones para encontrar el producto que había debajo. La disciplina sobre el alcance no es un rasgo de carácter. Hay que dejarla escrita en el plan.

La rebanada fina: una función, bien construida

Un MVP no es una versión a medio hacer del producto completo. Un producto a medio hacer hace diez cosas mal y no demuestra nada. La rebanada fina hace una cosa bien, sobre infraestructura real, delante de gente real.

La rebanada existe para responder a una pregunta: ¿funciona la idea central cuando la usa alguien que no es usted? Todo lo demás se anota y se aparca. Lo de anotarlo importa. Las funciones aparcadas no se cancelan, se ordenan, y ese orden cambia en cuanto uno tiene pruebas.

La decisión se compone de seis elementos, y conviene tenerlos en una sola página:

• La lista de funciones. Todo lo que quiere llegar a tener, sin filtrar.
• El presupuesto. Lo que puede gastar de verdad antes de necesitar más dinero o ingresos.
• La rebanada fina. La única función que sale primero, elegida porque de ella depende el modelo de negocio.
• La hoja de ruta. Lo que espera, en qué orden y con el motivo al lado.
• La beta cerrada. Un grupo pequeño de usuarios reales con trabajo real que hacer, no amigos pinchando por ahí.
• La respuesta. Qué hicieron con ella y qué le dice eso sobre lo siguiente que construir.

Este marco solo aguanta si usted lo defiende de la expansión del alcance. Fundadores capaces de explicar con soltura los principios de un MVP añaden igualmente tres cosas durante la construcción, porque cada una parece necesaria en su momento. La defensa son el presupuesto y el calendario, ambos fijados antes de empezar. Cuando alguien propone añadir algo, la pregunta no es si es buena idea. Es qué sale para hacerle sitio.

Cómo elegir qué sale primero en el desarrollo de un MVP de SaaS con IA

La primera semana es una semana de pensar, y se piensa en algo muy concreto: ¿de qué depende este producto para sostenerse o caer?

Una herramienta de diagnóstico para educación superior se sostiene sobre su cadena de diagnóstico: registro del estudiante, las evaluaciones, el análisis puntuado y una persona experta que revisa el resultado antes de devolverlo. Si la lógica de evaluación no produce resultados que alguien del mundo académico firme con su nombre, ningún panel lo salva. Así que los paneles esperan.

Un asistente de marketing para gremios y servicios a domicilio se sostiene sobre su motor de auditoría. Tiene que mirar la web de un fontanero, encontrar qué falla y sugerir palabras clave sobre las que alguien sin formación en marketing pueda actuar. Eso es el producto. El seguimiento de posiciones y la atribución de contactos son para clientes que ya pagan, y usted todavía no tiene ninguno.

Un producto financiero se sostiene sobre su capa de cálculo. Los números tienen que estar bien antes de que merezca la pena construir cualquier otra cosa, y la forma de demostrar que lo están es pasar casos reales por él con una persona revisando cada resultado. Las pantallas de informes y las exportaciones para cumplimiento llegan cuando las cuentas ya aguantan.

La regla que hay debajo de los tres casos: publique la rebanada que demuestra el modelo de negocio, no la que hace que el producto parezca completo. Lo completo es una sensación. Lo que usted está comprando son pruebas.

Este es también el momento en el que a veces le decimos a alguien que no construya. Si la pregunta central se responde con una hoja de cálculo, un buzón compartido y una semana de trabajo manual, haga eso. Algunas ideas necesitan software para ponerse a prueba. Muchas otras no, y averiguarlo cuesta una conversación en lugar de un trimestre.

Qué dejar fuera de la primera versión

Las exclusiones son donde realmente se hace el presupuesto. Hay cinco que aparecen en casi todos los planes de producto de IA ajustado que escribimos.

Modelos propios. Entrenar su propio modelo es un proyecto de investigación sin fecha de final conocida. Las API comerciales resuelven la primera versión, y la resuelven ya. Si más adelante sus datos o sus márgenes justifican el ajuste fino de un LLM privado con alojamiento seguro, tomará esa decisión con datos de uso en la mano y no con una corazonada. Saltárselo al principio ahorra de ocho a doce semanas.

Aplicaciones móviles nativas. Primero web adaptable. Dos compilaciones nativas más el envío a las tiendas añaden coste y riesgo de revisión, y a quien prueba en una beta cerrada el navegador le parece perfecto.

Funciones avanzadas. Motores de recomendación, seguimiento de posiciones, puntuación por comportamiento. Todas razonables. Ninguna demuestra lo esencial.

Integraciones que no sostienen la rebanada. Puede que un conector sea imprescindible porque sin él el producto no funciona. Los otros seis son para la versión dos. Los conectores de terceros envejecen mal cuando el producto a su alrededor todavía está cambiando de forma.

Paneles pulidos. Construya la interfaz justa para que quien prueba pueda usar la cosa sin usted sentado al lado. El pulido de verdad espera a que los usuarios le hayan dicho qué números miran realmente, que rara vez son los que usted habría supuesto.

Hay un debate abierto sobre si el MVP tradicional está anticuado y si los fundadores deberían publicar algo más cercano a un producto completo usando herramientas de poco código. Algo de razón tiene. El poco código lleva rápido al mercado cuando el producto es un flujo de trabajo. Deja de ayudar cuando el producto es la propia lógica de IA, porque ahí es donde vive el trabajo a medida y donde un constructor genérico toca techo.

Tres decisiones de arquitectura que no le dejan atrapado

Las tres se toman en la primera semana, cuando no cuestan nada extra. Arreglar cualquiera de ellas con usuarios ya en el sistema cuesta una reconstrucción.

Su propia capa de API, no la de un proveedor. Cada llamada al modelo pasa por una capa que usted controla. La aplicación habla con su backend y su backend habla con el proveedor que usted esté usando. Cuando un proveedor sube precios, retira un modelo o pierde en calidad frente a otro, usted cambia un servicio. Hemos visto a un producto de marketing cambiar de proveedor a mitad de construcción por una subida de coste sin tocar el código de la aplicación. Eso es lo que le compra una integración de API de IA a medida con capa envolvente.

Modelo de datos y seguridad antes que pantallas. Separación multiinquilino diseñada dentro del esquema en lugar de añadida por fuera. Puntos de acceso al modelo configurados para que el proveedor no entrene con lo que introducen sus clientes, con retención cero solicitada allí donde el proveedor la ofrezca. Reglas de permisos resueltas antes de que nadie construya una pantalla de acceso. Para trabajo regulado, las decisiones de arquitectura segura y conforme para IA pertenecen a la misma semana que el esquema.

Infraestructura de producción desde el primer día, a escala reducida. El MVP corre sobre el mismo alojamiento que correrá el producto completo, solo que con una configuración más pequeña. La misma arquitectura, menos recursos. Uno crece hacia dentro de ella en lugar de salírsele, y no hay un proyecto de migración esperando detrás de sus primeros cien usuarios.

En esta fase fijamos además una regla de comportamiento. Todo lo que toca dinero o llega a un cliente pasa por una aprobación humana. El modelo redacta, una persona confirma y entonces ocurre la acción. Eso vale durante el MVP y vale después.

Lo que cuestan realmente las semanas

Semanas 1 y 2. Arquitectura y mapa de seguridad. En esta fase trabajan una o dos personas de ingeniería. La cadena de datos se dibuja antes de que exista una línea de código. Se decide la estructura multiinquilino. Se eligen los puntos de acceso al modelo y se confirman los ajustes de retención. Lo que se entrega es un plan con coste que nombra la rebanada, nombra lo excluido y declara el equipo y el plazo que exige la construcción.

Al final de esas dos semanas usted debería poder marcharse con un documento que le sirva incluso si contrata a otra empresa.

Semana 3 en adelante. Construir la rebanada. Primero la lógica central y el backend, porque ahí está el riesgo. La integración de IA va encima, y luego la interfaz justa para que alguien de la beta cerrada pueda usarla sin ayuda. Nada de pulido.

De dónde sale el ahorro, sin rodeos:

• API primero en lugar de un modelo propio: de ocho a doce semanas menos de calendario.
• Una función bien construida en lugar de diez a medias: suele desaparecer entre el 40 y el 50 por ciento del alcance.
• Tratamiento de datos resuelto de entrada: ninguna reescritura cuando alguien pregunte cómo se guardan los registros.
• Beta cerrada antes del lanzamiento público: los problemas serios salen delante de veinte personas, no de dos mil.

Una rebanada fina suele situarse entre 40.000 y 100.000 dólares según cuánta lógica haya detrás. Es un rango amplio, y el motivo honesto es que una cadena de análisis de documentos y un motor de cálculo financiero no son la misma cantidad de trabajo. Nombramos el tamaño del equipo y la duración antes de empezar, así que la cifra se conoce antes de que usted se comprometa. El código, las cuentas y las claves son suyos todo el tiempo, lo que significa que la cifra que acepta es la cifra completa.

Es frecuente que fundadores sin perfil técnico pasen seis meses y mucho dinero con un socio de desarrollo antes de darse cuenta de que existía un primer paso más pequeño. Tener una rebanada funcionando delante de gente que la prueba dentro del primer trimestre es hoy una expectativa razonable, y es el estándar con el que construimos.

Qué salió primero: tres ejemplos

Una plataforma de diagnóstico para educación superior en el Reino Unido. Salió: registro, seis evaluaciones académicas, análisis puntuado con IA y verificación por personas expertas antes de entregar resultados. Esperó: los paneles, el motor de personalización, las bibliotecas de contenido, los informes para instituciones. La metodología era el producto. Hasta que la puntuación aguantó la revisión académica, nada de lo construido encima tenía valor.

Un asistente de marketing para negocios de servicios a domicilio. Salió: auditoría del sitio, análisis de palabras clave, redacción de contenidos y un panel sencillo. Esperó: seguimiento de posiciones, conexión con el CRM, atribución de contactos, seguimiento por SMS. La auditoría y el trabajo de palabras clave demuestran que la herramienta resuelve el problema que un gremio tiene de verdad. La atribución importa cuando hay ingresos que atribuir.

Una herramienta de apoyo a la evaluación para docentes particulares. Salió: análisis de documentos, lectura de rúbricas y guía de preparación priorizada. Esperó: videoconferencia, un mercado completo, moderación automática. El análisis y el circuito de retroalimentación son aquello por lo que la gente paga. Todo lo demás era infraestructura alrededor de un producto que aún no estaba validado.

En los tres casos, los primeros clientes llegaron porque el fundador vendió directamente, no por una campaña de lanzamiento ni por captación pagada. El fundador habló con gente que tiene el problema, la vio usar la rebanada y ajustó. Ese canal funciona mejor que cualquier otro en esta etapa, y es la vía más rápida para aprender qué debería llevar la versión dos. El prototipado rápido con IA existe para darle algo real que llevar a esas conversaciones.

Qué se tuerce cuando se salta la rebanada

La expansión del alcance hace más daño que los fallos. Los fallos se encuentran y se arreglan. La expansión del alcance retrasa el lanzamiento meses mientras el equipo construye funciones que un usuario real le habría dicho que descartara, y usted se entera después de haberlas pagado.

Las sorpresas con el tratamiento de datos llegan tarde y llegan fuerte. Las tiendas de aplicaciones y los reguladores miran la recogida, el almacenamiento y la transferencia. Diseñar eso al final significa deshacer decisiones de la primera semana. Las finanzas y la salud son los ámbitos menos indulgentes, y nadie puede garantizarle una aprobación. Lo que sí está en su mano es que su arquitectura sobreviva a las preguntas.

La dependencia de un proveedor se acumula en silencio. El SDK de un proveedor incrustado por todo su código significa que cambiar cuesta una reconstrucción. Los ajustes de retención que nunca cambió significan que lo que introducen sus clientes puede estar viviendo en la infraestructura de otro. Un alojamiento que no controla significa que no puede mudarse ni renegociar precios cuando lo necesite.

El prototipo sobre el que nadie puede construir sigue siendo el más caro de los cuatro fracasos, porque parece un éxito justo hasta que se añade la segunda función.

Preguntas que hacer antes de que nadie escriba código

Seis preguntas. Si sabe responderlas, su plan de producto de IA ajustado está escrito casi del todo.

• ¿Qué única función demuestra o mata la idea?
• ¿Puede demostrarlo con una API en lugar de con un modelo que entrene usted?
• ¿Qué reglas sobre datos tienen que estar bien el primer día y no el día noventa?
• ¿Quién usa la versión uno, con nombre y apellidos, y qué está intentando conseguir?
• ¿Qué integraciones pueden esperar de verdad a que entre dinero?
• ¿De quién son el código, las cuentas en la nube y las claves de API cuando termina la construcción?

Esta última se salta más de lo que debería. Si la respuesta no es usted, el resto del plan importa poco.

Cuándo dejar de planificar y empezar a construir

No tendrá todas las respuestas antes de empezar. De eso trata construir una rebanada en lugar de un producto. Veinte usuarios reales haciendo trabajo real le dirán más en quince días que otro mes de sesiones de planificación, y le dirán cosas que no se le habría ocurrido preguntar.

Las herramientas no dejan de cambiar, y los asistentes de programación con IA han hecho la fase de construcción realmente más rápida. Eso es cierto. Lo que no ha cambiado es la parte que decide si el dinero se gastó bien: elegir la primera función correcta y construirla sobre cimientos que pueda conservar. Esa es toda la disciplina que hay detrás del desarrollo de un MVP con IA, y es más antigua que cualquiera de las herramientas de ahora.

Si quiere ayuda para averiguar cuál es su rebanada, reserve una auditoría de automatización gratuita. Trazaremos la única función que demuestra su idea, pondremos precio al plan y le diremos con franqueza si le conviene más no construirlo. También puede ver cómo se definen y se presupuestan nuestros MVP de IA a medida o leer cómo trabajamos con nuestros clientes antes de escribirnos.

Arun Andiselvam

LinkedIn

Soy un emprendedor que ha creado cinco marcas. Vendí la primera, una herramienta de SEO, en una operación de seis cifras, y hoy creo productos de automatización con IA para empresas. Financié cada una con recursos propios desde el primer día.