Sistema mínimo viable para un solo founder: sitio, producto, pagos, datos y automatización

Abre launch-checklist.md: existe /pricing, pero no el Stripe Product; el login funciona, pero el estado de suscripción no se sincroniza; GA4 recibe page_view, pero el clic en el botón de pago no tiene evento; el formulario envía un correo, pero no crea una tarea.

Muchos desarrolladores independientes toman “funciona” como criterio de lanzamiento. Las brechas aparecen cuando un cliente de pago todavía requiere una activación manual o se supera un cupo gratuito antes de que alguien revise el consumo.

Un sistema mínimo viable para un solo founder no es viable por usar pocas herramientas. Sus acciones de negocio deben llegar hasta el resultado: la persona entra, recibe el producto, paga, obtiene acceso, genera datos útiles, envía feedback y encuentra atención cuando algo falla.

La primera tabla permite ubicar la entrega rota. Después podrás decidir qué capas necesitan una versión mínima y cuáles pueden esperar.

Tabla de aceptación: interfaces que deben cerrarse antes del lanzamiento

El criterio no es “todas las funciones existen”. Cada acción debe recorrer desde el disparador hasta el resultado. Stripe webhook, Supabase RLS y los eventos de GA4 suelen añadirse la noche anterior porque antes solo se comprobó que “la página renderiza”.

Estas son las interfaces que conviene probar de forma real:

Área	Interfaz que debe cerrarse	Omisión común	Acción de aceptación
Entrada del sitio	Las páginas cargan, no hay 404, cargan los assets y se monitorean builds	Se supera Cloudflare Free; nadie lee errores	Abrir inicio y precios en un dispositivo real; revisar historial de Cloudflare Pages
Forma del producto	Se define contenido/herramienta/SaaS y se muestra el precio	Solo hay descripción, sin precio ni compra; falta Stripe Product	Revisar Products/Prices en Stripe Dashboard; confirmar la oferta en /pricing
Pago completo	Funcionan Checkout Session, webhook, activación, fallo/cancelación y sincronización	No hay webhook; el pago no abre acceso; el reembolso no cambia estado	Completar un pago de prueba Stripe; revisar logs y tabla de suscripciones
Sistema de usuario	Funcionan login, RLS, sincronización y diferencia entre gratuito y pago	Hay login sin RLS; todos ven contenido de pago	Revisar subscriptions al entrar; probar RLS con una cuenta gratuita
Eventos de datos	Funcionan GA4/GSC, 5–8 eventos, pago/registro/prueba y alertas	GA4 solo tiene page_view; faltan clic de pago y registro	Verificar en GA4 DebugView; revisar consultas y páginas en GSC Performance report
Bucle de feedback	Se envía, entra a trabajo y tiene estado de atención	Solo llega un email, sin tablero ni seguimiento	Enviar feedback y comprobar su llegada al tablero o cola de correo
Frontera de automatización	Webhook/API/Cron tienen umbral, alerta y rollback	El fallo es silencioso; el límite se descubre después	Revisar uso de Workers; configurar umbral y monitoreo de errores
Control de costos	Se registra uso Cloudflare/Supabase y se conocen cupos y upgrades	Supabase Free inactivo se pausa; límite Workers pasa inadvertido	Revisar uso Cloudflare y actividad Supabase; documentar disparadores de upgrade

Cada fila requiere una acción real, no solo revisar configuración. Antes de lanzar, completa al menos un pago, una prueba de login y permisos, una validación de eventos y un envío de feedback.

Entrada del sitio: stack mínimo de despliegue y sus límites

El sitio es la primera capa. Una web estática o un framework ligero es un buen inicio, pero cantidad de builds, archivos y funciones dinámicas entran en el presupuesto. Cloudflare Pages y Astro reducen mantenimiento; sus cupos gratuitos no garantizan la arquitectura.

Tabla de selección del stack

Forma	Stack sugerido	Costo de build	Costo de funciones dinámicas	Uso adecuado
Sitio de contenido	Astro / Hugo / Hexo	Cloudflare Pages Free: 500 builds/month, 20.000 files, 25 MiB asset	Pages Functions cuenta en Workers	Blog, documentación, páginas SEO, páginas de producto
Sitio de herramienta	Astro + llamadas API	Igual	Llamadas API cuentan en Workers (100.000 requests/day)	Herramienta de una página, consulta, cálculo, visualización
SaaS	Astro + Supabase	Igual	Workers + Supabase Edge Functions	Varios usuarios, suscripciones, permisos, lectura y escritura en base

