Cómo los fundadores no técnicos lanzan SaaS con flujos de trabajo de IA

Lo que puedes construir con IA (y lo que aún te pertenece)

La IA puede llevarte sorprendentemente lejos en un producto SaaS—even si no escribes código—porque puede esbozar pantallas de UI, generar endpoints de backend, conectar bases de datos y explicar cómo desplegar. Lo que no puede hacer es decidir qué importa, verificar la corrección o asumir la responsabilidad por resultados en producción. Tú sigues teniendo el timón.

Qué significa realmente “lanzar”

En este post, lanzar significa: un producto usable en un entorno real que personas reales pueden iniciar sesión y usar. La facturación es opcional al principio. “Lanzado” no es un archivo de Figma, no es un enlace a un prototipo, y no es un repo que solo funciona en tu portátil.

En qué la IA es buena (y en qué no lo es)

La IA es excelente en ejecución rápida: generar andamiaje, sugerir modelos de datos, escribir funciones CRUD, redactar plantillas de correo y producir pruebas iniciales.

La IA todavía necesita dirección y verificaciones: puede alucinar APIs, pasar por alto casos límite, crear valores por defecto inseguros o desviarse silenciosamente de los requisitos. Trátala como un asistente junior extremadamente rápido: útil, pero no autoritario.

El flujo que seguirás en esta guía

Avanzarás a través de un bucle simple:

1. Elige un problema estrecho + una métrica de éxito
2. Escribe una especificación de una página que la IA pueda implementar
3. Diseña la UX + el modelo de datos
4. Elige una pila mínima + hosting
5. Usa un sistema de prompting para generar código fiable
6. Construye un MVP en iteraciones demostrables
7. Añade pruebas y salvaguardas
8. Asegura, despliega, monitoriza y lanza con feedback

Lo que aún posees (y qué confirmar)

Normalmente posees la idea del producto, la marca, la lista de clientes y el código que guardas en tu repositorio—pero verifica los términos de tus herramientas de IA y cualquier dependencia que copies. Adopta el hábito de guardar las salidas en tu propio proyecto, documentar decisiones y evitar pegar datos propietarios de clientes en los prompts.

Habilidades mínimas que necesitas (y lo que puedes saltarte)

Necesitas: escritura clara, pensamiento de producto básico y paciencia para probar e iterar. Puedes saltarte: ciencias de la computación profundas, arquitectura compleja y código “perfecto”—al menos hasta que los usuarios demuestren que importa.

Empieza con un problema estrecho y una métrica de éxito clara

Si confías en la IA para ayudarte a construir, la claridad se convierte en tu mayor palanca. Un problema estrecho reduce la ambigüedad, lo que significa menos funciones “casi correctas” y más salidas utilizables.

Elige un usuario objetivo y una tarea dolorosa

Empieza con una sola persona que puedas imaginar, no con un segmento de mercado. “Diseñadores freelance que facturan clientes” es mejor que “pequeñas empresas.” Luego nombra una tarea que ya estén intentando hacer—especialmente una repetitiva, estresante o con tiempo crítico.

Una prueba rápida: si tu usuario no puede decir en 10 segundos si tu producto es para ellos, sigue siendo demasiado amplio.

Escribe una propuesta de valor en una sola frase

Mantenla simple y medible:

“Ayuda a [usuario objetivo] a [hacer la tarea] mediante [cómo] para que puedan [resultado].”

Ejemplo: “Ayuda a diseñadores freelance a enviar facturas precisas en menos de 2 minutos auto‑construyendo las partidas desde notas de proyecto para que cobren más rápido.”

Define métricas de éxito para la semana 1 y la semana 4

Las métricas evitan que la construcción asistida por IA se convierta en “colección de funciones.” Elige números simples que puedas rastrear:

• Semana 1 (activación): % de registros que completan la acción central (p. ej., crear su primera factura)
• Semana 4 (retención + ingresos): % que repiten la acción central semanalmente y conversiones de pago o $ generados

Identifica la ruta feliz mínima

Lista solo los pasos que un usuario debe completar para obtener el resultado prometido—sin extras. Si no puedes describirlo en 5–7 pasos, recorta.

Crea una lista “no ahora”

