Crear una app con IA sin saber programar: la realidad (y los costes ocultos) detrás de Base44 y similares

Es difícil no toparse estos días con un anuncio de Base44, Lovable, Bolt o alguna plataforma parecida prometiendo que cualquiera puede tener su propia aplicación "solo describiendo la idea", sin escribir una sola línea de código. El mensaje es tentador: escribes lo que quieres construir, la IA lo genera en minutos, y en poco tiempo tienes un producto funcionando. Es una promesa dirigida directamente a quien nunca ha programado y probablemente nunca lo hará: emprendedores, autónomos, pequeños negocios, gente con una idea pero sin presupuesto para contratar a un desarrollador.

Hay que decirlo con honestidad: buena parte de esa promesa es real. Estas plataformas funcionan, y funcionan sorprendentemente bien para lo que hacen. El problema no está en si "funcionan" o no, sino en la distancia entre lo que el anuncio deja entender y lo que ocurre después del primer prototipo: cuánto cuesta de verdad seguir adelante, quién controla lo que se ha construido, y si esa aplicación llega a ser realmente tuya cuando termina el proceso. Después de probar varias de estas herramientas, creo que merece la pena analizar con calma cómo funcionan de verdad, para que cualquiera que se lo plantee sepa a qué atenerse.

Cómo funciona el proceso, en la práctica

Cuando te registras en una de estas plataformas, el punto de partida es un cuadro de texto. Describes lo que quieres —"una app para gestionar las reservas de mi peluquería", "una web donde mis clientes puedan pedir presupuestos"— y la IA interpreta esa descripción, genera una base de datos, una interfaz y la lógica necesaria, y en cuestión de minutos tienes algo visible y, hasta cierto punto, funcional.

Esa primera fase es la que se ve en los anuncios, y no exagera demasiado: es rápida y el resultado sorprende a cualquiera que no lo haya visto antes. Lo que no se suele contar es lo que pasa después. La primera versión suele quedarse en un 70-80% de lo que realmente hace falta, y ese último tramo —que un botón haga exactamente lo que debe, que los datos se guarden bien, que la app no se rompa con un caso que no se había previsto— es el que más cuesta cerrar. Con formación técnica, ese tramo final se resuelve con relativa rapidez: se entiende el error, se sabe qué preguntar, se reconoce cuándo la IA está dando vueltas sobre el mismo fallo sin avanzar. Sin esa formación, ese mismo tramo puede consumir semanas de prueba y error.

De gratis a la suscripción: cómo se paga esto en realidad

Todas estas plataformas siguen un guion parecido. Empiezas gratis, con un número limitado de "créditos" o interacciones con la IA, suficiente para hacerte una idea de si la herramienta sirve para lo que quieres. En cuanto quieres seguir avanzando —dar más instrucciones, corregir cosas, añadir funciones— esos créditos se agotan y aparece la propuesta de pasar a un plan de pago.

En el caso de Base44, la estructura de precios (con la tarifa anual, más barata que pagar mes a mes) queda aproximadamente así:

Plan	Precio (facturación anual)	Qué desbloquea
Free	0 $	Créditos muy limitados, solo para probar
Starter	~16 $/mes	Proyectos personales, MVP básicos
Builder	~40 $/mes	Dominio propio y exportación a GitHub
Pro	~80 $/mes	Más créditos, apps con más tráfico
Elite	~160 $/mes	Uso intensivo, soporte prioritario

Lo importante no es tanto la cifra exacta —cambia con cierta frecuencia— como el patrón: hasta llegar al plan Builder no tienes ni dominio propio ni la posibilidad de sacar el código a un repositorio. Sigues dependiendo por completo de la plataforma.

El coste oculto de los "créditos por uso"

Además del precio del plan, hay un segundo medidor que muchos usuarios no descubren hasta que lo sufren: los créditos no solo se gastan al construir la app, sino también cuando la usan las personas a las que se la enseñas. Cada llamada a la IA, cada integración (un correo automático, una llamada a otro servicio, una imagen generada) consume crédito. El coste real, por tanto, no depende solo del plan elegido, sino de cuánta gente acabe usando la aplicación.

Y esto no es exclusivo de Base44. Otras plataformas históricas y emergentes del sector rondan precios de entrada similares donde casi nunca se refleja el coste real de tener algo publicable y usable.

