Resumen. Un bot de Telegram con una base de usuarios real y un backend detrás puede convertirse en una app publicada de iOS y Android en unas seis semanas, no porque el trabajo sea trivial, sino porque la pregunta difícil de producto (¿esto lo quiere alguien?) ya está respondida. Este artículo es el plan semana a semana: qué se construye cuándo, adónde van realmente las seis semanas, cómo migras 50.000 usuarios sin perderlos y las cosas concretas que convierten seis semanas en cuatro meses. Si prefieres autoevaluarte primero, la página del servicio de chatbot a app tiene una lista de comprobación.

Si solo quieres el calendario, salta al plan de seis semanas.

El escenario

Imagina la posición en la que estás, que es buena. Lanzaste un bot de Telegram hace un año o dos para probar una idea. Funcionó. Ahora tienes 50.000 usuarios que lo abren, lo usan y de vez en cuando pagan por él. El bot hace algo real: un entrenador de fitness, un asistente de IA, un control de finanzas, un profesor de idiomas, un marketplace; la categoría da igual para este artículo. Lo que importa es que tienes en una plataforma que no es tuya.

Y la plataforma empieza a doler. Los usuarios piden cosas que el bot no puede hacer. No puedes enviar una notificación push sin que aterrice en un canal silenciado. No puedes cobrar como quieres. Un cambio en la API de bots de Telegram rompió un flujo el trimestre pasado y te pasaste un fin de semana apagando fuegos. Tienes éxito a pesar de la plataforma, y notas el techo.

Así que quieres una app. La pregunta que hace todo fundador en esta posición es la misma: ¿cuánto tarda y cómo no perdemos los 50.000 usuarios que ya tenemos?

La respuesta honesta para una clase amplia de bots es seis semanas hasta una app lanzada, más una migración gradual que corre en paralelo y termina cuando tú decides que ha terminado. Esta es la razón por la que ese número es realista, y exactamente adónde va el tiempo.

El recorrido de abajo es un compuesto: es el plan que hemos ejecutado, por partes, en desarrollos Flutter reales muy orientados al chat como Arcana (un cliente de chat con IA en streaming entregado en tres semanas) y YouMi (una app de mensajería en tiempo real que estabilizamos en dos). Ningún cliente concreto es «el bot de 50k», pero cada paso de aquí es algo que hemos hecho de verdad.

Por qué seis semanas es realista (y cuándo no lo es)

Seis semanas suena agresivo hasta que recuerdas lo que no estás haciendo.

No estás descubriendo el producto. No estás haciendo investigación de usuarios para averiguar qué construir: tu bot son dos años de investigación de usuarios. No estás diseñando un modelo de interacción nuevo: el flujo conversacional ya funciona y vas a conservar buena parte de él. No estás validando la demanda: 50.000 personas ya la validaron.

Lo que queda es ejecución contra una especificación conocida, y esa es la parte que se comprime. Una única base de código en Flutter llega a iOS y Android a la vez (hemos escrito sobre por qué una base de código gana a dos desarrollos nativos), así que no pagas dos veces por el mismo trabajo. El backend en su mayor parte ya existe. La lista de funcionalidades es finita y ya está probada en producción.

Seis semanas es realista cuando:

  • Tu bot ya habla con una API de backend, no solo con los servidores de Telegram.
  • El conjunto de funcionalidades es centrado en el chat más un puñado de pantallas, no una superapp desperdigada.
  • Tienes una sola persona que decide y que puede aprobar diseños y alcance sin un comité.
  • Estás dispuesto a lanzar una v1 enfocada y añadir la cola larga después de que la app esté en producción.

Seis semanas no es realista cuando el bot no tiene backend separado y toda la lógica vive dentro de los manejadores del bot (súmale 2-3 semanas para extraer una API), cuando necesitas un sistema de diseño a medida desde cero, o cuando «paridad» significa en secreto cincuenta comandos de casos límite que necesitan cada uno su propia pantalla. Volveremos a esto en qué revienta el calendario.

El plan de seis semanas, semana a semana

Este es el calendario que seguimos. Las semanas se solapan más de lo que sugiere esta lista lineal —el diseño empieza mientras termina la auditoría, el papeleo de las tiendas empieza el primer día— pero el camino crítico tiene esta pinta.

Semana 1 — Auditoría y mapeo de funcionalidades

Recorremos el bot comando a comando, flujo a flujo, y anotamos todo lo que hace. Cada /comando, cada teclado en línea, cada conversación de varios pasos, cada integración, cada camino de pago. Esto se convierte en la especificación, y es el artefacto más importante de todo el proyecto.

Después mapeamos cada capacidad del bot a su equivalente en la app y la clasificamos en tres cubos:

  • Mantener como chat. El núcleo conversacional sigue siendo conversacional: es lo que tus usuarios conocen.
  • Promover a pantalla. Las cosas que metiste a presión en el chat porque el bot te obligaba (ajustes, historial, cuadros de mando, perfiles) se convierten en pantallas de verdad.
  • Cortar de la v1. Los comandos que toca el 2 % de los usuarios. Van a la lista de después del lanzamiento, no al camino crítico.