La expansión de alcance es la razón nº1 por la que los builds con IA se atascan. Escribe añadidos tentadores (roles multiusuario, integraciones, app móvil, paneles) y etiquétalos explícitamente como “no ahora.” Eso te da permiso para lanzar la versión más simple primero y mejorar basándote en uso real.

Convierte tu idea en una especificación de una página que la IA pueda ejecutar

La IA puede escribir código rápidamente, pero no puede adivinar lo que quieres decir. Una especificación de una página (piensa en un “mini PRD”) le da al modelo una única fuente de verdad que puedes reutilizar en prompts, revisiones e iteraciones.

Paso 1: Redacta un PRD de una página (con IA)

Pide a la IA que genere un PRD de una página que incluya:

• Problema: qué dolor existe y para quién
• Usuario: tipo(s) de usuario primario y qué intentan lograr
• Flujo: los pasos de la ruta feliz desde el inicio hasta el éxito
• Funcionalidades imprescindibles: el conjunto mínimo que entrega valor

Si quieres una estructura simple, usa:

• Objetivo: …
• Usuario objetivo: …
• Recorrido del usuario: 1) … 2) … 3) …
• Funciones MVP: …
• Fuera del alcance (por ahora): …
• Métrica de éxito: … (p. ej., “el usuario puede terminar X en menos de 2 minutos”)

Paso 2: Convierte el PRD en historias de usuario (con criterios de aceptación)

Convierte cada función del MVP en 3–8 historias de usuario. Para cada historia exige:

• Como [usuario], quiero [acción], para que [beneficio].
• Criterios de aceptación: resultados específicos y comprobables (“Cuando hago clic en Guardar, veo una confirmación y el registro aparece en la lista en menos de 2 segundos.”)

Paso 3: Obliga a la claridad: supuestos y casos límite

Pide a la IA listar supuestos poco claros y casos límite: estados vacíos, entradas inválidas, errores de permisos, duplicados, reintentos y “¿qué pasa si el usuario abandona a mitad?” Decide cuáles son obligatorios en v0.1.

Paso 4: Crea un glosario para mantener consistencia en los prompts

Define términos clave (p. ej., “Workspace”, “Miembro”, “Proyecto”, “Estado de factura”). Reusa este glosario en cada prompt para evitar que el modelo renombre conceptos.

Paso 5: Bloquea el alcance de la primera versión: “MVP v0.1”

Termina tu una‑página con una estricta checklist MVP v0.1: qué está incluido, qué se excluye explícitamente y qué significa “hecho”. Esta es la especificación que pegarás en tu flujo de IA cada vez.

Diseña la UX y el modelo de datos sin atascarte

No necesitas pantallas perfectas ni un diseño de base de datos “real” para empezar. Necesitas una imagen compartida de qué hace el producto, qué información almacena y qué cambia cada página. Tu objetivo es eliminar la ambigüedad para que la IA (y luego las personas) implementen de forma consistente.

1) Genera wireframes de baja fidelidad (rápido)

Pide a la IA wireframes sencillos usando bloques de texto: páginas, componentes y navegación. Manténlo básico—cajas y etiquetas.

Ejemplo de prompt: “Crea wireframes de baja fidelidad para: Login, Dashboard, Lista de proyectos, Detalle de proyecto, Ajustes. Incluye navegación y componentes clave por página.”

2) Define tus objetos de datos principales en lenguaje claro

Escribe 3–6 objetos que almacenarás, como frases:

• Usuario: una persona que inicia sesión y posee proyectos.
• Proyecto: un espacio de trabajo con nombre, estado y miembros.
• Elemento: un registro dentro de un proyecto (tarea, ticket, nota—elige uno).

Luego pide a la IA proponer un esquema de base de datos y explicarlo en términos simples.

3) Mapea cada página a lo que lee/escribe

Esto evita que aparezcan funciones “aleatorias” en la implementación.

Un mapeo simple:

• Dashboard: lee Proyectos; lee Items recientes.
• Lista de proyectos: lee Proyectos; escribe Proyecto (crear).
• Detalle de proyecto: lee Proyecto + Items; escribe Item (crear/actualizar/completar).

4) Crea reglas de UI para que el producto se sienta consistente

Mantén una lista corta de “reglas de UI”:

• Tono del texto: amable, conciso, sin jerga.
• Estados vacíos: explica qué hacer a continuación (“Crea tu primer proyecto”).
• Estados de error: indica qué pasó y cómo arreglarlo (“El título es obligatorio”).
• Estados de carga: muestra esqueletos para listas.