Publicar la aplicación: los gastos externos

Incluso una vez terminada la app, publicarla tiene costes propios, ajenos a la plataforma que la ha construido. Si decides sacarla al mundo real, tendrás que asumir:

• Apple App Store: Exige una cuota de 99 dólares al año para mantener una cuenta de desarrollador individual (299$ si es empresa). Si dejas de pagar, la aplicación desaparece.
• Google Play Store: Es más asequible, con un pago único de 25 dólares para abrir la cuenta de desarrollador, sin renovaciones posteriores.
• Dominio y almacenamiento: Si se trata de una web app, necesitarás un dominio propio (generalmente no incluido en los planes básicos) y capacidad para soportar el tráfico de tus usuarios.

¿De quién es realmente la aplicación cuando termina el proceso?

Esta es la pregunta más importante y la que menos se explica. La sensación que transmiten estos anuncios es la de estar "creando tu propia app", como si al terminar tuvieras algo tan tuyo como un documento en tu ordenador. La realidad es bastante distinta.

En la mayoría de plataformas, lo que queda al terminar no es un programa que se pueda copiar y llevar sin más a otro servidor: es una aplicación que vive dentro de la infraestructura de la plataforma y que solo funciona ahí. Algunas permiten exportar el código, pero esa exportación se lleva solo la parte visible, no la base de datos ni la lógica de fondo. Exportar no es poseer. Rehacer esa conexión requiere justo los conocimientos técnicos que te prometieron que no harían falta.

Al final, el único escenario donde tienes el control absoluto de la arquitectura de tu proyecto es cuando lo construyes desde cero con tecnologías nativas —escribiendo tu propio HTML, estructurando tu base de datos relacional en MySQL y definiendo la lógica de servidor con PHP o JavaScript puro—. Al depender de la infraestructura de terceros, delegas esa propiedad y te expones a quedarte atrapado en su ecosistema (el temido vendor lock-in). Si la plataforma entra en insolvencia, es comprada por otra gran empresa, o simplemente decide cambiar sus tarifas de un día para otro, no tienes ningún control sobre esas decisiones y puedes llegar a perder tu producto por completo.

Los riesgos que la publicidad no cuenta: la seguridad

Programar bien no consiste solo en que la app "funcione" de cara al usuario. Gran parte del trabajo real está en cosas invisibles: quién puede acceder a qué datos o cómo se verifica que un usuario es quien dice ser. Es precisamente el terreno que una persona sin formación no puede evaluar.

Esto no es un riesgo teórico. Recientemente se descubrió un fallo de seguridad grave en una de las plataformas líderes que permitía a cualquiera registrarse y acceder a aplicaciones privadas ajenas —algunas con información empresarial sensible— simplemente conociendo un identificador público en la URL. Aunque se corrigió rápido, el episodio es revelador: al construirse miles de aplicaciones sobre la misma infraestructura compartida, un único fallo afecta a todas a la vez. De hecho, análisis recientes del sector coinciden en que casi la mitad del código que genera hoy la IA contiene alguna vulnerabilidad de seguridad que un desarrollador experto detectaría, pero un usuario inexperto no.

Entonces, ¿para quién tiene sentido esto de verdad?

Para probar una idea rápido, montar una herramienta interna sencilla para el día a día, o simplemente visualizar una aplicación antes de dar un paso mayor, estas herramientas son extraordinariamente útiles. Como banco de pruebas, cumplen con creces.

El problema aparece cuando esa "app de prueba" se convierte en el producto real: la herramienta con la que un negocio gestiona sus clientes o cobra pagos. Ahí entran en juego factores críticos: subidas de precio, brechas de seguridad o la necesidad de cambiar de proveedor. Son preguntas que solo se pueden responder con criterio técnico, y ese criterio es justo lo que el anuncio promete que no va a hacer falta.

En resumen

Si te planteas usar una de estas plataformas, hazlo con las expectativas ajustadas: sirven muy bien para prototipos y herramientas internas; sirven bastante peor como base de un producto escalable con datos reales. Y conviene tener presente el coste completo antes de empezar: no es solo la cuota mensual, sino los créditos por uso, las licencias de las tiendas de apps y, lo más difícil de cuantificar, lo que costaría salir de la plataforma el día que haga falta. Tenerlo claro desde el principio evita disgustos cuando el proyecto empieza a crecer.