La frase "cualquiera puede hacer una app" lleva diez años siendo mentira. Lo que salía de las herramientas sin código era una maqueta bonita que no guardaba nada, no tenía usuarios y no cobraba. Servía para enseñársela a un amigo y nada más.
Eso cambió. Hoy describes lo que quieres en español y sale una aplicación con base de datos, registro de usuarios y cobros. Funcionando de verdad, en una dirección pública, en una tarde.
Esta guía es el recorrido completo para alguien que nunca ha programado: de la idea a la app en vivo. Voy a usar Lovable porque es la que más rápido lleva a alguien sin experiencia a algo real, pero el método sirve igual con las demás.
Antes de abrir la herramienta: la idea
El 90% de los proyectos mueren aquí, no en la parte técnica. Y mueren por lo mismo: la idea era demasiado grande. Nadie sin experiencia debería empezar por "una red social para X".
Cuatro preguntas para encontrar algo del tamaño correcto:
- ¿Qué te molesta cada semana en tu trabajo y sigues resolviendo a mano?
- ¿Qué tarea manual estás haciendo en una hoja de cálculo que ya no debería vivir en una hoja de cálculo?
- ¿Qué buscas en internet una y otra vez sin encontrar nada decente?
- ¿De qué se queja la gente de tu gremio cuando se juntan?
Un dolor chico resuelto bien es un negocio. Un dolor grande resuelto a medias no es nada. La primera app de casi todo el mundo debería ser algo que resuelve un problema que tú mismo tienes, porque eres el único usuario al que puedes entrevistar gratis.
Lo que cuesta
Hay un plan gratuito con unos pocos créditos diarios: alcanza para probar la herramienta y ver salir la primera versión, no para terminar un producto. El plan de pago ronda los 25 dólares al mes y es el que da capacidad real de construcción. Súmale unos doce dólares al año si quieres tu propio dominio.
Es una cuenta razonable para lo que estás comprando. Pero no pagues el mes hasta que hayas gastado los créditos gratis y sepas qué se siente iterar.
El primer prompt: la parte que sí importa
Aquí se decide casi todo. Un prompt vago produce una app genérica que después tienes que corregir veinte veces, y cada corrección cuesta créditos. Esta es la estructura que uso:
Estoy construyendo "[NOMBRE DE LA APP]", una [tipo de app] para
[usuario objetivo].
El problema que resuelve: [una sola frase].
Páginas que necesito:
- Registro e inicio de sesión (correo y contraseña)
- [Página principal]
- [Página de detalle]
- Configuración y perfil
Funciones del primer lanzamiento:
- [Función 1]
- [Función 2]
- [Función 3]
Estilo: [descripción en pocas palabras]. Usa [color] como principal.
Antes de construir nada, hazme las preguntas que necesites para no
suponer.La última línea es la más importante de todo el prompt. Sin ella, la herramienta asume y construye; con ella, pregunta primero. Cada pregunta que te hace antes de construir es una ronda de correcciones que te ahorras después.
El paso que todo mundo se salta: apretar la seguridad de la base de datos. La primera versión sale con permisos abiertos, porque así es más fácil que todo funcione mientras construyes. Cuando la app ya haga lo que quieres, antes de enseñársela a nadie, escribe: "Aprieta la seguridad de la base de datos para que cada usuario solo pueda ver sus propios datos". Si te saltas esto y la app guarda información de otras personas, estás publicando los datos de tus usuarios.
Cómo se itera sin quemar créditos
La primera versión sale en minutos y va a estar a un 70% de lo que querías. Eso es normal. La forma de cerrar el 30% restante es la que separa a quien termina de quien abandona.
- Un tema por mensaje. "Cambia los botones a azul, agrega la sección de equipos y arregla el correo de bienvenida" sale mal las tres cosas. Uno a la vez.
- Describe el comportamiento, no la solución técnica. "Cuando el usuario borra un proyecto, pídele confirmación" funciona mejor que intentar decirle cómo programarlo.
- Prueba después de cada cambio. La vista previa está en vivo. Si acumulas cinco cambios y algo se rompió, no vas a saber cuál fue.
- Cuando algo falle, pega el error tal cual. Copiar el mensaje de error completo resuelve más rápido que describirlo con tus palabras.
Un ejemplo que no es de juguete
La app que más veces he visto funcionar como primer proyecto no es de consumidor: es interna. Una distribuidora con veinte vendedores que llevaban su seguimiento en una hoja compartida que se rompía cada semana. La app tenía tres pantallas: alta de cliente, registro de visita con foto y notas, y un tablero para el gerente con quién visitó a quién esta semana.
Eso es todo. Nada de inteligencia artificial adentro, nada de gráficas, nada de aplicación móvil. Salió en una tarde, y resolvió un problema que llevaba dos años sin resolverse porque cotizarlo con un desarrollador costaba más de lo que la empresa estaba dispuesta a pagar por un dolor que "se aguantaba".
Ese es el tamaño correcto de una primera app: algo que ya existe en una hoja de cálculo y que se rompe seguido. Ahí el problema está probado, el usuario está identificado y nadie te va a pedir que se vea como una app de Silicon Valley.
Base de datos, usuarios y cobros
La base de datos y el inicio de sesión suelen quedar conectados desde el primer prompt: no tienes que pedirlos aparte. Los cobros sí hay que pedirlos, y se piden así de directo:
Conecta Stripe para que pueda cobrar [monto] al mes por usuario. Que
haya un plan gratuito limitado a [límite] y un plan de pago sin ese
límite. Después de pagar, el usuario debe entrar directo a la app.Cobra desde el primer día aunque sean diez dólares al mes. No por el dinero: porque un usuario que paga te dice la verdad sobre si tu producto sirve, y un usuario gratis no. Cien registros gratuitos no valen lo que valen tres clientes que pagan.
Publicar
Un botón. Queda en una dirección del tipo tuapp.lovable.app, con hospedaje incluido y sin configurar nada. Si quieres tu propio dominio, se conecta desde la configuración del proyecto.
Y hay una salida importante: puedes exportar el código a GitHub y publicarlo desde Vercel o Netlify. Eso significa que no estás encerrado. El día que la app crezca lo suficiente para que la tome un programador, el código es tuyo y se lo puedes entregar.
Dónde no llega, dicho sin rodeos
Tres límites que conviene saber antes y no después.
No hace apps nativas de teléfono. Hace aplicaciones web que se ven bien en el celular. Para la mayoría de las ideas eso alcanza; si tu idea necesita cámara, notificaciones nativas o estar en la tienda de aplicaciones, no es el camino.
El diseño sale funcional y genérico. Reconocible como hecho con IA. Sirve perfecto para validar; si vas a cobrar caro, vas a querer que alguien le dé una pasada.
El plan gratis no alcanza para terminar nada. Alcanza para la primera versión y unas cuantas correcciones. Si tu plan es lanzar sin pagar un peso, este no es tu camino.
El error real, y no es técnico
Lo que veo una y otra vez: la gente construye durante tres semanas y no le enseña la app a nadie hasta que está "lista". Nunca está lista. Y cuando por fin la enseñan, descubren que el problema que resolvieron no le dolía a nadie más que a ellos.
El orden que sí funciona es al revés. Antes de construir, habla con diez personas que tengan el problema. Construye la versión más pequeña que se los resuelva. Enséñasela a esas diez el día que funcione, aunque esté fea. Cobra desde el principio.
La parte difícil de hacer un producto nunca fue programarlo. Era eso, y sigue siendo eso. La herramienta te quitó el obstáculo técnico; el obstáculo que queda es el de siempre. Si quieres ver cómo se ve esto convertido en ingreso, está en esta guía.