Si haces solo una cosa: asegura que cada página tenga una acción primaria clara y que cada objeto de datos tenga un propietario claro (normalmente el usuario u organización).

Elige una pila tecnológica simple y un plan de hosting

Una pila simple no se trata de “qué es más guay” sino de qué es aburrido, documentado y fácil de recuperar cuando algo falla. Para la v1, elige por defecto lo que miles de equipos usan y que los asistentes IA pueden generar de forma fiable.

Una pila por defecto probada para v1

Si no tienes restricciones fuertes, esta combinación es un punto de partida seguro:

• Frontend + backend: Next.js (un único código para páginas + rutas API)
• Base de datos: Postgres
• ORM: Prisma (esquema claro, migraciones sencillas)
• Auth: Clerk o Supabase Auth (configuración rápida, buena documentación)
• Hosting: Vercel (despliegues rápidos, previews simples)

Si prefieres construir vía un flujo orientado a chat en lugar de cablear todo manualmente, plataformas como Koder.ai pueden generar una UI React más un backend Go con PostgreSQL, manejar despliegue/hosting y dejarte exportar el código fuente cuando quieras control total.

Decide tu modo de construcción (y sé honesto)

Elige una de estas opciones:

• IA + revisión humana mínima: tú diriges prompts, la IA escribe código, usas checklists/pruebas y contratas una revisión pagada en hitos clave.
• IA + auditorías programadas por un desarrollador: un contratista revisa seguridad, acceso a datos y despliegue antes de recibir usuarios reales.

Si manejas pagos o datos sensibles, presupuestar auditorías temprano.

Hosting, base de datos y auth con bajo overhead

Apunta a servicios gestionados con paneles, backups y valores por defecto sensatos. “Funciona en una tarde” vence a “configurable en teoría.” Postgres gestionado (Supabase/Neon) + auth gestionada evita semanas de configuración.

Define entornos desde el principio

Ten tres:

• Local: tu máquina
• Staging: espejo seguro para pruebas (con datos de prueba)
• Producción: usuarios reales

Haz que “despliegues a staging en cada merge a main” sea una regla.

Checklist de herramientas reutilizables

Mantén una checklist de una página que copies en cada nuevo proyecto:

• Repo + reglas de ramas, checks de CI, formatter/linter
• Gestión de secretos (dónde viven las claves)
• Migraciones de BD + backups
• Configuración del proveedor de auth
• Logging/monitorización (p. ej., Sentry)
• URLs y pasos de despliegue para staging + producción

Esa checklist se convierte en tu ventaja de velocidad en el proyecto #2.

Tu sistema de prompting: cómo obtener salidas de código fiables

Sacar buen código de la IA no se trata de frases ingeniosas: se trata de un sistema repetible que reduce la ambigüedad y te mantiene en control. El objetivo es que la IA actúe como un contratista enfocado: brief claro, entregables claros, criterios de aceptación claros.

Usa una plantilla de prompt repetible

Reusa la misma estructura para no olvidar detalles clave:

• Contexto: qué es el producto, para quién es, estado actual
• Objetivo: qué quieres construir en este paso
• Restricciones: pila, reglas de estilo, librerías permitidas, “no cambies X”
• Archivos: pega archivos relevantes o árbol de carpetas (aunque sea parcial)
• Formato de salida: “devuelve un patch/diff”, “devuelve contenidos exactos de archivos”, “incluye tests”, “incluye comandos para ejecutar”

Esto reduce “cambios misteriosos” y hace las salidas más fáciles de aplicar.

Pide tickets antes del código

Antes de escribir nada, pide a la IA que proponga un desglose de tareas:

• “Crea 5–8 tickets para implementar restablecimiento de contraseña. Incluye riesgo estimado, archivos afectados y criterios de aceptación.”

Elige un ticket, bloquea su definición de hecho y luego procede.

Trabaja en porciones pequeñas

Pide solo una función, un endpoint o un flujo de UI a la vez. Prompts más pequeños producen código más preciso y puedes verificar el comportamiento rápidamente (y revertir si hace falta).

Si tu herramienta lo soporta, usa un paso de “modo planificación” (esquema primero, implementación después) y confía en snapshots/rollback para deshacer iteraciones malas—esto es exactamente el tipo de red de seguridad que plataformas como Koder.ai incorporan al flujo.

