Constructores de Apps IA

Qué incluye este pack

Estos siete cubren el espectro completo desde "escribe una frase, obtén una SaaS" hasta "da a los diseñadores control visual sobre mi codebase React real". No son intercambiables — cada uno apuesta por algo diferente sobre quién hace el trabajo y qué se genera.

Por qué importa

La categoría "IA construye tu app" pasó de truco a workflow real en 2025. Tres razones:

1. WebContainers: el runtime de Node en navegador de StackBlitz hace que un npm install completo + dev server arranque en 5 segundos dentro de una pestaña. Se acabó el "espera mientras provisionamos un sandbox".
2. Capacidad de código de modelos frontier: Claude Sonnet 3.7 y GPT-5 por fin escriben React que realmente compila y funciona al primer intento, no "casi funciona tras 3 arreglos".
3. Edición en vivo sobre codebases reales: Onlook es el avance — los diseñadores arrastran elementos en el navegador y emiten diffs limpios contra tu repo existente. Se acabó el "rediseñar en Figma → ingeniero reimplementa".

Resultado: construir una app CRUD desde un prompt ahora toma 15 minutos incluyendo auth, deploy y una base de datos real. El cuello de botella pasó de codificar a pensar producto.

Instala en un comando

# Instala el pack completo
tokrepo install pack/ai-app-builders

# O elige el que encaje en tu situación
tokrepo install bolt-diy
tokrepo install webstudio
tokrepo install onlook

La página TokRepo de cada recurso lista opciones hosted vs self-host, el coste típico de tokens por generación, y los targets de deploy soportados (Netlify, Vercel, Cloudflare Pages, Docker).

Trampas comunes

• WebContainer != Node: bolt.diy y Bolt.new corren apps en WebContainer, un runtime WASM compatible con Node. Algunos paquetes npm con bindings nativos no funcionan. Verifica tu stack antes de apostar un proyecto.
• Drift en código generado: el React generado por IA a menudo usa patrones ligeramente fuera de spec (hooks mal memoizados, bugs accidentales de cliente/servidor). Trata la generación como punto de partida, no producto terminado.
• Tools internos vs apps: Budibase y ToolJet son builders de tools internos — asumen un usuario empleado autenticado. No los lances como SaaS para clientes sin replantear auth, branding y casos borde.
• Onlook necesita un repo real: edita tu React, no un sandbox. Conectarlo requiere correr un proceso agente local. Trátalo como herramienta-de-instalación-única, no spin-up por tarea.
• Gasto de tokens en Bolt.new: generaciones de app completa pueden quemar 100k+ tokens por ronda. El tier hosted limita el uso; self-host bolt.diy con tu propia key Anthropic evita el límite pero te factura directo.

Cuando este pack solo no basta

Este pack genera el frontend. Para correr un producto real también necesitas:

• Un backend o CMS: ver CMS Headless para IA — Strapi, Directus, Hasura — la capa de datos estructurada para apuntar tu app generada.
• Una base de datos: las demos WebContainer de bolt.diy usan SQLite o en-memoria; producción necesita Postgres / Supabase / Neon.
• Auth: Bolt.new conecta Auth0 o Supabase Auth; si self-hosteas, plánealo explícito.
• Pipeline de deploy: elige Netlify o Cloudflare Pages y mantente.

Para sitios docs, páginas marketing o blogs producto, no necesitas este pack — ver Generadores de Sitios Estáticos & Docs. Los app builders resuelven una forma distinta de problema.

Errores conceptuales comunes

"Generaré una SaaS este finde". Quizá — pero el código generado es ~70% del trabajo. Flujos de auth, integración de pagos, multi-tenancy, estados de error, edge cases de mobile responsive, consent GDPR, accesibilidad y observabilidad son cosas que los builders saltan o hacen mal. Ese 30% restante es donde los productos viven o mueren.