Cómo crear una miniapp web con IA sin programar

Una IA puede traducir instrucciones a HTML, CSS y JavaScript, pero no puede decidir por ti qué comportamiento es aceptable ni qué riesgo puedes asumir. Para que una primera app sea comprobable, reduce la idea hasta que sus entradas, estados y límites quepan en un brief corto.

Esta guía usa un caso real y descargable: Mapa de alcance para una miniapp, un prototipo estático que clasifica ocho requisitos mediante reglas visibles. El flujo se ejecutó en un entorno local asistido por Codex. Eso aporta archivos, hashes, pruebas y capturas reproducibles; no demuestra que una persona sin experiencia técnica pueda construir o mantener cualquier aplicación.

Primero decide si tu idea cabe en una miniapp local

Una miniapp local es una buena primera prueba cuando puede resolver el problema con una interfaz y lógica dentro del navegador. El alcance cambia en cuanto necesitas compartir estado entre personas, identificar usuarios, cobrar, guardar información en un servidor o actuar sobre otro sistema.

El límite no es una desventaja del prototipo. Es lo que permite saber qué se verificó y evita confundir una vista previa atractiva con un producto preparado para operar.

Qué construimos para comprobar el método

La miniapp presenta ocho interruptores cerrados; no admite texto libre ni solicita información del lector. Cinco requisitos llevan al estado FUERA_DEL_TUTORIAL: cuentas o roles, datos personales, pagos, base compartida y edición multiusuario. Otros tres llevan a REQUIERE_REVISION_TECNICA: API externa, archivos de usuario y tareas en segundo plano.

Si no seleccionas ninguno, el resultado es CANDIDATO_ESTATICO_LOCAL. Si combinas requisitos, prevalece el estado más restrictivo y se conservan todos los motivos. La interfaz también incluye:

• tres presets: Checklist local, Consulta de API pública y Portal de clientes;
• un botón para restablecer selección, contador, motivos y estado;
• una descarga TXT reproducible a partir de lo visible;
• etiquetas textuales y marcadores para no depender solo del color;
• un aviso permanente: el resultado filtra alcance, no certifica seguridad, privacidad, mantenibilidad ni producción.

Durante la corrida registrada, la miniapp no creó cookies ni datos en localStorage, sessionStorage o IndexedDB, y el log de red solo mostró recursos servidos desde 127.0.0.1. Esas observaciones describen esa versión y ese harness, no cualquier app generada con IA.

Antes del código: convierte la idea en un brief comprobable

El paso más importante ocurrió antes de generar index.html: el prompt se guardó, fechó y hasheó. Las correcciones posteriores quedaron en un registro de iteraciones y no reemplazaron la instrucción original para construir una historia perfecta a posteriori.

Un brief útil para una miniapp pequeña debería contestar al menos estas preguntas:

Evita instrucciones como “crea una app moderna para mi negocio”. La IA tendrá que completar demasiadas decisiones y tú no tendrás un oráculo para distinguir una salida correcta de una demo convincente. Es mejor especificar pocos estados observables, la precedencia entre ellos y los casos que deben fallar.

El brief congelado descargable conserva el prompt completo del caso. Úsalo como estructura, no como un “prompt perfecto”: debes sustituir propósito, reglas y pruebas por los de tu problema.

Del brief a los archivos: el flujo local asistido por Codex

La construcción siguió cortes pequeños y auditables:

1. Se congelaron el prompt y el contrato de aceptación antes de crear el código.
2. Codex asistió la creación de HTML semántico, CSS mobile-first, lógica JavaScript separada de la capa DOM, fixtures y pruebas.
3. Se ejecutaron unitarios y un validador estático sobre la fuente.
4. Se generó un ZIP determinista, se extrajo en una carpeta temporal nueva y las pruebas finales se repitieron contra esa extracción.
5. Se sirvió únicamente en loopback y Playwright recorrió teclado, estados, descarga, reset, red, almacenamiento y tres viewports.
6. Las capturas se revisaron visualmente y cada corrección quedó anotada antes de repetir el pipeline.

El proceso no prueba una interfaz de Lovable, Bolt o Replit: ninguna de esas plataformas se ejecutó. Tampoco hubo una sesión observada de una persona no técnica ni se midieron tiempo, coste o facilidad. “Asistido por Codex” identifica el tooling local usado, no atribuye autonomía humana que no fue estudiada.

Qué revelaron las iteraciones reales

Una prueba funcional que termina en verde todavía puede dejar problemas de packaging o presentación. El registro conservó tres ajustes concretos:

Ninguno de esos cambios fue ocultado ni se reescribió el brief para justificarlo. Las tres corridas E2E funcionales ya pasaban antes de los dos ajustes visuales; por eso la revisión visual aportó información que el conteo de tests no mostraba.

Cómo ejecutar y leer la miniapp descargable

Extrae el ZIP del mapa de alcance, abre una terminal dentro de miniapp-mapa-alcance y sirve la carpeta por HTTP local:

python -m http.server 14690 --bind 127.0.0.1

Después abre http://127.0.0.1:14690/. Es el mismo flujo HTTP local que se validó; la corrida registrada usó el puerto 14692. Abrir index.html mediante file:// no equivale a la prueba registrada. El kit no instala Python, Node, Playwright ni Chromium, y no existe una URL pública de demostración.

Prueba primero los tres presets y después combina requisitos manualmente:

• Checklist local: no selecciona requisitos adicionales y devuelve candidato estático local.
• Consulta de API pública: activa una integración y exige revisión técnica.
• Portal de clientes: activa cuentas, datos personales y base compartida; queda fuera del tutorial.