Mantén un registro de decisiones

Mantén un doc simple con: qué elegiste y por qué (método de auth, campos de datos, convenciones de nombres). Pega las entradas relevantes en los prompts para que la IA se mantenga coherente.

Define “hecho” por ticket

Para cada ticket exige: comportamiento demoable + tests + una nota corta en docs (incluso un snippet en el README). Eso mantiene la salida enviable, no solo “con forma de código”.

Construye el MVP en iteraciones que puedas demostrar a diario

La velocidad no es escribir más código: es reducir el tiempo entre “cambio hecho” y “una persona real puede probarlo”. Un bucle de demostración diario mantiene el MVP honesto y evita semanas de trabajo invisible.

Día 1: Obtén un esqueleto end-to-end que funcione

Empieza pidiéndole a la IA el app mínimo que arranque, cargue una página y pueda desplegarse (aunque sea feo). Tu objetivo es una canalización funcionando, no funciones.

• Inicializa el repo y el esqueleto básico; confirma que corre end-to-end.

Una vez que funcione localmente, haz un cambio mínimo (p. ej., cambia un título) para confirmar dónde están los archivos. Commitea temprano y a menudo.

Día 2: Añade control de acceso antes de agregar “cosas reales”

La autenticación es molesta de añadir después. Agrégala mientras la app es pequeña.

• Añade autenticación y la primera página protegida pronto.

Define qué puede hacer un usuario autenticado y qué ve un visitante. Manténlo simple: email + contraseña o magic link.

Días 3–5: Lanza un “bucle central” completo

Elige el objeto central de tu SaaS (un “Proyecto”, “Factura”, “Campaña”, etc.) e implementa el flujo completo.

• Implementa el flujo CRUD principal para tu objeto central.

Entonces hazlo usable, no perfecto:

• Añade estados básicos de UI: carga, vacío, error, éxito.

Diario: Demuestra la ruta feliz y anota confusiones

Cada día, demoa la app como si ya se vendiera.

• Muestra la ruta feliz a un amigo y captura puntos de confusión.

Pídeles que narren qué creen que va a pasar antes de hacer clic. Convierte su confusión en las tareas del día siguiente. Si quieres un ritual ligero, mantiene una checklist “Mañana” en tu README y trátala como mini roadmap.

Añade pruebas, revisiones y salvaguardas (sin convertirte en desarrollador)

Si la IA escribe grandes porciones de tu código, tu trabajo cambia de “teclear” a “verificar”. Una pequeña estructura—tests, checks y un flujo repetible de revisión—evita el fallo más común: lanzar algo que parece terminado pero se rompe con uso real.

Checklist de revisión de código por IA (copia/pega)

Pide a la IA que revise su propia salida contra esta checklist antes de aceptar un cambio:

• Corrección: ¿Coincide con la especificación y la métrica de éxito? ¿Faltan casos límite?
• Legibilidad: nombres claros, funciones cortas, comentarios solo donde se necesitan.
• Seguridad: validación de inputs, comprobaciones de auth, sin secretos en el código, uploads seguros.
• Logs: mensajes útiles para acciones clave y fallos (sin loggear contraseñas/tokens).
• Modos de fallo: ¿qué pasa en timeouts, resultados vacíos o caídas de terceros?

Pruebas que realmente necesitas para un MVP

No necesitas “cobertura perfecta.” Necesitas confianza en las partes que pueden perder dinero o confianza silenciosamente.

1. Tests unitarios para lógica central (reglas de precios, cheques de permisos, validación de datos).

2. Tests de integración para flujos clave (registro → crear cosa → pagar → ver resultado). Pide a la IA que genere estos tests según tu PRD de una página y que explique cada test en lenguaje simple para que entiendas qué protege.

Salvaguardas que mantienen el repo limpio

Añade linting/formatting automático para que cada commit sea consistente. Esto reduce la “ensalada IA” y abarata futuras ediciones. Si ya tienes CI, ejecuta formateo + tests en cada pull request.

Una plantilla ligera de bug (para ti y la IA)

Cuando encuentres un bug, regístralo igual siempre:

• Qué esperaba:
• Qué pasó en su lugar:
• Pasos para reproducir:
• Captura / mensaje de error:
• Contexto de usuario/cuenta: (rol, plan, navegador)