Al 26 de julio de 2026, los límites oficiales de Cloudflare Pages siguen indicando 500 builds mensuales en Free, timeout de 20 minutos, hasta 20.000 archivos y 25 MiB por asset. Las solicitudes de Pages Functions consumen Workers; Workers Free incluye 100.000 solicitudes diarias y 10 ms de CPU por invocación.

Que los assets estáticos no tengan costo no vuelve gratis al sistema completo. Con muchas imágenes, videos o descargas también cuentan almacenamiento de objetos, procesamiento CDN, transformaciones y egress.

Las páginas generadas con IA necesitan valor para el usuario

La guía de Google Search sobre IA generativa permite usarla en investigación y estructura. Generar muchas páginas sin valor añadido puede incumplir la política de scaled content abuse. Una entrada útil necesita producto, feedback y revisión reales, no cientos de páginas SEO automáticas.

Para rendimiento consulta la optimización de Astro 5. El sistema mínimo no necesita Lighthouse 100 antes de lanzar, pero sí páginas, assets y CTA funcionales y fallos de build visibles.

Capa de producto: ¿contenido, herramienta o SaaS para la primera versión?

La forma del producto determina la complejidad de pagos, usuarios, datos y automatización. Contenido, herramienta y SaaS no son botones equivalentes, sino compromisos operativos crecientes. La primera versión debe favorecer la tecnología más conocida, el pago más simple y la menor cantidad de datos.

Tabla para elegir la forma del producto

Forma	Complejidad técnica	Complejidad del pago	Datos de usuario	Adecuación inicial
Sitio de contenido	Baja: estático + CMS + SEO	Baja: pago único o gratis	Baja: email, RSS, comentarios	Alta: adquisición SEO, ingresos de contenido, validar demanda
Sitio de herramienta	Media: estático + API + backend ligero	Media: pago único o suscripción	Media: usuario ligero e historial	Media: validar función y cobro
SaaS	Alta: auth + base + suscripción + RLS	Alta: suscripción, uso, reembolso	Alta: usuarios, permisos, estado, aislamiento	Baja: demanda de pago clara y stack conocido

Criterios de decisión

Tres factores definen la primera forma:

1. Dominio del stack: si conoces Astro o Hugo, el contenido valida rápido la demanda. Con Supabase o Postgres, una herramienta o SaaS tiene menos riesgo de implementación.
2. Complejidad del pago: un pago único suele ser más simple que una suscripción, y esta más simple que el cobro por uso. Empieza con pago único o captura gratuita y añade complejidad cuando exista demanda.
3. Datos de usuario: el contenido puede requerir solo email y RSS; una herramienta necesita historial; un SaaS necesita identidad, permisos, estado de suscripción y aislamiento.

La forma no es una identidad. Si la acción central sigue inestable, un centro de cuenta, espacios de equipo y mercado de plantillas no deben ir primero.

Capa de pagos: no es el último botón, sino una entrada del modelo de datos

Los pagos son la capa de mayor riesgo. Influyen en base, usuarios, derechos, administración y notificaciones. Si Checkout cobra pero el webhook no da acceso, un reembolso no cambia estado o una suscripción vencida conserva permisos, el cumplimiento falló.

Lista de pasos del flujo de pago

Un circuito mínimo de Stripe incluye:

Paso	Objeto Stripe	Interfaz que debe cerrarse	Omisión común
1. Crear producto	Products	Crear en Stripe Dashboard y mostrar precio	Hay precio en /pricing, pero no Stripe Product
2. Crear precio	Prices	Definir monto, moneda, periodo y compra/suscripción/uso	Falta interval; falta meter para uso
3. Crear Checkout Session	Checkout Session	Definir line_items, mode, success_url, cancel_url	success_url redirige sin verificar pago
4. Configurar webhook	Webhook endpoint	Recibir checkout.session.completed, invoice.paid, customer.subscription.deleted, etc.	No hay webhook; no se activa acceso
5. Cumplir el pedido	Lógica propia	Otorgar acceso en base y enviar confirmación	Depende de una acción manual sin traza
6. Gestionar reembolso	Refunds	Actualizar, quitar acceso y avisar	El acceso de pago permanece
7. Sincronizar suscripción	Subscriptions	Actualizar tras renovación, cancelación o vencimiento	Los permisos permanecen al vencer

Tabla de decisión del modelo de pago

El modelo de cobro cambia los datos:

Modelo	Efecto en datos	Gestión del acceso	Uso adecuado
Pago único	Añadir paid_at o purchase_id a usuario o compra	Otorgar una vez, permanente o temporal	Producto digital, curso, plantilla, herramienta
Suscripción	subscriptions con user_id, stripe_subscription_id, status, current_period_end	Otorgar y retirar por periodo; requiere sincronización	Herramientas, SaaS, contenido de miembros
Cobro por uso	usage con user_id, meter, amount, timestamp	Limitar uso y saldo; requiere tabla de cupo	API, almacenamiento, cómputo

