Cuando un producto se convierte en dos: cómo dividir tu app hecha con IA sin empezar de cero

Empezaste con una sola idea. Se la describiste a tu creador de apps con IA, lo viste generar las pantallas, ajustaste los detalles ásperos y lanzaste algo real. La gente empezó a usarlo. Y entonces, lento al principio, apareció un patrón en los comentarios: la mitad de tus usuarios quería una cosa y la otra mitad quería algo distinto. No estaban peleando por la misma función. Estaban pidiendo dos productos diferentes.

Este es el momento en que muchos fundadores entran en pánico y arrancan un segundo proyecto desde cero. No deberían. Hay una manera más limpia de dividir una app con IA cuando tu único producto resulta ser dos — y por lo general conserva casi todo lo que ya construiste. Este artículo trata de cómo reconocer la división, cuándo hacerla y las tres formas que suele tomar.

Cómo te enteras de que tienes dos productos

La señal casi nunca parece una solicitud de función. Parece fricción.

Una app de productividad que vi pasar por esto tenía una historia clara. Se vendía como un “planificador personal”. Los usuarios empezaron a aparecer en dos sabores. Un grupo la usaba para organizar su propia semana y la trataba como un cuaderno privado. El otro grupo dirigía equipos pequeños y quería asignar cosas a otras personas. Ambos estaban lo bastante contentos como para seguir usando el mismo producto, pero cada lanzamiento complacía a un grupo y molestaba al otro. El equipo pensó que tenía un problema de priorización de funciones. En realidad tenía un problema de marca. Tenía una app personal y una app de equipo compartiendo un mismo código, una misma página de inicio y una misma página de precios.

Sabrás que cruzaste esa línea cuando empiece a cumplirse alguna de estas cosas:

• Tu landing page tiene que esconder su propuesta real detrás de un lenguaje genérico porque dos audiencias no van a creerse las mismas palabras.
• Cada nueva función trae una salvedad del tipo “pero para el otro tipo de usuario debería funcionar distinto”.
• Tus respuestas de soporte empiezan a ramificarse: “si la estás usando para ti…” frente a “si estás gestionando un equipo…”.
• Una cantidad nada despreciable de usuarios mantiene dos cuentas separadas para mantener separados los dos modos.

Si estás viendo dos o más de esas, no tienes un problema de funciones. Tienes una división de producto esperando a suceder.

Las tres formas de una división

No tienes que elegir una forma el primer día. Por lo general puedes probar primero la más ligera e ir escalando. Pero conviene conocer el menú antes de empezar a describirlo a tu creador con IA, porque las palabras que uses van a moldear lo que se genere.

Forma 1: una app, dos puertas

La versión más ligera. Mantienes un solo código. Agregas una pregunta al primer uso — “¿Estás aquí para ti o para un equipo?” — y usas la respuesta para mostrar un conjunto distinto de páginas y una navegación distinta. Mismo almacén de datos. Mismo inicio de sesión. Misma facturación. Solo una superficie distinta.

La mayoría de los creadores de apps con IA manejan esto bien si lo describes como una “app de dos modos”. Lo que hay que vigilar es que los dos modos no compartan pantallas con mostrar-y-ocultar condicionales por todas partes. Eso termina pareciendo una app recargada que finge ser dos. Dile al creador que las dos puertas son separadas — distintas páginas de inicio, distintas páginas de ajustes, distintos estados vacíos. Las pocas pantallas que sí se solapan (ajustes de cuenta, facturación) pueden compartirse.

Cuándo funciona: cuando las dos audiencias quieren un encuadre distinto pero los mismos objetos de fondo. El ejemplo del planificador frente al equipo encaja aquí. Lo que estás programando sigue siendo una tarea; solo cambian las reglas sobre asignar, compartir y notificar.

Cuándo no funciona: cuando las dos audiencias esperan objetos completamente distintos. Un “portal de clientes” y una “herramienta interna de administración” casi no tienen solapamiento, aunque parezca que tratan del mismo negocio.

Forma 2: dos apps, un mismo backend

La forma intermedia. Divides la parte frontal del producto en dos apps separadas — dos URLs, dos landing pages, dos flujos de incorporación, dos tablas de precios — pero ambas leen de la misma base de datos por debajo. Un cliente puede tener cuenta en las dos. Un administrador puede ver datos de ambas.

Esto es lo que hicimos hace poco en la empresa que publica este blog. Teníamos una sola app tratando de servir a dos audiencias: ingenieros evaluando nuestra plataforma de agentes, y creadores usando nuestro creador de apps con IA. Mismo backend, misma autenticación, misma base de datos — pero el frontend había echado dos cabezas, y el mensaje estaba confuso. Lo dividimos en dos apps de frontend, una para cada audiencia. El backend se quedó exactamente igual.

Esta forma es la respuesta correcta cuando:

• Las dos audiencias compran por razones distintas.
• El texto de marketing de la otra audiencia las confundiría o las alejaría.
• Los datos que les importan tienen casi la misma forma, pero encuadrados distinto.
• No quieres mantener dos bases de datos ni dos configuraciones de facturación.

Dile a tu creador con IA que quieres una “segunda app de frontend que comparta la API existente”. La mayoría de los creadores con IA modernos pueden levantar un proyecto hermano y apuntarlo a tu backend actual. La trampa que hay que evitar: copiar y pegar los componentes de la primera app tal cual y luego editar ambas copias para siempre. Pídele al creador que extraiga las partes compartidas (pantallas de autenticación, widgets de formularios comunes) en una pequeña librería que ambas apps usen. Te vas a ahorrar meses de correcciones duplicadas más adelante.

Forma 3: dos apps, dos backends

La división más pesada. De verdad tienes dos productos. No comparten datos, no comparten usuarios y no deberían compartir hoja de ruta. Lo correcto es separarlos del todo: códigos separados, bases de datos separadas, dominios separados.

Esto es lo correcto menos seguido de lo que la gente cree. Tienta porque se siente limpio. La realidad es que dos apps completamente separadas significan dos de todo que mantener funcionando — dos canales de despliegue, dos guardias de turno, dos integraciones de facturación, dos documentaciones de ayuda. No recurras a esta forma a menos que los productos de verdad no se solapen. Una buena prueba: si un usuario del producto A nunca sería usuario del producto B, probablemente sí necesitas la Forma 3. Si la mayoría de tus usuarios podría plausiblemente querer ambos, casi con seguridad quieres la Forma 2.

Cuando hagas esto con un creador con IA, lo más fácil es copiar tu proyecto existente como punto de partida del segundo, y luego pedirle al creador que quite las funciones que no corresponden y agregue las que sí. No arranques el segundo proyecto desde un lienzo en blanco. Ya aprendiste mucho construyendo el primero, y el creador con IA retomará ese contexto si lo dejas.

Qué hacer antes de dividir cualquier cosa

Antes de describirle la división a tu creador con IA, haz tres cosas pequeñas. Valen más de lo que suenan.

Primero, escribe la nueva página de inicio para cada lado. Dos párrafos cada una. La propuesta, la audiencia, la única cosa que quieres que hagan. Si no puedes escribir dos páginas de inicio distintas, todavía no tienes dos productos — solo tienes dos segmentos de un mismo producto, y eso lo resuelves con mensaje, no con arquitectura.

Segundo, enlista qué pantallas se comparten y cuáles no. Sé honesto. “El inicio de sesión se comparte. La incorporación es distinta. El panel es distinto. Los ajustes se comparten casi todos. La facturación se comparte.” Esa lista se vuelve el brief que le entregas al creador con IA. Te ahorra mucho ir y venir.

Tercero, decide qué es lo mismo por debajo. ¿Mismos usuarios? ¿Mismos datos? ¿Mismos pagos? Cada “sí” te jala hacia la Forma 1 o 2. Cada “no” te jala hacia la Forma 3. No hay respuesta correcta — solo la respuesta que coincide con cómo funciona de verdad tu producto.

Qué cambia después de la división

Dos cosas se vuelven más fáciles y una se vuelve más difícil.

El marketing se vuelve más fácil. Cada app recibe su propia propuesta clara. Cada landing page puede hablarle a una sola audiencia sin titubear. Tu tasa de conversión normalmente sube en al menos un lado, a veces en ambos.

La incorporación se vuelve más fácil. Un usuario primerizo aterriza en una página que trata de él, no en una página que intenta tratar de todos.

Lo que se vuelve más difícil es mantener sincronizadas las partes compartidas. Si corriges un bug en el flujo de inicio de sesión, lo quieres corregido en ambas apps. Si cambias cómo se ve la pantalla de facturación, quieres que ambas apps lo reflejen. La disciplina que necesitas — y esto es cierto lo mismo si estás haciendo vibe coding con un creador con IA que si construyes con un equipo de desarrolladores humanos — es mantener las partes compartidas genuinamente compartidas. No dupliques. No bifurques. O extraes la pantalla compartida en una pequeña librería que ambas apps usen, o aceptas que tienes dos apps verdaderamente separadas y asumes eso.

Una pequeña pregunta para cerrar

Si pasaras la propuesta de tu app actual frente a cinco desconocidos y cada uno la describiera distinto — pero en dos cubetas bien diferenciadas — probablemente ya estás viviendo con la división. La única pregunta es si sigues pagando el impuesto de un solo producto confuso, o haces el trabajo de ser honesto sobre que son dos.

No tienes que decidirlo hoy. Pero la próxima vez que tu creador de apps con IA pregunte “¿qué construyo a continuación?”, considera que la respuesta más útil quizá no sea una nueva función. Quizá sea una nueva puerta de entrada.

Si esto te resonó, también podría gustarte nuestro artículo anterior sobre construir para tu equipo frente a construir para clientes — el mismo sabor de decisión, un paso antes en la vida de tu producto.