← Todas las guías
Método Esclusa Construye con IA

De la idea a una aplicación en producción

El camino completo para convertir un prototipo hecho con IA en una aplicación real: arquitectura, base de datos, servidor, claves, despliegue, automatizaciones y mantenimiento.

4 min de lecturaRevisada en octubre de 20263 fuentes

Cuándo un artefacto ya no basta

Un artefacto vive en el navegador de quien lo abre. En cuanto necesitas cualquiera de estas cosas, necesitas una aplicación con su parte de servidor:

  • Datos compartidos entre varias personas o que sobrevivan al navegador.
  • Llamar a una API con una clave secreta, incluida la de un modelo de IA.
  • Usuarios con contraseña de verdad.
  • Trabajos que se ejecutan solos (actualizar datos cada hora, enviar avisos).

Una arquitectura sencilla que escala

Para la mayoría de herramientas de empresa basta con cuatro piezas. Así está construido, por ejemplo, nuestro seguimiento de golfistas en la NCAA, que se actualiza solo cada tres horas:

PiezaQué haceEjemplo
InterfazLo que ve el usuarioHTML estático en Cloudflare Pages
Servidor ligeroGuarda las claves, habla con APIs y con la base de datosCloudflare Workers o funciones serverless
Base de datosLos datos compartidosCloudflare D1, Supabase o Postgres
Tareas programadasLo que se hace soloCron triggers del propio servidor

Cómo pedirle a la IA la arquitectura antes que el código

El error más caro es empezar escribiendo código. Primero, que la IA te proponga el diseño y lo discutáis:

Prompt de arquitecturaQuiero convertir este prototipo [adjunta el HTML] en una aplicación real. Requisitos: - La usarán 15 personas de mi empresa, con usuario y contraseña. - Los datos tienen que compartirse entre todos y guardarse. - Una vez al día tiene que traer datos de [fuente] y actualizar la tabla. - Presupuesto: lo más cercano a cero posible. Tráfico bajo. - Datos en la Unión Europea. Antes de escribir código: 1. Propón la arquitectura (piezas, servicios concretos y por qué). 2. Dibuja el modelo de datos: tablas, campos y relaciones. 3. Lista los riesgos de seguridad y cómo los cubres. 4. Dime el coste mensual estimado y qué lo haría subir. 5. Divide la construcción en fases que pueda probar por separado. No escribas código hasta que te confirme el diseño.

El servidor: dónde viven las claves

Un Worker es un pequeño programa que responde a peticiones. Aquí, uno que lee de la base de datos y otro trozo que se ejecuta solo cada tres horas:

worker.jsexport default { // Responde a la interfaz: GET /api/jugadoras async fetch(request, env) { const url = new URL(request.url); if (url.pathname === "/api/jugadoras") { const { results } = await env.DB .prepare("SELECT nombre, universidad, puesto FROM jugadoras ORDER BY puesto") .all(); return Response.json(results); } return new Response("No encontrado", { status: 404 }); }, // Se ejecuta solo según el cron configurado async scheduled(event, env, ctx) { const datos = await fetch("https://fuente-de-datos.example/api").then(r => r.json()); for (const j of datos) { await env.DB.prepare("UPDATE jugadoras SET puesto = ? WHERE nombre = ?") .bind(j.puesto, j.nombre).run(); } } };
wrangler.tomlname = "mi-app" main = "worker.js" compatibility_date = "2026-01-01" [[d1_databases]] binding = "DB" database_name = "mi-app-db" database_id = "el-id-que-te-da-cloudflare" [triggers] crons = ["0 */3 * * *"]

Las claves se guardan como secretos del servidor (npx wrangler secret put NOMBRE) y se leen con env.NOMBRE. Nunca aparecen en el HTML.

Construir por fases

  1. Datos: crea la base de datos y carga diez filas reales a mano.
  2. Lectura: el servidor devuelve esas filas y la interfaz las pinta.
  3. Escritura: la interfaz puede crear y editar, con validación en el servidor.
  4. Acceso: usuarios y permisos. Usa la autenticación del proveedor (Cloudflare Access, Supabase Auth); no te inventes la tuya.
  5. Automatización: las tareas programadas, primero ejecutadas a mano.
  6. Producción: dominio, copias de seguridad y avisos de error.

Al final de cada fase, prueba en el navegador antes de seguir. Pídele a la IA que te diga exactamente qué comprobar.

Los errores que más se repiten

  • Claves en el código del navegador. Cualquier clave que llegue al navegador es pública. Las claves de API viven solo en el servidor, como secretos.
  • Sin copia de la base de datos. El primer borrado accidental llega antes de lo que crees. Exporta de forma automática y prueba a restaurar una vez.
  • Confiar en lo que llega del navegador. Precios, permisos o identificadores de usuario que manda el cliente se pueden falsificar. El servidor comprueba todo.
  • Un solo entorno. Probar cambios directamente donde están los usuarios. Ten al menos una versión de pruebas separada.
  • Nadie sabe que se ha caído. Una comprobación automática cada pocos minutos que te avise si la aplicación no responde cuesta poco y evita enterarte por un cliente.

Lista antes de abrirla a usuarios

  1. Claves solo en el servidor, y ninguna en el repositorio.
  2. Inicio de sesión y permisos comprobados en el servidor para cada acción.
  3. Copia automática de la base de datos y restauración probada.
  4. Entorno de pruebas separado del real.
  5. Aviso legal, política de privacidad y, si recoges datos personales, base legal de cada tratamiento.
  6. Monitor de disponibilidad y alertas de error.
  7. Límite de gasto en todos los servicios de pago que use.

Mantenerla viva

  • Copias de seguridad de la base de datos, automáticas y probadas: restaura una al menos una vez.
  • Registro de errores: que el servidor guarde los fallos y te avise si se repiten.
  • Un archivo de contexto en el proyecto (arquitectura, reglas, decisiones) para que la IA no rompa nada en la siguiente sesión. Es la diferencia entre mantener una app y reescribirla cada mes.
  • Cambios pequeños y probados, con control de versiones (Git) aunque trabajes solo.

Fuentes

Contenido redactado por Esclusa a partir de la documentación oficial citada. Los modelos, precios y funciones cambian a menudo: comprueba la fuente antes de tomar decisiones.

@esclusa.ia