Luego pega la plantilla en tu chat con la IA y pide: causa probable, corrección mínima y un test que evite regresiones.

Seguridad y fiabilidad básicas para usuarios reales

Lanzar un MVP es emocionante—luego llegan los primeros usuarios reales con datos reales, contraseñas reales y expectativas reales. No necesitas ser experto en seguridad, pero sí necesitas una lista corta que realmente sigas.

Maneja secretos de forma aburrida (siempre)

Trata las claves API, contraseñas de BD y secretos de firma como “nunca en el repo”.

• Guarda secretos en variables de entorno (tu host suele tener una pantalla “Secrets” o “Environment”).
• Mantén un .env.example con marcadores, no valores reales.
• Si una clave llega al historial de Git, asume que está comprometida: rótala inmediatamente.

Haz explícito el acceso a datos

La mayoría de brechas tempranas son simples: una tabla o endpoint que cualquiera puede leer.

• Escribe roles (por ejemplo, anónimo, usuario, admin) y qué puede leer/escribir cada uno.
• Asegura que cada consulta esté acotada (ej.: “el usuario solo accede a filas donde user_id = current_user).
• Añade una prueba rápida de permisos en QA: intenta acceder al registro de otro usuario desde una segunda cuenta.

Añade protección básica contra abuso

Incluso apps pequeñas sufren bots.

• Limita la tasa de login, registro, restablecimiento de contraseña y endpoints caros.
• Añade topes en uploads (tamaño/tipo) y jobs en background.
• Considera medidas anti‑abuso simples (verificación por email, CAPTCHA solo donde haga falta).

Sabe cuándo algo se rompe

No puedes arreglar lo que no ves.

• Configura seguimiento de errores (Sentry, etc.) para frontend y backend.
• Loggea eventos clave (fallos de auth, pagos, webhooks) con IDs de petición.
• Crea alertas para picos en errores, latencia o pagos fallidos.

Publica un resumen simple de privacidad y retención

Escribe una página corta y comprensible: qué recoges, por qué, dónde se almacena, quién puede acceder y cómo pueden los usuarios borrar sus datos. Mantén la retención mínima por defecto (p. ej., borrar logs tras 30–90 días salvo necesidad).

Despliega, monitoriza y prepara un lanzamiento seguro

Lanzar no está “hecho” cuando la app funciona en tu portátil. Un lanzamiento seguro significa que tu SaaS puede desplegarse repetidamente, vigilarse en producción y revertirse rápido cuando algo falla.

Delega en CI (para que no tengas que hacerlo)

Configura integración continua para ejecutar tus tests en cada cambio. El objetivo: nadie puede mergear código que falle checks. Empieza simple:

• Ejecuta tests unitarios/integración en cada PR
• Bloquea merges con tests o lint fallando
• Publica una build preview cuando sea posible (opcional)

Aquí la IA también ayuda: pídele que genere tests faltantes para los archivos cambiados en un PR y que explique fallos en lenguaje sencillo.

Añade staging: tu entorno de “ensayo”

Crea un entorno staging que refleje producción (mismo tipo de BD, mismo patrón de env vars, mismo proveedor de email—solo credenciales de prueba). Antes de cada release verifica:

• Registro/login funcionando end-to-end
• Pagos (en modo de prueba) completándose correctamente
• Correos que envían y enlaces apuntando al entorno correcto

Escribe un runbook de despliegue (una página)

Un runbook evita “despliegues en pánico.” Mantenlo corto:

1. Pasos exactos de despliegue
2. Quién pulsa el botón y quién monitorea
3. Plan de rollback (cómo revertir y cuándo)
4. Dónde están logs/alertas

Instrumenta lo que importa

Añade analytics o tracking de eventos para acciones clave: registro, tu paso principal de activación y el clic de upgrade. Acompáñalo de monitorización de errores básica para ver crashes antes de que los usuarios te escriban.

Checklist pre‑lanzamiento (rápido pero estricto)

Revisa rendimiento, maquetado móvil, plantillas de email y onboarding. Si alguno está flojo, pospone el lanzamiento un día—es más barato que perder confianza temprana.

Lanza con bucles de feedback y un plan de monetización simple

Un “lanzamiento” no es un día: es el inicio de aprendizaje con usuarios reales. Tu objetivo es (1) llevar a las personas al primer momento de éxito rápido y (2) crear rutas claras de feedback y pago cuando esté justificado.