Stripe Products y Prices permiten crear un Price y transferirle un lookup key. Consultar por clave evita codificar un Price ID en varios sitios, pero cambiar el precio sigue el flujo oficial de creación y activación.

Cumplimiento, reembolso y estado de suscripción necesitan webhook y base. Una página success o trabajo manual en Dashboard no basta. Para profundizar, consulta la comparación de pagos para solo founders.

Verificar un pago de prueba

Antes del lanzamiento completa un recorrido en el entorno de prueba Stripe:

1. Usar el entorno de prueba de Stripe Dashboard
2. Usar métodos actuales documentados para éxito, fallo y autenticación adicional
3. Completar Checkout con los datos de prueba
4. Revisar Payments y Events y confirmar el evento esperado
5. Revisar subscriptions o el derecho y confirmar sincronización
6. Verificar acceso al iniciar sesión y repetir con una cuenta sin derecho

Después revisa por separado claves de producción, webhook endpoint, firmas de eventos y notificaciones.

Capa de usuario: separar identidad, permisos y estado de suscripción

Un sistema de usuario es más que un botón. La versión mínima distingue identidad, permisos, suscripción y frontera de datos. Si el login funciona pero todos leen datos de pago, el problema es autorización.

Supabase Auth puede manejar contraseña, magic link, OTP, login social y SSO. JWT y RLS de la base colaboran en la autorización. La autenticación responde “quién eres”; una RLS policy decide qué filas puedes leer o escribir.

Lista del sistema de usuario mínimo

Capacidad	Capacidad Supabase	Interfaz que debe cerrarse	Omisión común
Autenticación	Contraseña, magic link, OTP, login social, SSO	Entrar, recibir JWT y acceder a datos propios	Login sin autorización
Permisos	RLS (seguridad a nivel de fila)	Cada usuario ve sus datos; el de pago ve contenido de pago	RLS desactivado o policy demasiado amplia
Sincronización	Stripe webhook → subscriptions	Estado cambia tras pago, renovación, cancelación, vencimiento	Estado solo en Stripe
Frontera de datos	RLS policy	Cada usuario accede a sus filas; administración separada	Aislamiento no probado; datos ajenos visibles

Un proyecto Supabase usa Postgres como base; Auth, Storage, Realtime y Edge Functions trabajan alrededor. Un backend confiable actualiza la suscripción. El navegador no decide si existe acceso de pago.

Antes de lanzar prueba RLS con dos cuentas, una con derecho y otra sin él. Confirma también que service role y otras claves privilegiadas no estén en el navegador.

Capa de datos: 5–8 eventos de negocio, no solo un script

Instalar GA4 no crea una capa de datos. La versión mínima solo necesita 5–8 eventos que cambien decisiones, pero deben cubrir visita, clic, acción central, registro, pago, error y feedback.

Tabla de eventos de negocio

Evento	Nombre GA4	Disparador	Uso de análisis
Vista de página	page_view	Carga	Entrada y adquisición SEO
Clic de pago	begin_checkout o evento propio	Clic en comprar o suscribir	Funnel y página de precios
Registro completo	sign_up	Termina registro	Conversión y calidad de adquisición
Inicio de prueba	Evento propio trial_start	Comienza prueba o uso gratis	Conversión y experiencia
Pago completo	purchase	Backend confirma éxito	Ingresos y flujo de pago
Error	Evento propio error_occurred	Fallo frontend, API o acción central	Estabilidad y prioridad
Feedback enviado	Evento propio feedback_submit	Envío de comentario o problema	Tasa y clasificación

GA4 puede marcar acciones importantes como key event. Realtime y DebugView validan la captura; en producción también hay que revisar parámetros, atribución y deduplicación.

Rutina de revisión de datos

Revisa al menos cada semana:

1. GA4: revisar eventos: validar en DebugView y seguir visita, registro, prueba y pago.
2. GSC: revisar consultas y páginas: observar clics, impresiones, CTR, posición media, consultas y páginas, no solo tráfico total.
3. Analítica de producto: decidir el detalle: añadir PostHog o similar cuando GA4 no muestre qué hizo un usuario específico, cuántas veces o dónde abandonó.

GSC, logs y alertas son útiles antes de cobrar. Muestran consultas, fricción de precios, fallos de la acción central y errores frecuentes. Si la captura empieza con el primer cliente, las causas anteriores ya se perdieron.

Capa de automatización: qué conviene el primer día y qué aumenta el riesgo

Algunas automatizaciones eliminan repetición segura; otras amplifican el daño al fallar. Las herramientas de código con IA aceleran el desarrollo, pero no validan pagos, permisos, seguridad ni datos de negocio.

