Llevar una app a producción consiste en apilar capas sobre lo que ya funciona. El diagrama de abajo muestra el orden: empezar por la app en línea, protegerla con autenticación y RLS, monetizarla con pagos y, por último, conectar workflows externos mediante un webhook.

Diagrama ilustrativo — recreación conceptual de las capas de producción, no es una captura de pantalla real.

Una app sin inicio de sesión es una app abierto: cualquier persona con la URL puede activar el workflow y consumir tus tokens de IA, y tú pagas por el uso de los demás. Autenticarse resuelve dos problemas a la vez: protege el uso (solo los usuarios registrados activan el backend) y protege los datos (cada quien solo ve lo suyo).

O Supabase entra como proveedor de base de datos y autenticación: en Plan Mode, le pides a la IA que agregue el inicio de sesión y el registro a la app usando Supabase. En la plataforma, creas el proyecto y defines el contraseña de la base de datos (distinta de la contraseña de inicio de sesión) y eliges la región.

Configuración de Supabase

Row-Level Security son reglas que viven dentro de la base de datos, no en el código de la interfaz. Garantizan que cada usuario solo vea sus propias filas, incluso si hay un error en el frontend. Es una capa de defensa que no depende de que el código de la pantalla sea perfecto: un bloqueo en el nivel más profundo.

Dos configuraciones hacen que la autenticación funcione de principio a fin. La migración SQL: ejecutar en el SQL editor de Supabase el SQL generado por la IA para crear la tabla (p. ej., la tabla de leads). Y las URLs de autenticación: configurar la URL de la app (Vercel) y la redirect URL, para que el inicio de sesión vuelva correctamente a la app.

-- migração gerada pela IA
create table leads (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users not null,
  empresa text,
  score int,
  created_at timestamptz default now()
);

-- liga o Row-Level Security
alter table leads enable row level security;

Antes de continuar, haz una auditoría explícita: limpia la conversación y pídele a la IA que actúe como especialista en seguridad y revise la app. Una auditoría solicitada a propósito detecta vulnerabilidades que pasan desapercibidas en el día a día y te da una lista clara de lo que debes corregir.

La lista de verificación de la auditoría

Con el Stripe, la aplicación se convierte en un SaaS: un modelo freemium con un tier gratis limitado y un tier pago por suscripción, vía Stripe Checkout. La motivación es la misma que para la autenticación —limitar el uso para que no pagues por el consumo ilimitado de IA de los usuarios—, pero ahora con ingresos del otro lado.

La integración de Stripe reúne cuatro piezas que vienen de distintos momentos. Creas el producto recurrente y copia el price ID; toma las claves (publicable + secreta); crea el webhook apuntando a tu URL con los eventos correctos; y ejecuta la migración de la tabla de suscripciones en Supabase.

Las piezas de la integración

Para darle una interfaz atractiva a un workflow de n8n, el patrón es cambiar dos nodos: el primero (el formulario) por un Webhook trigger, y el último por un nodo "Respond to Webhook". El frontend (generado y mejorado con la skill de diseño) envía los datos a la URL del webhook y muestra la respuesta; está conectado mediante una env var en Vercel.

Convertir el workflow + conectar el frontend

Todo el recorrido es una lección de iteración incremental: la app empezó como un prompt de una frase y creció por capas — diseño → autenticación → pago → integración. La buena ingeniería es así: empezar en pequeño, publicar pronto y escalar según la necesidad, sin planificarlo todo de una vez.

Las capas, en orden