Crear una web app con IA ya no es una barrera técnica, es un problema de criterio. Puedes montar una aplicación funcional sin tocar código, pero si no entiendes qué estás construyendo, lo único que tendrás es una demo bonita que no sirve para nada.
Lo que realmente cambia aquí no es la tecnología, es el enfoque. Pasas de depender de desarrolladores a poder construir, validar y lanzar tus propias herramientas. Eso abre negocio, automatización y producto. Pero también expone algo: la IA no piensa por ti. Si no sabes lo que quieres, te devuelve basura bien presentada.
Qué puedes construir con IA (y qué no)
Puedes construir aplicaciones web funcionales sin escribir código, pero eso no significa que puedas construir cualquier cosa. La IA responde bien cuando el problema está acotado: calculadoras, herramientas internas, pequeños SaaS, landings interactivas o apps con lógica clara. Ahí es donde realmente aporta velocidad y reduce fricción.
El límite aparece cuando hay complejidad real: sistemas con múltiples usuarios, seguridad crítica, lógica avanzada o arquitecturas complejas. En esos casos, la IA no sustituye desarrollo, solo lo acelera. Pensar que puedes montar un SaaS robusto con un par de prompts es una fantasía bastante extendida.
Aquí está el punto importante: la IA ejecuta, pero no decide. Si la idea es débil o mal planteada, el resultado será igual de débil. Lo que construyes depende más de tu criterio que de la herramienta que uses.
Herramienta elegida: por qué usar Horizons (y cuándo no)
Horizons funciona porque reduce todo a lo esencial: le dices lo que quieres y te devuelve una aplicación que puedes probar, modificar y exportar. Para el 80-90% de casos simples o intermedios, es más que suficiente y te ahorra una cantidad absurda de tiempo.
El problema aparece cuando necesitas un mayor control. Si hay base de datos compleja, autenticación, lógica sensible o integraciones críticas, Horizons se queda corto. No porque sea mala herramienta, sino porque no está diseñada para ese nivel de profundidad.
Por eso la elección no va de cuál es “mejor”, sino de cuándo usar cada una. Horizons es rápido, práctico y directo. Cuando el proyecto escala o exige más precisión, necesitas salirte de ahí y usar herramientas más potentes o directamente desarrollo tradicional.
Caso real: app para calcular el valor de oro
Para esta guía no se ha usado un ejemplo teórico ni una demo vacía. Se ha construido una herramienta real: una aplicación web que permite estimar cuánto puedes recibir al vender tus joyas de oro en función de su peso, quilataje y el precio actual del mercado. Ohmygold.net es una herramienta creada por y para esta guia.
La diferencia es importante. No estás viendo una interfaz bonita generada por IA sin propósito, estás viendo una herramienta que responde a una necesidad concreta. Alguien tiene oro, quiere venderlo y no sabe si la oferta que le hacen es justa. Esta aplicación le da una referencia clara para empezar a negociar con criterio.
Este tipo de caso es ideal para entender cómo usar IA de forma práctica. La lógica es sencilla pero útil, no requiere una arquitectura compleja y permite centrarse en lo importante: definir bien el problema y construir una solución funcional. No hay humo, hay utilidad directa.
Además, este enfoque deja claro cómo deberías plantear cualquier web app con IA. No se trata de “crear algo porque se puede”, sino de construir herramientas que tengan sentido fuera del entorno técnico. Si nadie usaría esa aplicación en la vida real, da igual lo bien que esté hecha.
Aquí la IA no está haciendo magia, está ejecutando una idea bien definida. Y ese es el punto clave de toda esta guía: cuando el problema está claro, la herramienta responde. Cuando no lo está, lo único que obtienes es ruido bien empaquetado.
Paso 1: acceso a la herramienta y coste
El punto de entrada es simple: necesitas acceso a una herramienta que te permita generar la aplicación con IA. En este caso se utiliza Horizons, que funciona bajo un modelo de suscripción mensual. Pagas una cantidad baja (en torno a unos 10–12 euros) y tienes un número limitado de interacciones para construir tu app. Obviamente, si usas nuestro enlace, te hemos conseguido un 20% de descuento.
Aquí hay que entender bien qué estás comprando. No estás pagando por una web terminada, estás pagando por capacidad de ejecución. Es decir, por poder iterar, probar, corregir y ajustar lo que la IA va generando. Si entras pensando que en tres mensajes tendrás una aplicación lista, estás mal enfocando el proceso.
Además, este coste tiene sentido solo si lo usas con criterio. Si entras, generas una app y no la exportas, te quedas atado a la herramienta. Si exportas el código, puedes dejar de pagar y trabajar sobre esa base sin depender de la plataforma. Ese es el movimiento inteligente.
Paso 2: Momento prompting (no copiar prompts)
El prompting no se ejecuta, se construye. No trabajas con una instrucción cerrada, trabajas con una secuencia de decisiones. Cada mensaje tiene una función concreta y prepara el siguiente paso. Si no estructuras eso, pierdes control y el resultado se degrada rápido.
En este caso, la estructura es clara y replicable. Primero se define el diseño: interfaz, secciones, textos, flujo de usuario. Solo capa visual, sin lógica. Esto permite validar rápido si la app tiene sentido antes de invertir tiempo en lo importante.
Después se introduce el núcleo de la aplicación. En la app de oro, esto es el sistema de cálculo: cómo se transforma el peso y el quilataje en un rango de precios realista. Aquí no se improvisa. Es donde está el valor de la herramienta y donde más errores suelen aparecer si no tienes claro lo que estás haciendo.
El siguiente paso es integrar datos externos, como la API del precio del oro. Esto conecta la lógica con la realidad. Sin ese dato actualizado, todo lo anterior se queda en una simulación. Aquí ya empiezas a tener una aplicación que responde a condiciones reales.
A partir de ahí entran capas secundarias pero necesarias: SEO básico, aspectos legales, optimización y pequeños ajustes. No construyen el producto, pero lo hacen usable y publicable. Y entre cada uno de estos pasos hay correcciones, ajustes y decisiones que afinan el resultado.
Esto no es opcional. Si no trabajas así, la IA mezcla diseño, lógica y datos en un mismo bloque y te devuelve algo genérico. Cuando separas cada parte, la calidad sube porque cada instrucción tiene foco. Ese es el cambio: dejar de pedir resultados y empezar a construirlos paso a paso.
Ejemplo práctico
Antes de entrar en los prompts, es importante que entiendas algo: esto no va de escribir instrucciones sueltas, va de estructurar el proceso. A continuación te dejo un ejemplo de la arquitectura que he utilizado yo, resumida para que veas cómo se organiza de verdad el prompting en una web app.
No es una plantilla para copiar, es una referencia para entender el orden y la lógica detrás de cada paso. Si no estructuras así, la IA mezcla todo y el resultado se degrada rápido.
Además, si quieres ir un paso más allá, tengo un GPT especializado en crear prompts para web apps que automatiza esta parte y te ayuda a estructurarlos correctamente (pulsa aquí).
1) Prompt: Arquitectura visual completa de la aplicación
Este prompt separa diseño de lógica. Si mezclas esto con cálculos, la IA empieza a improvisar. Aquí validas si la app tiene sentido antes de construirla.
Actúa como diseñador UX/UI especializado en aplicaciones web funcionales.
Quiero que construyas la estructura completa de una aplicación web cuyo objetivo es calcular cuánto puede recibir un usuario al vender sus joyas de oro.
La aplicación debe incluir:
Home clara con propuesta de valor directa
Inputs para:
peso en gramos
quilataje (selector)
Botón principal de acción (calcular)
Zona de resultados estructurada
Textos claros, sin lenguaje técnico
Flujo simple: introducir datos → obtener resultado
Importante:
NO añadas lógica ni cálculos todavía
NO añadas APIs
NO simules resultados
Céntrate únicamente en:
estructura
jerarquía visual
experiencia de usuario
claridad
Quiero una app usable, no bonita sin sentido.2) Prompt: Núcleo de la aplicación
Aquí defines el producto. Si esto está mal, todo lo demás es irrelevante. Esto no es código, es modelo de negocio.
Actúa como desarrollador con criterio de negocio.
Ahora quiero que implementes la lógica real de la aplicación.
Objetivo:
Calcular un rango de precios al que una persona podría vender sus joyas de oro.
Datos de entrada:
peso (gramos)
quilataje
Condiciones:
No mostrar precio exacto, sino rangos:
conservador (mínimo esperado)
mercado (valor medio)
premium (valor alto posible)
Tener en cuenta que los compradores aplican márgenes
El cálculo debe ser realista, no optimista
Salida:
rango inferior y superior
desglose claro para el usuario
lenguaje entendible
Importante:
NO inventar datos sin lógica
NO centrarse en diseño
centrarse en que el cálculo tenga sentido3) Prompt: Integración de API (datos reales)
Aquí introduces complejidad de verdad. Backend, seguridad, caché. Esto jamás se mete en el primer prompt porque rompe todo.
Actúa como desarrollador backend.
Quiero integrar una API externa que proporcione el precio actualizado del oro.
Requisitos:
Obtener precio del oro en tiempo real
NO exponer la API key en el frontend
Implementar backend intermedio si es necesario
Aplicar sistema de caché (mínimo 12 horas)
Evitar llamadas innecesarias
Preparar función centralizada para obtener precios
Formato interno esperado:
{
price_24k,
price_22k,
price_18k,
price_14k,
price_10k
}
Importante:
La app debe seguir funcionando aunque la API falle (usar caché)
No romper la lógica de cálculo anterior4) Prompt: Estructura SEO mínima viable
Esto es una capa técnica básica. No posiciona por sí sola, pero evita errores típicos. Es lo mínimo para que Google entienda qué es tu web. Nada más.
Actúa como especialista en SEO técnico.
Quiero que añadas a la aplicación una base SEO correcta sin modificar el funcionamiento actual.
Incluye:
title optimizado y claro según la funcionalidad de la app
meta description concisa y entendible
estructura HTML semántica (uso correcto de h1, h2, etc.)
etiquetas básicas necesarias para indexación
Importante:
NO modificar diseño
NO añadir contenido innecesario
NO cambiar textos principales
NO prometer posicionamiento
El objetivo es tener una base técnica correcta, no hacer SEO avanzado.5) Legal mínimo obligatorio
Esto no aporta valor al usuario ni mejora el producto, pero es obligatorio si quieres evitar problemas legales. Es cumplimiento, no estrategia.
Actúa como asesor legal para aplicaciones web.
Quiero que añadas a la aplicación los elementos legales mínimos necesarios.
Incluye:
aviso de cookies
política de privacidad
términos de servicio
Condiciones:
textos claros y profesionales
evitar lenguaje excesivamente técnico o legalista
mantener coherencia con la web
integrarlo sin romper la experiencia de usuario
Importante:
NO modificar diseño principal
NO afectar al funcionamiento de la app
NO añadir elementos innecesarios
El objetivo es cumplir, no aportar valor diferencial.6) Optimización y rendimiento
Aquí es donde pasas de demo a producto usable. Sin esto, la app puede funcionar, pero cargará mal, será lenta y dará mala experiencia.
Actúa como ingeniero senior especializado en rendimiento web.
Optimiza la aplicación manteniendo exactamente el mismo comportamiento visible.
No puedes modificar:
diseño
experiencia de usuario
lógica de cálculo
textos
funcionalidad
Objetivos:
mejorar velocidad de carga
optimizar rendimiento en móvil
evitar bloqueos en el render inicial
reducir peso de JavaScript y dependencias
evitar llamadas API innecesarias en carga inicial
Aplica:
lazy loading de componentes no críticos
optimización de dependencias
reducción de trabajo en el hilo principal
mejora de Core Web Vitals
Importante:
la aplicación debe verse y funcionar exactamente igual para el usuario.7) Exportación y preparación para despliegue (optativo)
Este es el punto donde dejas de depender de la herramienta. Si no haces esto, la app no es tuya, es de la plataforma. Aunque esto con horizons no es necesario.
Actúa como desarrollador web.
Prepara la aplicación para poder exportarla y desplegarla fuera de la plataforma actual.
Incluye:
exportación completa del código
estructura clara de archivos del proyecto
instrucciones para ejecutar el proyecto en local
generación de versión optimizada para producción (build)
creación de carpeta final lista para subir al hosting (dist o equivalente)
Importante:
NO añadir complejidad innecesaria
NO cambiar la lógica de la aplicación
NO modificar diseño ni funcionalidad
El objetivo es tener una versión independiente lista para desplegar en cualquier servidor.Error típico: intentar resolver todo en un solo prompt
Este es el clásico. Intentar meter toda la aplicación en un único mensaje esperando que la IA entienda diseño, lógica, estructura, funcionalidades y detalles técnicos de golpe. El resultado casi siempre es el mismo: algo desordenado, superficial o directamente inútil.
El problema no es la IA, es el enfoque. Cuando concentras todo en un solo prompt, estás mezclando capas que deberían separarse. Diseño con lógica, estructura con funcionalidades, ideas generales con detalles concretos. Eso rompe la claridad y la IA responde igual de mal.
Además, este error suele venir acompañado de otra cosa: expectativas irreales. Pensar que puedes construir un producto completo en una sola interacción. Eso no es eficiencia, es desconocimiento de cómo funciona realmente el proceso.
Paso 3: exportar el código correctamente
Exportar el código no es un paso técnico más, es el punto donde la aplicación deja de ser “algo generado” y pasa a ser un activo real. Mientras trabajas dentro de la herramienta, todo está encapsulado: hosting, ejecución, dependencias… todo ocurre en un entorno que no controlas. En el momento en que exportas, eso desaparece y te enfrentas a la aplicación tal y como es.
Lo que obtienes no es una web lista para usar sin más, sino un proyecto con estructura, archivos, dependencias y lógica interna. Ahí es donde empiezas a ver cómo está construida realmente la aplicación: carpetas, componentes, librerías, scripts… y entiendes que lo que parecía simple tiene capas por debajo.
Este paso es clave porque te da independencia. Puedes dejar de pagar la herramienta, modificar lo que necesites, mover la app a otro hosting o incluso escalarla. Si no exportas, estás alquilando. Si exportas, estás construyendo. Y esa diferencia, a medio plazo, lo cambia todo.
Cuándo NO deberías depender de la plataforma
Depender de la plataforma tiene sentido en una fase muy concreta: cuando estás validando ideas o construyendo rápido sin preocuparte por la infraestructura. Es útil para prototipar, lanzar versiones iniciales o probar si algo tiene sentido antes de invertir más tiempo.
El problema aparece cuando ese uso puntual se convierte en dependencia permanente. Si tu aplicación empieza a tener tráfico, lógica más compleja o cualquier tipo de monetización, seguir dentro de la plataforma te limita. No tienes control total, dependes de sus precios, de sus límites y de sus decisiones técnicas.
También hay un punto crítico con la escalabilidad. Muchas herramientas funcionan bien para casos simples, pero en cuanto necesitas backend propio, control de datos o integraciones más serias, empiezan los problemas. En ese momento, seguir dentro no es práctico, es un freno.
La regla es simple: usa la plataforma para construir y validar, pero no para quedarte. Si el proyecto tiene potencial, sal de ahí cuanto antes. No porque la herramienta sea mala, sino porque no está pensada para ser el destino final.
Paso 4: trabajar el código en Visual Studio
Toca descargar Visual Studio. Cuando llevas el proyecto a Visual Studio (o cualquier editor), entras en una fase diferente. Ya no estás hablando con una IA que ejecuta por ti, estás interactuando con el código real de la aplicación. Y aquí es donde mucha gente se bloquea porque cree que tiene que “saber programar”.
La realidad es otra. No necesitas entender todo el código, necesitas saber moverte dentro de él. Abrir el proyecto, ejecutar unos comandos básicos, ver si funciona en local y generar la versión final. Es más mecánico que técnico si sigues un proceso claro.
Visual Studio actúa como puente entre lo que has generado y lo que vas a publicar. Te permite ejecutar la app en local, comprobar que todo funciona correctamente y preparar la versión optimizada para producción. Sin este paso, estás subiendo algo que no has validado realmente.
Además, este entorno te da margen para hacer ajustes que la IA no cubre bien: añadir favicon, modificar metadatos, crear sitemap, tocar pequeños detalles. No es desarrollo complejo, es control básico sobre tu propia aplicación.
¿Qué harás en visual studio?
Estás instalando dependencias, ejecutando un entorno local, generando un build de producción y preparando un despliegue. Eso es exactamente lo mismo que hace un desarrollador, solo que apoyado por IA.
La diferencia es que no necesitas construir cada pieza manualmente, pero sí necesitas entender el flujo. Saber qué comando ejecuta qué, por qué se genera una carpeta “dist” o qué significa levantar la aplicación en local. No es programación clásica, pero tampoco es “no hacer nada”.
Este punto es importante porque rompe una idea bastante extendida: que con IA todo es automático. No lo es. La IA acelera la construcción, pero el control sigue siendo tuyo. Si no entiendes mínimamente lo que estás haciendo, dependes totalmente de la herramienta.
En cambio, cuando entiendes el proceso, aunque sea a nivel básico, ganas algo mucho más valioso: autonomía. Puedes construir, corregir, adaptar y publicar sin quedarte bloqueado. Y eso es lo que realmente cambia el juego.
Paso 5: preparar archivos y estructura del proyecto
Cuando exportas la aplicación desde la herramienta, lo que recibes no es una web lista para subir directamente, sino un proyecto completo. Esto es importante entenderlo desde el principio, porque aquí es donde mucha gente se pierde: abre la carpeta, ve archivos raros y piensa que algo está mal. No, es exactamente como debe ser.
Lo primero que tienes que hacer es descomprimir el archivo que has descargado. Dentro encontrarás una estructura de carpetas que puede parecer compleja, pero en realidad sigue una lógica bastante clara. Hay una carpeta donde vive la aplicación, normalmente dentro de algo como apps\web, y dentro de esa carpeta están todos los archivos que hacen que la web funcione.
Ahí vas a encontrar varias cosas: archivos de configuración, carpetas con componentes, estilos, scripts y dependencias. No necesitas entender todo esto al detalle, pero sí necesitas saber identificar dónde está la aplicación real. Ese es el primer paso práctico: localizar la carpeta donde está la web que quieres ejecutar.
Una vez identificada, la subes a Visual Studio Code (o el editor que estés usando) utilizando la opción de abrir carpeta. En ese momento ya estás dentro del proyecto. No estás viendo “código suelto”, estás viendo la base de tu aplicación. Y esto cambia la mentalidad: ya no estás generando, estás trabajando sobre algo que existe.
Además, este paso tiene una función clave: te permite empezar a tener control. Mientras estás dentro de la herramienta todo es automático. Aquí empiezas a ver cómo está organizado, qué archivos existen y qué partes puedes modificar. No hace falta que toques nada todavía, pero ya estás dentro del sistema.
Paso 6: comandos clave para ejecutar la app
Hasta ahora solo tienes archivos, pero no una aplicación ejecutándose. Para eso necesitas usar una serie de comandos que preparan el entorno y levantan la web en local. Empezarás yendo a ‘new terminal’ y ahí pondrás una serie de comandos que aquí te especificaré.
Paso 1: Instalar dependencias
npm install
Este comando descarga e instala todas las librerías que necesita el proyecto para funcionar. Es el primer paso que debe realizarse después de descargar o exportar una aplicación.
Cuando ejecutas esto, lo que estás haciendo realmente es decirle al proyecto: “descarga todo lo que necesitas para poder funcionar”. La aplicación no está completa solo con los archivos que has descargado, necesita librerías externas que se instalan automáticamente con este comando.
Puede tardar unos segundos o incluso minutos dependiendo del proyecto. Verás cómo se crean carpetas como node_modules, que contienen todo lo necesario para que la aplicación funcione. No necesitas tocar esa carpeta, pero sí entender que sin este paso nada va a arrancar.
Paso 2: Entrar en la carpeta de la web y verla en local
cd apps\web
En los proyectos exportados desde Horizons la aplicación suele encontrarse dentro de apps\web, aunque en otros proyectos la ruta puede ser diferente. La idea es entrar en la carpeta donde realmente está la web.
Este comando simplemente te mueve dentro del proyecto. Es como entrar en la habitación donde está la aplicación. Si no estás en la carpeta correcta, los siguientes comandos no funcionarán.
Después:npm run dev
Esto permite abrir la aplicación en local, probarla y comprobar que todo funciona correctamente antes de generar la versión final.
Aquí es donde ocurre la magia real. Este comando levanta un servidor local y te da una URL (normalmente algo como http://localhost:5173). Cuando entras ahí en tu navegador, estás viendo tu aplicación funcionando en tu propio ordenador.
Este paso es crítico porque te permite validar. Puedes interactuar con la app, probar inputs, ver si hay errores y confirmar que todo está funcionando antes de dar el siguiente paso. Si algo falla aquí, mejor detectarlo ahora que cuando ya esté publicada.
Qué hace cada comando y por qué importa
Estos comandos no son técnicos por capricho, cada uno cumple una función concreta dentro del flujo.
npm install no es opcional porque sin él la aplicación no tiene todo lo que necesita para ejecutarse. Es como intentar arrancar un coche sin motor. Puedes tener la estructura, pero no funciona.
cd apps\web te coloca en el sitio correcto. Parece una tontería, pero es clave. Si ejecutas comandos fuera de la carpeta correcta, simplemente no pasa nada o da error. Esto es orden, no complejidad.
npm run dev es el paso donde conviertes archivos en una aplicación real. Aquí es donde puedes ver, tocar y probar. Es el equivalente a encender el producto antes de venderlo.
Entender esto, aunque sea a nivel básico, cambia completamente cómo trabajas. Ya no estás siguiendo pasos sin sentido, estás ejecutando un proceso lógico: instalar → acceder → ejecutar → validar.
Generar la versión final (build)
Una vez has comprobado que todo funciona en local, necesitas generar la versión final de la aplicación. La que realmente vas a subir al hosting.
Aquí entra el siguiente comando:
npx vite build --outDir dist
Este comando crea o actualiza la carpeta dist, que contiene la versión final optimizada de la web lista para subir al hosting. Aunque existen otros métodos para generar el build, este fue el que funcionó correctamente y generó la carpeta dist de forma clara y predecible dentro de la propia aplicación.
Lo que hace este comando es transformar tu proyecto. Pasa de ser una aplicación en desarrollo (con archivos separados, código sin optimizar, etc.) a una versión comprimida, optimizada y preparada para producción.
Dentro de la carpeta dist vas a encontrar archivos más “limpios”: HTML, CSS y JavaScript listos para funcionar en cualquier servidor. Esta es la carpeta que importa. Todo lo demás es entorno de trabajo.
Este paso es imprescindible. Si subes el proyecto sin hacer esto, es muy probable que no funcione correctamente o que cargue mal. El build convierte tu aplicación en algo publicable.
Añadir favicon, title y meta correctamente
Aquí entras en una capa que mucha gente ignora, pero que es necesaria. No es desarrollo complejo, pero sí es control básico sobre tu web.
El favicon es el icono que aparece en la pestaña del navegador. Para añadirlo, simplemente colocas la imagen dentro de la carpeta public y luego la referencias en el archivo index.html. No tiene complejidad técnica, pero mejora la presentación y da sensación de producto terminado.
El title es el título que aparece en Google y en la pestaña del navegador. La meta description es el texto que aparece debajo en los resultados de búsqueda. Esto no va a posicionarte por sí solo, pero sí evita que tu web aparezca con textos genéricos o vacíos.
Aquí puedes usar IA de forma inteligente: copias el contenido del index.html, le pides que añada favicon, title y meta, y luego pegas el resultado. No necesitas saber escribir código, solo entender qué estás modificando.
Este paso no aporta funcionalidad, pero sí profesionaliza la aplicación. Es la diferencia entre algo “generado” y algo que parece un producto real.
Crear sitemap y robots.txt sin complicarte
Este es otro punto que suele parecer más complejo de lo que realmente es. Un sitemap es simplemente un archivo que le dice a Google qué páginas existen en tu web. El robots.txt le dice qué puede o no puede rastrear.
No necesitas construirlos a mano. Puedes pedírselo directamente a una IA: le dices tu dominio y te genera ambos archivos en segundos. Luego solo tienes que colocarlos dentro de la carpeta public.
El sitemap es útil para facilitar la indexación, especialmente si tienes varias páginas. El robots.txt es una guía básica para los motores de búsqueda. Ninguno de los dos va a hacer que posiciones automáticamente, pero sí evita errores básicos.
Además, este paso te introduce en cómo funciona realmente la publicación de una web. No es solo subir archivos, es preparar el entorno para que funcione correctamente en buscadores y navegadores.
Paso 7: subir la web al hosting
Este es el momento donde todo lo anterior cobra sentido. Hasta ahora has construido, probado y preparado la aplicación, pero sigue estando en tu entorno local. Subirla al hosting es lo que la convierte en accesible para cualquier persona desde internet.
El proceso en sí es más simple de lo que parece. Básicamente consiste en coger el contenido de la carpeta dist (que es la versión final optimizada) y subirlo al servidor, normalmente dentro de una carpeta como public_html. No se sube el proyecto entero, solo esa versión final.
Aquí hay un punto clave: si has hecho bien el build, subir la web es casi un trámite. Si no lo has hecho, empiezan los problemas. Por eso todo el proceso anterior no es opcional, es lo que hace que este paso sea sencillo.
Además, subir la web no tiene nada que ver con programar. Es gestión de archivos. Arrastras, subes, reemplazas y listo. Pero aunque sea simple, es el paso que marca la diferencia entre “tengo una app” y “mi app está online”.
Cómo funciona el despliegue
El despliegue no es magia, es un proceso bastante directo. Un servidor web no hace más que servir archivos cuando alguien accede a una URL. Cuando subes tu carpeta dist, lo que estás haciendo es poner esos archivos en un lugar donde el servidor puede entregarlos a cualquier usuario.
Cuando alguien entra en tu dominio, el servidor busca un archivo principal (normalmente index.html) y empieza a cargar el resto de recursos: CSS, JavaScript, imágenes… todo lo que forma la web. Si esos archivos están bien generados, la web funciona. Si no, falla.
Aquí es donde se entiende por qué el build es importante. Durante el desarrollo tienes muchos archivos, dependencias y código sin optimizar. El build convierte todo eso en una versión limpia, ligera y lista para ser servida correctamente.
También es importante entender que el hosting no “ejecuta IA” ni nada complejo. Solo sirve archivos. Toda la lógica ya está dentro de lo que has generado. El servidor no piensa, solo entrega lo que le has subido.
Conectar dominio o subdominio
Una vez la web está subida, necesitas darle una dirección accesible. Aquí entran los dominios y subdominios.
Un dominio es la dirección principal (por ejemplo, tuweb.com). Un subdominio es una extensión de ese dominio (por ejemplo, app.tuweb.com). Técnicamente funcionan igual, pero se usan para organizar proyectos o separar aplicaciones.
Conectar un dominio implica decirle al proveedor de hosting: “cuando alguien entre aquí, muéstrale estos archivos”. Esto se hace configurando DNS o seleccionando el dominio dentro del propio panel del hosting. No es complicado, pero sí requiere seguir los pasos correctamente.
Elegir entre dominio o subdominio depende del proyecto. Si es algo principal, suele ir en dominio. Si es una herramienta o app concreta, el subdominio tiene más sentido. No es una decisión técnica compleja, es más estratégica.
Lo importante aquí es entender que el dominio no contiene la web. Solo apunta a ella. La web está en el servidor, el dominio es la puerta de entrada.
Google Search Console: indexación básica
Una vez la web está online, Google no la “descubre” automáticamente de forma instantánea. Necesitas indicarle que existe. Para eso sirve Google Search Console.
El proceso es sencillo: añades tu dominio, verificas que eres el propietario (normalmente añadiendo un código en el index.html) y a partir de ahí puedes enviar tu sitemap. Esto le dice a Google qué páginas tiene tu web y facilita que las indexe.
Aquí no hay magia ni resultados inmediatos. Lo que estás haciendo es abrir la puerta para que Google pueda rastrear tu web. Puede tardar horas, días o más. Pero sin este paso, dependes completamente de que Google te encuentre por casualidad.
También te permite ver errores, problemas de indexación o páginas que no se están mostrando correctamente. No es una herramienta opcional si quieres que tu web tenga visibilidad mínima.
Error común: pensar que esto posiciona solo
Aquí es donde hay que ser claro porque es uno de los mayores engaños dentro del mundo de la IA y las webs automáticas. Crear una web, añadir SEO básico y subirla no significa que vaya a posicionar. Ni cerca.
El problema es que muchas herramientas venden la idea de que puedes generar una web, añadir cuatro metas y empezar a recibir tráfico. Eso no ocurre así. Google no posiciona webs por existir, posiciona contenido que aporta valor, responde a búsquedas y compite con otras páginas.
El SEO que has hecho aquí es técnico, no estratégico. Sirve para que Google entienda tu web, no para que la priorice. Es como matricular un coche, no como ganar una carrera. Aquí te cuento como es el SEO en esta era de ‘respuestas generativas’. Spoiler: Poco ha cambiado.
Además, hay otro punto importante: la competencia. No estás solo. Para cualquier búsqueda hay decenas o cientos de webs intentando posicionar. Si tu aplicación no aporta algo mejor, más útil o más específico, no va a destacar por sí sola.
También influye el contenido, los enlaces, la autoridad del dominio, la experiencia de usuario… todo eso está fuera del simple hecho de “crear una web con IA”. Pensar que la IA sustituye eso es un error bastante común.
Por eso es importante separar dos cosas: construir una web y hacer que funcione a nivel de tráfico. Lo primero es técnico y cada vez más accesible. Lo segundo es estratégico y sigue requiriendo criterio, tiempo y trabajo real.
Si no entiendes esta diferencia, es fácil caer en la trampa de creer que has construido un activo cuando en realidad solo has creado una página más dentro de internet.
Caso avanzado: app con API (frontend + backend)
Hasta ahora has trabajado con aplicaciones relativamente simples: lógica en el navegador, sin necesidad de conectarse a nada externo. Eso está bien para muchos casos, pero en cuanto necesitas datos reales o lógica más sensible, aparece un nuevo nivel: separar frontend y backend.
Una app con API ya no es solo una web que calcula cosas. Es un sistema donde una parte (frontend) se encarga de la interfaz y otra (backend) se encarga de obtener datos, procesarlos y devolver resultados. Esto introduce complejidad, pero también es lo que permite construir herramientas realmente útiles.
En el caso de la app del oro, el frontend recoge los datos del usuario (peso, quilataje) y muestra resultados. Pero el precio del oro no está dentro de la web, se obtiene desde una API externa. Ahí entra el backend: actúa como intermediario, consulta esa API, aplica lógica y devuelve el dato limpio al frontend.
Este cambio es importante porque rompe la idea de “todo ocurre en la web”. Ya no. Ahora tienes dos partes que deben comunicarse correctamente. Y si esa comunicación falla, la aplicación deja de funcionar.
Qué cambia cuando hay backend
El cambio principal es que ya no estás trabajando con una sola capa. Antes todo ocurría en el navegador. Ahora tienes una arquitectura donde cada parte tiene su responsabilidad.
El frontend se encarga de lo visible: inputs, botones, resultados, interacción. Es lo que ve el usuario. El backend, en cambio, trabaja en segundo plano: obtiene datos, aplica lógica, protege información sensible y devuelve respuestas.
Esto implica varias cosas. La primera es que necesitas entender que hay comunicación entre ambas partes. El frontend hace una petición (por ejemplo, “dame el precio del oro”) y el backend responde. Esa comunicación tiene que estar bien estructurada.
La segunda es que introduces puntos de fallo. Si la API externa no responde, si el backend falla o si hay un error en la conexión, la app puede romperse. Por eso necesitas manejar errores, no asumir que todo va a funcionar siempre.
La tercera es que ganas control. Puedes decidir cómo se calculan las cosas, qué datos usas, cómo los filtras y cómo los entregas. Ya no dependes completamente de lo que haga la IA o la herramienta.
Seguridad, variables de entorno y caché
Momento de separar lo básico de lo serio. Cuando trabajas con APIs, hay información que no puede estar en el frontend. Por ejemplo, las claves de acceso. Si metes una API key directamente en la web, cualquiera puede verla y usarla. Eso es un error crítico.
Para evitar esto, se utilizan variables de entorno en el backend. Son valores que se guardan fuera del código visible y que solo el servidor conoce. Así puedes hacer peticiones a la API sin exponer datos sensibles al usuario.
Otro punto clave es la caché. En el caso del precio del oro, no tiene sentido hacer una petición a la API cada vez que alguien entra en la web. Eso consume recursos, puede generar costes y aumenta el riesgo de fallos.
La solución es almacenar el resultado durante un tiempo determinado, por ejemplo 12 horas. De esta forma, el backend consulta la API una vez, guarda el dato y lo reutiliza para todos los usuarios durante ese periodo. Esto mejora rendimiento, reduce costes y hace la app más estable.
También es importante tener un fallback. Si la API falla, la app no debería romperse. Puede usar el último valor almacenado y seguir funcionando. No es perfecto, pero es mucho mejor que devolver error.
Ejemplo real: OhMyGold y su lógica
La aplicación de OhMyGold es un buen ejemplo de cómo se aplica todo esto en la práctica. No es una web que muestra el precio del oro, es una herramienta que interpreta ese precio para el usuario.
Por un lado está el frontend, que recoge los datos: cuánto pesa la joya, qué quilataje tiene, etc. Esa parte es similar a cualquier otra app. La diferencia está en lo que ocurre detrás.
El backend se encarga de consultar una API externa para obtener el precio actualizado del oro. Ese dato no se envía directamente al usuario. Primero pasa por un sistema que lo adapta: lo convierte en precios por quilataje, aplica márgenes y genera rangos de negociación.
Además, se implementa un sistema de caché de 12 horas. Esto significa que no se está consultando constantemente la API, sino que se reutiliza la información durante un periodo. Esto reduce llamadas, evita problemas de límites y mejora el rendimiento general.
También hay una separación clara entre frontend y backend. El usuario nunca ve cómo se obtiene el precio ni qué clave se utiliza. Solo ve el resultado final. Esto es fundamental para mantener la seguridad y el control.
Y aquí está lo importante: la complejidad no está en “usar IA”, está en diseñar bien el sistema. La IA puede ayudarte a construirlo, pero la arquitectura, las decisiones y el criterio siguen siendo tuyos.
Este tipo de aplicaciones ya no son demos. Son herramientas reales que pueden escalar, monetizarse y evolucionar. Pero solo si entiendes que detrás hay más que prompts: hay estructura, lógica y decisiones técnicas que marcan la diferencia.
Qué hace útil una app (y qué no)
Una aplicación no es útil porque funcione, es útil porque resuelve algo concreto mejor que la alternativa. Este matiz es clave porque la mayoría de apps generadas con IA fallan justo aquí: funcionan técnicamente, pero no tienen ningún motivo real para existir.
Una app útil parte de una situación clara. Alguien tiene un problema específico, necesita tomar una decisión o quiere ahorrar tiempo en algo concreto. Si no puedes describir en una frase qué resuelve tu aplicación, probablemente no tenga valor. En el caso de OhMyGold, el problema es directo: “quiero vender oro y no sé si me están ofreciendo bien”. Todo gira alrededor de eso.
Otro punto importante es la fricción. Una app útil reduce pasos, simplifica decisiones y elimina incertidumbre. Si el usuario tiene que pensar demasiado, interpretar datos complejos o hacer cálculos por su cuenta, la herramienta falla. La utilidad está en hacer fácil lo que antes era incómodo.
También hay una diferencia entre información y herramienta. Mostrar datos no es suficiente. Internet está lleno de webs que “informan”, pero pocas que ayudan a decidir. Una app útil no te dice solo cuánto vale el oro, te dice qué significa eso en tu caso concreto. Ese salto es lo que marca la diferencia.
Ahora bien, hay cosas que NO hacen útil una app. El diseño bonito no la hace útil. La tecnología tampoco. Que esté hecha con IA no aporta nada por sí mismo. Incluso tener muchas funcionalidades puede jugar en contra si no están alineadas con el problema principal. Más no es mejor, es más ruido.
Otro error común es construir sin contexto real. Apps que parecen interesantes en teoría pero que nadie usaría en la práctica. Esto suele pasar cuando se construye “porque se puede” y no porque exista una necesidad clara. La IA facilita crear, pero no valida si tiene sentido.
Por último, está el criterio. La IA no sabe si tu app es buena, solo sabe generarla. Si tú no sabes evaluar si lo que has construido tiene utilidad real, puedes acabar con algo técnicamente correcto pero completamente irrelevante. Y esto pasa más de lo que parece.
Monetización: dónde está el dinero realmente
Aquí es donde se rompe otra idea bastante extendida: el dinero no está en crear la app, está en lo que haces con ella. La tecnología es el medio, no el negocio.
Una de las formas más directas de monetizar es resolver un problema que ya tiene valor económico. En el caso de OhMyGold, el usuario está en un momento donde puede perder o ganar dinero al vender oro. Si tu herramienta le ayuda a tomar una mejor decisión, ahí hay valor real. Y donde hay valor, hay posibilidad de monetización.
Luego está la afiliación. Si tu app está en un contexto donde el usuario puede necesitar productos o servicios, puedes recomendar soluciones y ganar una comisión. El ejemplo claro es el enlace a kits para comprobar oro. No es intrusivo, tiene sentido dentro del flujo y monetiza sin romper la experiencia.
También está la venta directa, pero aquí hay que ser realista. Cobrar por una app solo funciona si el valor es evidente. Si tu herramienta ahorra dinero, tiempo o mejora decisiones de forma clara, puedes cobrar. Si no, el usuario no paga, por muy bien hecha que esté.
Otro modelo es generar tráfico y monetizarlo indirectamente, pero esto ya entra en estrategia de contenido y SEO, no en la app en sí. Y aquí es donde muchos se confunden: creen que por tener una web ya van a tener visitas. No funciona así.
También puedes usar la app como puerta de entrada a algo mayor: servicios, consultoría, productos propios. En muchos casos, la app no es el negocio, es el canal. Es lo que atrae al usuario y lo mete dentro de tu ecosistema.
Y aquí está la parte incómoda: la mayoría de apps no monetizan porque no deberían existir. No tienen problema claro, no tienen usuario definido y no aportan nada que alguien esté dispuesto a pagar. La IA ha multiplicado la capacidad de crear, pero no ha aumentado la demanda de herramientas inútiles.
El dinero está en el contexto, no en la herramienta. Está en entender qué problema tiene el usuario, en qué momento está y qué decisión necesita tomar. Si conectas eso con tu app, puedes monetizar. Si no, solo tienes otra web más perdida en internet.
Lo que la IA no va a hacer por ti
La IA puede ejecutar, acelerar y ayudarte a construir, pero no va a pensar por ti. Este es el punto que más se ignora y el que más impacto tiene en el resultado final. Puedes generar una aplicación completa en horas, pero si no sabes qué estás construyendo, solo estás produciendo ruido más rápido.
No va a validar si tu idea tiene sentido. Puedes crear una app perfectamente funcional que no use nadie. La IA no entiende contexto real, ni mercado, ni necesidad. Solo responde a lo que le pides. Si la base está mal, el resultado también lo estará.
Tampoco va a tomar decisiones estratégicas. No sabe si debes usar una API u otra, si ese cálculo tiene lógica de negocio o si tu enfoque es el correcto. Puede proponerte cosas, pero no sustituye el criterio. Delegar eso es el error más común.
Otro punto clave es que no va a encargarse de la calidad real. Puede darte código que “funciona”, pero no te asegura que sea óptimo, seguro o escalable. Si no revisas, corriges y entiendes mínimamente lo que estás haciendo, dependes completamente de algo que no controla el resultado.
Y por último, no va a hacer que tu app tenga impacto. No va a traer usuarios, no va a posicionar tu web, no va a hacer que la gente pague. Eso está fuera de la tecnología. Pensar lo contrario es comprar la narrativa fácil que se está vendiendo alrededor de la IA.
Qué deberías hacer ahora con esto
Si has llegado hasta aquí, ya tienes algo que la mayoría no tiene: un proceso claro para construir una web app con IA de principio a fin. Ahora la diferencia no está en aprender más, está en ejecutar.
Lo primero es aplicar esto a un caso real. No empieces por algo complejo. Elige un problema concreto, acotado y con sentido. Algo que alguien usaría de verdad. Construye una primera versión, aunque sea simple, y comprueba si funciona.
Después, itera. Ajusta la lógica, mejora la experiencia, corrige errores. No intentes hacerlo perfecto desde el inicio. Lo importante es validar si lo que has creado tiene utilidad. Si no la tiene, cambia el enfoque. Si la tiene, empieza a mejorar.
También es importante que salgas de la herramienta cuanto antes. Exporta, trabaja el código, súbelo a un hosting. Mientras estés dentro de la plataforma, estás en modo prueba. Cuando lo sacas fuera, estás en modo producto.
Y por último, sé realista con las expectativas. Esto no es un atajo para generar dinero automático. Es una herramienta que te permite construir más rápido. Lo que hagas con eso depende de tu criterio, no de la IA.
Aquí es donde se separa la gente que consume contenido de la que construye cosas. Tienes el proceso. Ahora toca usarlo.