Descarga el TXT en cada estado y comprueba que coincidan título, contador, motivos y siguiente paso. Luego restablece: no deberían quedar checkboxes, motivos ni estado de una selección anterior.

Prueba comportamientos, no solo si la página abre

Los criterios se dividieron para que una cifra no oculte qué se observó:

El E2E comprobó HTTP 200, un H1, main, skip link, fieldset y labels; recorrió preset, cambio de estado, descarga y restablecimiento con teclado. Registró cero errores de consola o página, requests fallidas o respuestas HTTP de error. El ancho del documento no superó el viewport en 375, 768 ni 1280 px.

Es un buen gate para este artefacto, no un certificado universal. No hubo pruebas en otros navegadores, lector de pantalla, Lighthouse, CrUX de campo ni sesiones con usuarios. Tampoco se evaluaron seguridad, publicación, backend, autenticación, datos personales o mantenimiento a largo plazo.

Repite el método con tu propia idea

No empieces el siguiente prototipo cambiando nombres en el código. Redefine el contrato:

1. Elige una sola decisión o tarea que pueda terminar dentro del navegador.
2. Sustituye datos reales por opciones cerradas o fixtures ficticios durante la primera prueba.
3. Enumera todos los estados válidos, incluidos vacío, error y límite.
4. Escribe la regla exacta de transición y la precedencia entre casos.
5. Decide qué salida debe conservarse y qué información nunca debe entrar.
6. Añade casos normales, combinaciones y un caso que fuerce el estado más restrictivo.
7. Prueba teclado, móvil, descarga, reset, consola, red y almacenamiento.
8. Conserva brief, código, fixtures, resultados y hashes de la versión que revisaste.

Si una corrección cambia propósito, datos o regla principal, no la trates como pulido. Actualiza la versión del brief y repite los casos afectados. El objetivo no es mantener un prompt intacto para siempre, sino poder explicar qué especificación produjo cada resultado.

Cuándo dejar de iterar solo y pedir ayuda

Puedes conservar una utilidad como prototipo personal mientras sus datos sean ficticios o autorizados, no necesite compartir estado y un fallo sea fácil de detectar y revertir. Detente y pide revisión técnica antes de continuar si aparece cualquiera de estas condiciones:

• identidad, inicio de sesión, roles o permisos;
• datos personales, confidenciales o de clientes;
• una base de datos compartida, sincronización o edición simultánea;
• APIs con credenciales, archivos subidos o tareas que siguen en segundo plano;
• pagos, suscripciones o acciones difíciles de deshacer;
• varios usuarios, obligaciones de disponibilidad o necesidad de recuperar información;
• ausencia de pruebas, logs, copias, responsables o un plan de mantenimiento.

Agregar una API no convierte necesariamente la idea en imposible, pero sí introduce contratos, errores de red, secretos y límites que esta miniapp no cubre. Si lo que necesitas es que el sistema decida rutas y actúe sobre otras herramientas, aclara primero la diferencia entre chatbot, workflow y agente de IA; es otra arquitectura, no un interruptor más.

Lovable, Bolt y Replit: documentación, no una comparativa probada

Las siguientes filas resumen capacidades descritas por cada proveedor y consultadas el 14 de agosto de 2026. Ranquia no ejecutó el brief en estas plataformas, por lo que no hay ganador, mediciones de facilidad, precio, calidad ni equivalencia entre planes o cuentas.

DOCUMENTED significa que la capacidad aparece en una fuente primaria vigente para una superficie concreta; no que Ranquia la haya usado. NOT_TESTED significa que no existe resultado local para esa plataforma, no que la función falle o no exista. Comprueba disponibilidad, límites y condiciones en tu cuenta antes de elegir.

Una vez acotada la idea, usa la plantilla para evaluar una herramienta de IA antes de pagar con una candidata concreta. No pagues solo porque una landing page muestre una app más compleja que la que sabes describir y comprobar.

Qué demuestra el kit y qué permanece sin probar

Esta guía utiliza tres etiquetas para evitar que una captura se convierta en una conclusión mayor:

• HARNESS_VERIFIED: el artefacto local implementa ocho toggles, tres estados, presets, reset y TXT; las propiedades declaradas quedaron respaldadas por tests, logs, hashes o capturas reproducibles.
• DOCUMENTED: una fuente primaria describe una capacidad de un proveedor; no prueba que el caso de Ranquia funcionaría igual allí.
• NOT_TESTED: no se ejecutó o no se pudo verificar localmente. No debe interpretarse como cero, fallo ni ausencia de capacidad.

Permanecen NOT_TESTED: Lovable, Bolt y Replit; cualquier publicación externa; backend, autenticación, bases de datos, pagos, secretos o datos personales; seguridad; costes y tiempos; mantenimiento por una persona no técnica; navegadores distintos de Chromium; lector de pantalla y usuarios; Lighthouse y Core Web Vitals de campo.

Si decides mantener tu prototipo durante varias semanas, mide por separado el trabajo de corregirlo, actualizarlo y explicar sus límites. La guía para medir durante siete días si la IA ahorra tiempo puede ayudarte a no confundir velocidad de generación con ahorro humano sostenido.

Método y versión

El artefacto se preparó localmente el 14 de agosto de 2026 desde un brief congelado antes del código. La versión descargable fue empaquetada dos veces con el mismo hash, extraída en un directorio temporal y probada desde esa extracción. El manifiesto público hashea ZIP, brief y README y se excluye a sí mismo.

El flujo local estuvo asistido por Codex; no fue una prueba de los tres builders comerciales ni un estudio de facilidad con personas no técnicas. Las iteraciones conservaron hallazgos y correcciones reales. Contrasta los archivos con el manifiesto SHA-256 si vuelves a utilizar el kit o si cambia su versión.