Ese tercer cubo es donde se ganan o se pierden las seis semanas. El resultado de la primera semana es un alcance firmado: una lista concreta de qué sale en la v1.

Semana 2 — Arquitectura y la cuestión de la API

La app necesita hablar con un backend. El mejor caso es que tu bot ya lo haga y que la app simplemente llame a los mismos endpoints. Diseñamos la arquitectura del cliente alrededor de tu API existente —autenticación, modelos de datos, canales en tiempo real— sin reescribir el backend.

Si tu bot no tiene backend separado (toda la lógica dentro de los manejadores de Telegram), aquí es donde extraemos una capa de API ligera para que el bot y la app puedan compartirla. Es la única situación que añade tiempo de forma legítima, y la señalamos el primer día en vez de descubrirla en la semana cuatro.

Esta semana también deja cerrados los dos subsistemas que hunden en silencio a las apps de chat:

  • Mensajería en tiempo real: un ciclo de vida de WebSocket en condiciones, con reconexión, encolado de mensajes y sincronización de estado. Hacer esto mal es exactamente lo que nos llamaron a arreglar en YouMi, donde los usuarios se caían a mitad de conversación. Es poco vistoso y es la diferencia entre una app que funciona y una que funciona cuando no falla nada.
  • Notificaciones push: APNs y FCM conectados pronto, porque las notificaciones son la mitad del motivo por el que te vas de Telegram.

Semanas 3-4 — Construir el núcleo

Este es el tramo más pesado: la app en sí. En una única base de código Flutter, el equipo construye:

  • La interfaz de chat: scroll fluido sobre miles de mensajes, medios enriquecidos, respuestas en streaming si tu bot está respaldado por IA (el renderizado incremental de Markdown que construimos para Arcana vive aquí).
  • La autenticación: teléfono, correo o login social, mapeado a las identidades de usuario existentes para que las cuentas se traspasen.
  • Las pantallas promovidas de la semana uno: cuadros de mando, historial, ajustes, perfiles.
  • Las notificaciones push de principio a fin, en tu calendario y en tus términos.

Recibes una build de demostración al final de cada semana. No un correo de estado: una build instalable en un dispositivo real. Esto no es negociable: las builds semanales son la forma de detectar el aumento de alcance mientras arreglarlo es barato.

Semana 5 — Fontanería de migración y preparación de tiendas

Ahora la parte que es propia de migrar en vez de construir de cero. Tres cosas van en paralelo:

  • Vinculación de cuentas. Un usuario abre la app y demuestra que es la misma persona que usaba el bot, normalmente con un de un toque desde el bot que lleva un token firmado, o con un emparejamiento por teléfono o correo. Su historial y sus datos vienen con él.
  • Envío a las tiendas. Fichas de App Store y Google Play, capturas, declaraciones de privacidad, envío a revisión. La cola de revisión de Apple es la única dependencia externa que no puedes controlar del todo, y por eso esto empieza ahora y no en la semana seis.
  • El puente dentro del bot. El propio bot se convierte en tu mejor canal de captación. Añadimos un flujo de anuncio y deep links para que los 50.000 usuarios se enteren de la app dentro de la herramienta que ya abren todos los días.

Semana 6 — Lanzamiento y comienzo de la migración

La app sale a producción. Pero «lanzamiento» no significa un corte brusco, y esta es la parte que más preocupa a los fundadores, así que seamos precisos.

No apagas el bot. El bot sigue funcionando. El día del lanzamiento empieza a empujar a los usuarios hacia la app con un deep link, pero quien lo ignore sigue usando el bot exactamente como antes. Nadie se queda fuera, nada se rompe y tus 50.000 usuarios no se van por una migración forzada.

La migración se convierte en un dial que giras en las semanas siguientes: un banner, luego un aviso más suave, luego funcionalidades exclusivas de la app que atraen a la gente por sí solas. Muchos productos mantienen un bot simplificado de forma permanente como segundo punto de entrada. Tú decides el ritmo; lo que entrega la semana seis es que la app esté en producción desde el primer día.

Cómo no perder 50.000 usuarios

Esto merece su propia sección porque es el miedo real, y la mecánica es sencilla en cuanto la ves.

  1. Funcionamiento en paralelo, no un corte. Bot y app conviven. Nunca hay un momento en que la única opción de un usuario sea «descarga la app o pierde el acceso».
  2. El bot es el canal de migración. No estás comprando anuncios para encontrar a estos usuarios: ya hablan contigo todos los días. Un deep link en el bot convierte mucho mejor que cualquier campaña de instalación en frío, y es gratis.
  3. Las cuentas y el historial se traspasan. Los tokens de deep link o el emparejamiento por teléfono o correo hacen que el usuario inicie sesión y encuentre sus datos ya ahí. La app se siente como una mejora, no como empezar de cero.
  4. Incentivos graduales, no obligación. Las funcionalidades exclusivas de la app, mejores notificaciones y una experiencia más agradable atraen a la gente. Empujarla con una fecha límite dura empuja a algunos fuera del todo.