Decide: cobrar ahora o después

Si aún estás validando el problema, puedes lanzar sin pagos (lista de espera, beta limitada o “solicitar acceso”) y enfocarte en activación. Si ya hay demanda fuerte (o reemplazas un flujo pagado existente), añade pagos temprano para no aprender lecciones equivocadas.

Regla práctica: cobra cuando el producto entregue valor de forma fiable y puedas soportar a los usuarios si algo falla.

Precios: 2–3 niveles basados en valor

Formula hipótesis de precios que reflejen resultados, no un grid largo de funciones. Por ejemplo:

• Starter: para individuos validando el flujo
• Pro: para equipos o mayor uso (más asientos, más ejecuciones, más historial)
• Business: para prioridades como cumplimiento, facturación o soporte dedicado

Pide a la IA que genere opciones de niveles y posicionamiento, y edita hasta que un amigo no técnico lo entienda en 20 segundos.

Haz que actualizar y pedir soporte sea muy sencillo

No escondas el siguiente paso. Añade:

• Un botón claro de “Actualizar” en la app
• Una página de facturación básica (aunque solo sea “gestionar plan”)
• Una vía de soporte obvia: “Envíanos un email” o un formulario corto

Si mencionas “contactar soporte”, hazlo clicable y rápido.

Onboarding, FAQs y bucles de feedback

Usa la IA para redactar pantallas de onboarding, estados vacíos y FAQs, luego reescríbelos para claridad y honestidad (especialmente sobre limitaciones).

Para feedback combina tres canales:

1. Prompt en la app (“¿Qué te detuvo hoy?”)
2. Encuesta por email tras 3–5 días (“¿Qué extrañarías si esto desapareciera?”)
3. Llamadas cortas con usuarios (15 minutos; obsérvalos usar el producto)

Rastrea temas, no opiniones. Tu mejor roadmap temprano son fricciones repetidas en onboarding y razones repetidas por las que la gente duda en pagar.

Trampas, soluciones y cuándo traer a un experto humano

La mayoría de proyectos SaaS construidos con IA no fallan porque el fundador no sepa “codear.” Fallan porque el trabajo se vuelve difuso.

Modos comunes de fallo (y soluciones rápidas)

Sobreconstrucción. Añades roles, equipos, facturación, analítica y rediseño antes de que nadie haya completado onboarding.

Solución: congela el alcance 7 días. Lanza solo el flujo más pequeño que pruebe valor (p. ej., “subir → procesar → resultado → guardar”). Todo lo demás al backlog.

Especificaciones poco claras. Le pides a la IA “construir un dashboard” y ella inventa funciones que no querías.

Solución: reescribe la tarea como una especificación de una página con inputs, outputs, casos límite y una métrica de éxito medible.

Confiar ciegamente en la IA. La app “funciona en mi máquina” pero se rompe con usuarios reales o datos distintos.

Solución: trata la salida de la IA como borrador. Exige pasos de reproducción, una prueba y una checklist de revisión antes de mergear.

Cuando el código de IA falla: una rutina de recuperación

1. Reproduce de forma fiable: pasos exactos, datos de ejemplo, esperado vs real.
2. Aísla el diff: revierte o aísla el último cambio hasta que el bug desaparezca.
3. Escribe un test primero: aunque sea “no debe fallar cuando X está vacío”.
4. Pide a la IA que arregle solo el test que falla: pega el error y las restricciones, no todo el repo.

Cuándo contratar a un experto humano

Trae ayuda para revisiones de seguridad (auth, pagos, uploads), tuning de rendimiento (queries lentas, escalado) e integraciones complejas (banca, salud, APIs reguladas). Unas horas de revisión senior pueden evitar reescrituras costosas.

Estimar costes y tiempos con entregables pequeños

Estima por porciones demoables: “login + logout”, “importar CSV”, “primer informe”, “checkout de facturación”. Si una porción no puede demostrarse en 1–2 días, es demasiado grande.

Un roadmap práctico de 30 días

Semana 1: estabiliza el flujo central y manejo de errores.

Semana 2: onboarding + analítica básica (activación, retención).

Semana 3: afina permisos, backups y revisión de seguridad.

Semana 4: itera desde feedback, mejora la página de precios y mide conversión.