Coding agents como Codex ayudan a entender repositorios, implementar, revisar, depurar, probar y migrar. Son colaboradores de desarrollo. Cumplimiento del pago, fronteras de acceso, secretos de producción, alertas y feedback siguen bajo una persona responsable.

Tabla de fronteras de automatización

Automatización	Vale la pena el primer día	Riesgo añadido	Umbral de uso
Despliegue	Build y despliegue después de Git push	Se supera el cupo; nadie recibe el fallo	Builds y timeout de Pages
Notificación	Pago → derecho → confirmación	Webhook sin reintento; mensaje y derecho divergen	Solicitudes Workers, CPU, reintentos
Backup	Exportar datos críticos; activar backup en plan de pago	Free no incluye backup automático; export fallido invisible	Tamaño de base, almacenamiento, restauración
Revisión	Exportar GA4/GSC y crear informe periódico	Frecuencia excesiva; se ignoran cupos y retraso	GA4/GSC API quota
Orquestación compleja	Hacer observable pago → acceso → email → CRM	Un fallo rompe la cadena; sin idempotencia ni rollback	Fallos por etapa, reintentos, dead letters
Dependencias múltiples	Conectar Webhook, API, Cron, email y CRM	Latencias distintas; sin logs unificados	Solicitudes dinámicas, colas, API externas

Umbrales para Webhook, API y Cron

Webhooks, API ligeras y Cron pueden funcionar en Cloudflare Workers, pero los límites actuales van al presupuesto:

• Workers Free: 100.000 requests/day y 10 ms CPU/invocation.
• Workers Paid: desde 5 dólares por cuenta al mes; Standard incluye 10M requests/month y 30M CPU ms/month, con cobro posterior por uso.

Los assets estáticos y las solicitudes dinámicas tienen reglas distintas. Monitorea solicitudes, CPU, reintentos, logs, KV, Queues, R2 y productos relacionados en conjunto, no un único número “gratis”.

Alertas de despliegue, confirmación de pago, enrutamiento de feedback y resúmenes periódicos son buenas automatizaciones iniciales. Reembolsos automáticos, borrado de producción, cambios de permisos, mensajes masivos y precios deben conservar aprobación humana hasta validar auditoría, idempotencia y rollback.

Umbrales de costo: un cupo gratuito no es una promesa de arquitectura

Un cupo gratuito es presupuesto inicial, no promesa. Los límites de Cloudflare y Supabase dependen de solicitudes dinámicas, CPU, almacenamiento, egress, builds, logs y patrón de uso. No garantizan “gratis para siempre” ni una cantidad fija de usuarios.

Tabla de costos y límites

Servicio	Cupo gratuito	Inicio de pago o upgrade	Riesgo de cambio	Límite a monitorear
Cloudflare Pages	500 builds/month, 20.000 files, 25 MiB asset, timeout de 20 minutos	Ampliar límites Pages con el plan Cloudflare correspondiente	Cupos y planes pueden cambiar	Builds, archivos, timeout
Cloudflare Workers	100.000 requests/day, 10 ms CPU/invocation; assets estáticos gratis	Paid desde $5/account/month, incluye 10M requests y 30M CPU ms	Precio, CPU, solicitudes y productos cambian	Solicitudes, CPU, reintentos, alertas
Supabase	50.000 MAU, 500 MB database, 1 GB storage, 5 GB egress, 2 Free projects; posible pausa tras una semana inactivo	Pro $25/month con $10 de compute credits	Proyecto, cómputo, tráfico y seguridad cambian	MAU, base, almacenamiento, egress, actividad

Estas cifras se verificaron el 26 de julio de 2026 en Cloudflare Pages limits, Workers pricing y Supabase pricing. Revisa de nuevo las páginas oficiales al lanzar.

Un proyecto Supabase Free inactivo puede pausarse tras una semana y Free no incluye backups automáticos. “El proyecto abre” no es una prueba de salud. Verifica actividad, exportación, restauración y disparadores de upgrade.

Consulta también la lista de límites Cloudflare Free y la comparación de planes Cloudflare.

Resumen

El sistema mínimo viable de un solo founder no es una lista corta de herramientas. Cada acción importante necesita entrada, resultado y camino de error: la persona llega, recibe el producto, paga, obtiene acceso, produce datos, envía feedback y recibe ayuda ante incidentes.

La primera versión no tiene que ser perfecta, pero sí comprobable. Coloca launch-checklist.md junto al repositorio y recorre pago, permisos, eventos, feedback e incidentes como un usuario real. Frontend, backend, despliegue, base, pagos y analítica podrán crecer sin reconstruir todo por una entrega olvidada.