Hecho así, la migración no es un evento arriesgado: es una curva que controlas, y el bot se queda de red de seguridad todo el tiempo.

Qué convierte seis semanas en cuatro meses

Honestidad sobre los modos de fallo, porque son predecibles:

  • No hay backend con el que hablar. Si toda la lógica vive dentro de los manejadores de Telegram sin ninguna API, extraer una añade 2-3 semanas. Merece la pena hacerlo —es el cimiento sobre el que se apoya todo lo demás— pero es tiempo real.
  • «Paridad» significa todo. Insistir en que la v1 lleve los 60 comandos, incluidos los que toca el 2 % de los usuarios, es el asesino de calendarios más habitual. Publica el núcleo y añade la cola después del lanzamiento.
  • Diseño desde una página en blanco. Un sistema de diseño a medida inventado durante el desarrollo añade semanas. Un diseño limpio y convencional aplicado a un flujo conocido no.
  • Decisión por comité. Seis semanas asume que alguien puede aprobar una pantalla el día que la ve. Si cada decisión espera una semana a una reunión, es el calendario —y no la ingeniería— quien marca el ritmo.
  • Un rescate, no un desarrollo. Si ya hay una app a medio hacer que se está rompiendo, arreglar problemas heredados es un trabajo distinto de empezar limpio: esa es la situación de YouMi, y se presupuesta aparte.

Ninguno de estos es un misterio. Los sacamos a la luz en la semana uno, que es justamente el sentido de empezar con una auditoría y no con un diagrama de Gantt.

Cuánto cuesta

Una migración directa con este calendario —funcionalidades principales conservadas, interfaz de chat, autenticación, notificaciones push, publicación en tiendas y migración de usuarios— se sitúa en el rango de 4000-8000 € a lo largo de cuatro a seis semanas. Los bots con muchas funciones, con pagos, soporte sin conexión y pantallas a medida salen más caros y más largos; los bots respaldados por IA con streaming y renderizado en tiempo real, todavía más. El desglose completo por niveles está en la página del servicio de chatbot a app, y el marco de costes explica cómo se acumula el alcance hasta dar la cifra final.

Lo que conviene interiorizar: la parte cara de construir una app es encontrar el encaje producto-mercado, y esa factura ya la pagaste con tu bot. La migración es la parte barata. Estás convirtiendo demanda validada en un producto que es tuyo, y esa es una posición de partida mucho mejor que la del fundador mirando un archivo de Figma en blanco y adivinando qué construir.

Preguntas frecuentes

Un bot sencillo con un backend funcionando puede publicarse como app de iOS y Android en unas seis semanas. Los bots con muchas funciones, con pagos, soporte sin conexión o streaming de IA suelen llevar de dos a cuatro meses. El calendario depende sobre todo de si el bot ya tiene una API de backend separada y de cuánta parte del conjunto de funcionalidades tiene que salir en la versión uno.
No si migras de forma gradual. El bot sigue funcionando junto a la app, así que ningún usuario se queda fuera nunca. El propio bot se convierte en el canal de migración: un deep link dentro de él convierte mucho mejor que la publicidad de pago, y las cuentas y el historial se traspasan, de modo que la app se siente como una mejora y no como empezar de cero.
Normalmente no. Si tu bot ya habla con una API de backend, la app llama a los mismos endpoints sin reescribir nada. Solo cuando toda la lógica vive dentro de los manejadores de Telegram sin backend separado hace falta extraer primero una capa de API ligera, lo que añade unas dos o tres semanas.

Una migración directa con las funcionalidades principales, chat, autenticación, notificaciones push y publicación en tiendas se sitúa en torno a 4000-8000 €. Los bots con muchas funciones y los respaldados por IA cuestan más. Como el bot ya demostró la demanda, la parte más cara de construir una app ya está pagada.

Sí. La mayoría de los productos mantiene un bot simplificado funcionando de forma permanente como segundo punto de entrada. El lanzamiento no es un corte brusco: el bot va empujando a los usuarios hacia la app con el tiempo mientras sigue siendo plenamente funcional para quien todavía no se haya cambiado.
Flutter llega a iOS y Android desde una sola base de código, lo que recorta tiempo y coste en torno a un 40-50 % frente a dos desarrollos nativos, sin penalización de rendimiento. Es especialmente fuerte para apps muy orientadas al chat que necesitan scroll fluido, actualizaciones en tiempo real y renderizado de medios enriquecidos.

::

Empieza por la lista de comprobación

Antes de una sola línea de código, pasa tu bot por la lista de comprobación para migrar de la página del servicio. Te dice, con honestidad, cómo de cerca estás realmente de una migración limpia de seis semanas, y dónde te van a costar tiempo los huecos.

Si tienes un bot con usuarios reales y estás notando el techo de la plataforma, reserva una llamada de descubrimiento. Pasaremos tu bot por la auditoría, te diremos qué semanas serán fáciles y cuáles difíciles, y te daremos un presupuesto de alcance cerrado, no una conjetura.