Cómo Construir un SaaS con IA: Arquitectura, Stack y Lanzamiento
Construir un SaaS rentable en 2026 requiere mucho más que escribir código. Necesitas combinar inteligencia artificial como diferencial competitivo real, una arquitectura que escale sin reescribir, y un enfoque de lanzamiento lean que te permita validar rápido y pivotar sin quemar capital. Esta guía cubre las 7 decisiones técnicas y de negocio que marcan la diferencia entre un side-project que muere en el limbo y un producto con tracción medible. Cada sección incluye decisiones concretas, anti-patterns que hemos visto en proyectos reales, y métricas para saber si vas por buen camino. No es teoría: es el playbook que usamos en FranMotion para construir productos digitales con IA integrada desde el día uno. Este post es la pieza arquitectónica de nuestro cluster sobre IA en desarrollo. Para el contexto general del ecosistema, herramientas y patrones de adopción, empezá por Desarrollo Web Potenciado por IA: Guía Práctica 2026.
Validación antes de escribir código
El error más caro en SaaS es construir algo que nadie necesita. Antes de abrir el editor, necesitas evidencia de que el problema existe, que la gente paga por resolverlo, y que tu enfoque con IA aporta algo que las alternativas no pueden replicar fácilmente. Empieza por definir tu Problem-Solution Fit con claridad quirúrgica. No basta con "la gente necesita X" — necesitas hablar con al menos 10 potenciales usuarios y escuchar el mismo dolor repetido en sus propias palabras. Las entrevistas de descubrimiento son tu herramienta más poderosa: pregunta qué soluciones usan hoy, cuánto pagan, qué les frustra, y qué harían si el problema desapareciera mañana. Si no puedes articular el problema en una frase, no estás listo para construir.
El análisis competitivo en SaaS con IA tiene una dimensión extra: no solo mapeas features y pricing de competidores, sino que evalúas qué parte de su stack es replicable con modelos foundation (GPT-4, Claude, Gemini) vs. qué requiere datos propietarios o fine-tuning especializado. Tu moat no puede ser "usamos IA" — eso lo hace todo el mundo. Tu moat es la combinación de datos únicos + UX específica + integración profunda en el workflow del usuario.
Calcula tu TAM (Total Addressable Market) de forma bottom-up: número de empresas en tu segmento × willingness to pay × frecuencia de uso. Si tu TAM bottom-up es menor a $10M, reconsidera el segmento o expande el alcance del producto. Para SaaS B2B con IA, el sweet spot en 2026 está en nichos verticales donde puedes cobrar $50-500/mes por asiento porque el ROI es demostrable. Horizontal tools con IA genérica ("asistente de todo") tienen CAC prohibitivo y churn brutal.
Antes de escribir una línea de código, crea una landing page con tu propuesta de valor y mide signups a una waitlist. Si no puedes conseguir 100 signups orgánicos en 2 semanas, tu mensaje no resuena o el canal de distribución no funciona. Ambos problemas son más baratos de resolver ahora que después de 6 meses de desarrollo. Si tenés una idea SaaS validada y querés acelerar la construcción del MVP con IA integrada desde el día uno, en FranMotion desarrollamos productos SaaS con stack moderno (React + Node + Prisma) y enfoque lean — del Problem-Solution Fit al primer cliente pago.
- Realiza al menos 10 entrevistas de descubrimiento con usuarios potenciales antes de cualquier decisión técnica — el patrón emerge en la repetición.
- Mapea 5+ competidores evaluando: pricing, features IA, datos propietarios, integraciones y churn público (reviews en G2/Capterra).
- Calcula TAM bottom-up: empresas target × precio × frecuencia. Si es <$10M, reconsidera el segmento.
- Valida con landing page + waitlist: 100 signups orgánicos en 2 semanas es el umbral mínimo.
- Define tu moat de IA: datos propietarios, fine-tuning especializado, o integración de workflow que GPT genérico no puede replicar.
Arquitectura de referencia para SaaS con IA
La arquitectura de un SaaS con IA en 2026 debe balancear tres tensiones: velocidad de iteración (ship fast), consistencia operacional (no rompas lo que funciona), y escalabilidad de inferencia (los modelos de IA consumen recursos de forma no-lineal). Nuestra recomendación basada en decenas de proyectos es clara: empieza con un monolito modular y extrae servicios solo cuando el dolor sea medible.
La arquitectura de referencia que usamos tiene 5 capas. La capa de presentación es una SPA en React 19 (o Next.js 15 con App Router si necesitas SSR para SEO). La capa de API es un servidor Express/Fastify con endpoints REST bien estructurados y validación con Zod. La capa de lógica de negocio contiene tus servicios, orquestadores y la integración con modelos de IA. La capa de datos combina PostgreSQL como fuente de verdad relacional, Redis para cache y colas, y opcionalmente pgvector o Pinecone para embeddings vectoriales. La capa de infraestructura es Docker + Railway/Render para MVP, migrando a AWS/GCP cuando superes $5K MRR.
Para la integración de IA, el patrón más robusto es el Orchestrator Pattern: un servicio central que recibe la request del usuario, determina qué modelo(s) invocar, gestiona el contexto (embeddings, historial), y formatea la respuesta. Este orquestador abstrae el proveedor de IA (OpenAI, Anthropic, local) detrás de una interfaz común, permitiendo cambiar de modelo sin tocar la lógica de negocio. Nunca llames a la API de OpenAI directamente desde un route handler — siempre a través de un servicio dedicado con retry, fallback, rate limiting y logging de costos.
El patrón de comunicación interna debe ser event-driven desde el inicio. Usa un sistema de colas (BullMQ con Redis) para tareas de IA que superen 2 segundos de latencia: generación de reportes, procesamiento batch, re-indexación de embeddings. El usuario recibe un job ID y consulta el estado vía polling o WebSocket. Esto evita timeouts HTTP y permite escalar workers de IA independientemente del servidor web.
Para multi-tenancy, PostgreSQL con Row-Level Security (RLS) es la opción más pragmática hasta 1000 tenants. Cada tabla tiene una columna tenantId y políticas RLS que garantizan aislamiento a nivel de base de datos. Para >1000 tenants o requisitos de compliance estrictos (SOC2, HIPAA), considera schema-per-tenant o database-per-tenant, pero no prematures esta decisión.
- Monolito modular primero: extrae microservicios solo cuando un componente necesite escalar independientemente (normalmente el worker de IA es el primero).
- Orchestrator Pattern para IA: un servicio central gestiona modelo, contexto, retry y costos. Nunca llames OpenAI desde route handlers.
- Event-driven para tareas >2s: BullMQ + Redis para jobs de IA asíncronos. El usuario recibe job ID, no espera bloqueo HTTP.
- Multi-tenancy con RLS de PostgreSQL hasta 1000 tenants. Schema-per-tenant solo si compliance lo exige.
- Infraestructura: Docker + Railway para MVP. AWS/GCP cuando MRR > $5K justifique el overhead operacional.
"Ship a monolith, scale into services. La arquitectura prematura es la raíz de todo mal en startups."
Stack técnico recomendado 2026
Elegir el stack de un SaaS no es una decisión técnica — es una decisión de negocio. El stack determina tu velocidad de iteración, el pool de talento al que puedes acceder, el costo operacional, y la curva de escalabilidad. En 2026, el stack que maximiza todos estos factores para SaaS con IA es React 19 + Node.js + Prisma + PostgreSQL + Redis.
En el frontend, React 19 con TypeScript es la elección por defecto. No por hype, sino por pragmatismo: el ecosistema es el más grande (componentes, librerías, herramientas), el pool de talento es el más profundo, y las nuevas features de React 19 (Server Components, automated memoization, document metadata API) reducen boilerplate significativamente. Usa Vite como bundler (10x más rápido que Webpack), Tailwind CSS 4 para estilos (utility-first elimina CSS muerto), y TanStack Query para server state management (cache, revalidación, optimistic updates). Para el dashboard de tu SaaS, Recharts o Nivo cubren gráficos, y Radix UI + shadcn/ui te dan componentes accesibles sin vendor lock-in — la base ideal para un design system escalable.
En el backend, Node.js 22 LTS con Express/Fastify y TypeScript. Express sigue siendo la opción más pragmática: middleware ecosystem maduro, debugging conocido, y performance suficiente para el 99% de SaaS. Fastify solo si necesitas raw throughput en endpoints hot-path. Prisma 6 como ORM: type-safety end-to-end con TypeScript, migrations robustas, y un query engine que ha madurado enormemente. La alternativa es Drizzle si prefieres SQL-first, pero Prisma tiene mejor DX para equipos mixtos.
PostgreSQL 16 es tu base de datos primaria. No hay debate en 2026: soporte nativo de JSON, full-text search, pgvector para embeddings, window functions para analytics, y un ecosistema de extensiones sin rival. Redis sirve doble propósito: cache de queries frecuentes (TTL-based) y queue broker para BullMQ. Para embeddings vectoriales a gran escala (>1M vectors), evalúa Pinecone o Weaviate como complemento a pgvector.
Para testing, Jest + Supertest para unit e integration tests, Playwright para E2E. Para CI/CD, GitHub Actions es el estándar: lint, test, build, deploy en un pipeline de 3-5 minutos. Para observabilidad, Sentry para error tracking, y un stack de métricas lightweight (PostHog o Plausible para product analytics, no Google Analytics — tus usuarios valoran la privacidad).
Un punto crítico que muchos ignoran: type-safety end-to-end. Con Prisma generando tipos desde tu schema, TypeScript en frontend y backend, y Zod validando inputs en la API, eliminas una clase entera de bugs en runtime. Este stack no es sexy ni bleeding-edge — es deliberadamente boring tech que funciona. Combinado con herramientas de IA integradas en el flujo de desarrollo, la productividad se multiplica.
- Frontend: React 19 + TypeScript + Vite + Tailwind CSS 4 + TanStack Query + Radix UI. El ecosistema más productivo en 2026.
- Backend: Node.js 22 LTS + Express + TypeScript + Prisma 6. Boring tech que escala y se contrata fácil.
- Database: PostgreSQL 16 (relacional + JSON + pgvector) + Redis (cache + queues). Un combo que cubre el 95% de necesidades.
- Testing: Jest + Supertest + Playwright. CI/CD con GitHub Actions en pipeline de 3-5 min.
- Observabilidad: Sentry (errors) + PostHog (product analytics) + structured logging con pino.
- Type-safety end-to-end: Prisma types → Zod validation → TypeScript. Elimina bugs de runtime por categoría completa.
"El mejor stack es el que tu equipo domina y puedes contratar. Boring tech wins."
Integración de IA como feature core
La diferencia entre un SaaS "con IA" y un SaaS donde la IA es decoración está en una pregunta: ¿el usuario principal job-to-be-done se resuelve mejor gracias a la IA, o la IA es un feature más en una lista? Si puedes quitar la IA y el producto sigue teniendo sentido, la IA es decoración. Si al quitar la IA el producto pierde su razón de ser, tienes un SaaS con IA real.
Hay 5 patrones de integración de IA que vemos funcionar en SaaS en 2026. El primero es RAG (Retrieval-Augmented Generation): el usuario sube documentos o datos, tu sistema los indexa como embeddings vectoriales, y cuando hace preguntas el sistema recupera contexto relevante antes de generar la respuesta. Este patrón funciona para knowledge bases, Q&A sobre documentación, y análisis de datos no-estructurados. El stack técnico es pgvector para almacenamiento, un modelo de embeddings (text-embedding-3-small de OpenAI o E5 de Microsoft), y un LLM para generación (GPT-4o o Claude Sonnet).
El segundo patrón es Structured Output Generation: el LLM genera JSON tipado que tu aplicación consume directamente. Ejemplos: generación de reportes, extracción de datos de documentos, clasificación automatizada. La clave es usar el response_format de OpenAI o tool_use de Anthropic para garantizar que el output sea parseable. Siempre valida con Zod el output del modelo — los LLMs pueden generar JSON malformado bajo edge cases.
El tercer patrón es Agentic Workflows: cadenas de invocaciones donde el LLM decide qué herramientas usar y en qué orden. Para SaaS, esto es poderoso en automatización: el usuario describe un objetivo, y el sistema ejecuta una secuencia de acciones (consultar API, transformar datos, enviar email, actualizar CRM). Usa LangChain o un orquestador custom ligero — LangChain tiene overhead pero también tiene el ecosistema más grande de tools y memory.
El cuarto patrón es Fine-Tuning para dominio específico: cuando tu vertical tiene terminología o lógica que los modelos foundation no manejan bien. Fine-tuning de GPT-4o-mini es sorprendentemente barato ($8/M tokens de training) y mejora dramáticamente la calidad en dominios especializados (legal, médico, financiero). Pero solo fine-tunea cuando RAG no es suficiente — fine-tuning es costoso de mantener y cada actualización del modelo base requiere re-entrenar.
El quinto patrón es Predictive Features: usar modelos de ML clásico (no LLMs) para predicciones que mejoran la UX. Ejemplos: lead scoring, churn prediction, anomaly detection, recommendation engines. Scikit-learn o XGBoost para modelos simples, entrenados con los datos de tu plataforma. La ventaja competitiva aquí es que tus modelos mejoran con más datos de usuarios — un flywheel que los competidores no pueden copiar sin su propia base de usuarios.
Gestión de costos de IA es crítica. Un LLM call puede costar $0.01-0.15 dependiendo del modelo y tokens. Con 10K usuarios haciendo 10 calls/día, son $1K-15K/mes solo en inferencia. Estrategias de gestión: cache de respuestas similares (Redis con embeddings similarity), modelo-routing (usar GPT-4o-mini para queries simples, GPT-4o solo para complejas), batch processing para análisis no-interactivos, y rate limiting por plan de pricing. Siempre loguea el costo por request para entender tu unit economics. Si buscas maximizar la interacción con estos modelos, una buena colección de prompts especializados para developers marca la diferencia entre outputs genéricos y resultados profesionales.
- RAG: embeddings + vector search + LLM generation. El patrón más común y versátil para SaaS con datos de usuario.
- Structured Output: JSON tipado via response_format/tool_use. Siempre valida con Zod — los LLMs no son deterministas.
- Agentic Workflows: cadenas de herramientas orquestadas por LLM. Potente para automatización multi-paso.
- Fine-Tuning: solo cuando RAG falla en tu dominio. GPT-4o-mini fine-tuning es barato ($8/M tokens) y efectivo.
- Predictive ML: modelos clásicos (XGBoost, sklearn) para scoring, churn, anomalías. Flywheel de datos como moat.
- Cost management: cache con similarity search, model routing (mini vs. full), batch processing, rate limiting por plan.
Auth y Billing desde el día 1
Auth y billing no son features — son cimientos. Si los dejas para después, terminas haciendo refactors dolorosos cuando ya tienes usuarios pagando. Implementa ambos antes de cualquier feature de negocio.
Para autenticación en SaaS, el patrón probado es JWT con refresh tokens + RBAC (Role-Based Access Control). El flujo: el usuario se autentica (email/password o OAuth), recibe un access token (15min TTL) y un refresh token (7d TTL, rotante). Cada request incluye el access token en Authorization header. Cuando expira, el frontend usa el refresh token para obtener uno nuevo sin interrumpir al usuario. RBAC con 3 roles base: Owner, Admin, Member. Extiéndelo a permisos granulares solo si tu modelo de pricing lo requiere.
No construyas auth from scratch. Clerk, Auth0, o Supabase Auth te dan login, OAuth, MFA, y session management out-of-the-box. El costo es $0-25/mes para los primeros 5K-10K MAU — insignificante comparado con el tiempo de desarrollo. Si insistes en custom auth (por compliance o control), Passport.js + bcrypt + jose (para JWT) es el stack mínimo, pero presupuesta 2-3 semanas de desarrollo incluyendo edge cases (reset password, email verification, rate limiting en login, brute force protection).
Para billing, Stripe es el estándar en 2026 para SaaS. No hay alternativa que se acerque en developer experience, documentación, y cobertura de payment methods. El setup mínimo: crea Products y Prices en Stripe Dashboard, usa Stripe Checkout para la suscripción (hosted payment page = PCI compliance gratis), y gestiona el lifecycle vía webhooks. Los eventos clave a manejar: customer.subscription.created (activar features), customer.subscription.updated (cambio de plan), customer.subscription.deleted (desactivar acceso), invoice.payment_failed (comunicar al usuario + retry logic).
Diseña tu pricing antes de construir. Los modelos más efectivos en SaaS con IA en 2026 son: per-seat pricing para herramientas colaborativas, usage-based pricing para APIs o procesamiento (cobra por IA tokens consumidos — es justo y escalable), y tiered plans con feature gating para productos con audiencia mixta (Starter, Pro, Enterprise). Un error común es ofrecer demasiados planes — 3 es el sweet spot. Incluye siempre un free trial de 14 días con acceso completo (no un plan free crippled — eso atrae usuarios que nunca convierten).
Implementa soft-delete para cancelaciones: cuando un usuario cancela, desactiva el acceso al final del billing period pero conserva los datos 90 días. El 10-15% de los usuarios que cancelan reactivan si la experiencia de reactivación es frictionless. Winback emails automatizados en day 3, 7, y 30 post-cancelación con un incentivo (20% descuento por 3 meses) tienen un recovery rate de 5-8% en SaaS B2B.
- JWT con refresh tokens rotativos: access token (15min) + refresh token (7d, rotante). RBAC con Owner/Admin/Member como base.
- Usa Clerk, Auth0, o Supabase Auth en lugar de custom auth. El costo es insignificante vs. tiempo de desarrollo.
- Stripe Checkout para suscripciones: hosted page = PCI compliance gratis. Gestiona lifecycle vía webhooks.
- Webhooks clave: subscription.created (activar), subscription.updated (cambio plan), subscription.deleted (desactivar), payment_failed (retry).
- 3 planes máximo: Starter, Pro, Enterprise. Free trial de 14 días con acceso completo, no freemium crippled.
- Soft-delete en cancelaciones + winback emails (day 3, 7, 30) con descuento. Recovery rate típico: 5-8%.
Estrategia de lanzamiento lean
El lanzamiento de un SaaS no es un evento — es un proceso de 12 semanas dividido en 4 fases. La mayoría de fundadores over-engineer el lanzamiento (spend 6 meses en features) o lo under-engineer (publican en Product Hunt sin preparación). El enfoque lean equilibra momentum con feedback.
Fase 1 — Waitlist y Contenido (semanas 1-3). Crea una landing page con Framer o Next.js que comunique tu propuesta de valor en 8 segundos. Include un formulario de waitlist y un CTA claro. Produce 3-4 artículos de blog que ataquen keywords long-tail de tu nicho — esto genera tráfico orgánico que alimenta la waitlist. Para maximizar el impacto de cada pieza, aplica estrategias de marketing digital potenciadas por IA. Comparte contenido en LinkedIn, Twitter/X, y comunidades relevantes (Discord, Slack, Reddit) sin ser spammy: aporta valor primero, menciona el producto después. Objetivo: 200-500 emails en waitlist.
Fase 2 — Beta Cerrada (semanas 4-7). Invita a los primeros 20-50 usuarios de la waitlist. Prioriza usuarios que respondieron a tu email de bienvenida o que tienen un perfil cercano a tu ICP (Ideal Customer Profile). Dales acceso completo y un canal directo de feedback (Slack, WhatsApp, o Intercom). Tu objetivo NO es que les guste el producto — es observar dónde se atascan, qué feature piden primero, y cuánto usan la IA. Mide activation rate (% de usuarios que completan la acción core en los primeros 7 días). Si activation < 30%, el onboarding necesita trabajo antes de escalar.
Fase 3 — Beta Abierta (semanas 8-10). Abre el acceso a toda la waitlist y comienza a cobrar (aunque sea con descuento de early-adopter: 30-50% off primer año). Cobrar filtra usuarios serios de curiosos. Implementa un flujo de onboarding guiado: tour interactivo, template pre-configurado, y un "aha moment" en los primeros 5 minutos. Mide conversión de trial a paid (target: >5% para B2B SaaS).
Fase 4 — Lanzamiento Público (semanas 11-12). Product Hunt, Hacker News, comunidades verticales, y outreach a newsletters de tu nicho. Para Product Hunt, lanza en martes o miércoles (mayor tráfico), prepara assets (thumbnail, gallery, video demo de 60s), y moviliza tu red para upvotes en las primeras 2 horas — el algorithmo favorece momentum temprano. Paralelamente, contacta a 10-15 creadores de contenido o newsletters de tu nicho ofreciéndoles acceso lifetime a cambio de una review honesta. Un post en una newsletter con 5K suscriptores de tu ICP vale más que 1000 upvotes genéricos.
Post-lanzamiento, tu métrica norte es MRR (Monthly Recurring Revenue). Todo lo demás (signups, users, features) es un indicador proxy. Si MRR no crece semana a semana, algo en tu funnel está roto: no estás adquiriendo (marketing), no estás activando (onboarding), no estás reteniendo (product-market fit), o no estás monetizando (pricing). Diagnostica cuál de los 4 antes de añadir features.
- Semanas 1-3: Landing page + waitlist + 3-4 posts SEO. Objetivo: 200-500 emails.
- Semanas 4-7: Beta cerrada con 20-50 usuarios. Canal directo de feedback. Mide activation rate (target: >30%).
- Semanas 8-10: Beta abierta + cobrar (30-50% descuento early-adopter). Onboarding guiado. Mide trial→paid (target: >5%).
- Semanas 11-12: Product Hunt (martes/miércoles), newsletters de nicho, outreach a creators. Momentum en primeras 2h.
- Post-lanzamiento: MRR como métrica norte. Si no crece, diagnostica: adquisición → activación → retención → monetización.
Métricas que importan post-lanzamiento
Después del lanzamiento, la tentación es medir todo. Resiste. En los primeros 6 meses, solo 6 métricas importan, y cada una te dice algo específico sobre la salud de tu SaaS. Medirlas bien es un superpoder; ignorarlas es volar a ciegas.
MRR (Monthly Recurring Revenue) es tu métrica norte. Es el ingreso recurrente mensual normalizado. Calcula: suma de todas las suscripciones activas × precio mensual. Descompón MRR en: New MRR (nuevos clientes), Expansion MRR (upgrades), Contraction MRR (downgrades), y Churned MRR (cancelaciones). Un SaaS sano tiene New + Expansion > Contraction + Churned de forma consistente. En los primeros 6 meses, un growth rate de 15-20% MoM (month-over-month) indica tracción real.
Churn Rate es el porcentaje de clientes que cancelan en un periodo. Para SaaS B2B, el benchmark es <5% mensual (gross churn). Por encima de 5%, estás llenando un balde con agujero — por mucho que adquieras, no crecerás sosteniblemente. Calcula: clientes perdidos en el mes / clientes al inicio del mes × 100. Si tu churn es alto, haz exit interviews (email automático al cancelar con 3 preguntas) para entender por qué se van. Las razones más comunes: no usan el producto (activation problem), lo usan pero no ven valor (product-market fit problem), ven valor pero es caro (pricing problem).
CAC (Customer Acquisition Cost) es cuánto gastas en adquirir un cliente. Calcula: gasto total en marketing y ventas / nuevos clientes en el periodo. Para SaaS con IA, el CAC incluye los costos de IA durante el trial (inferencia, embeddings). Un ratio LTV:CAC saludable es >3:1 — si pagas $100 para adquirir un cliente, ese cliente debe generar >$300 de revenue en su lifetime. En early-stage, tu CAC será alto y eso es normal — baja a medida que tu brand organic traffic crece y reduce la dependencia de paid acquisition.
LTV (Customer Lifetime Value) es el ingreso total esperado de un cliente. Fórmula simplificada: ARPU (Average Revenue Per User por mes) / churn rate mensual. Si tu ARPU es $50/mes y tu churn mensual es 5%, LTV = $50 / 0.05 = $1000. LTV te dice cuánto puedes gastar en adquirir y retener un cliente de forma rentable. Si LTV < CAC, estás perdiendo dinero por cada cliente — la solución es reducir churn, aumentar ARPU (upsell), o reducir CAC.
Activation Rate es el porcentaje de nuevos signups que completan la "acción core" dentro de un periodo definido (típicamente 7 días). Para un SaaS con IA, la acción core podría ser: crear su primer proyecto, ejecutar su primera query con IA, o invitar a un team member. Define tu activation event antes de lanzar y mídelo obsesivamente. Un activation rate <25% indica que tu onboarding tiene fricción o que tu "aha moment" no está claro. Optimiza el onboarding antes de gastar en adquisición — es más barato activar 10% más de los usuarios que ya tienes que adquirir 10% más.
NPS (Net Promoter Score) mide satisfacción y predicción de word-of-mouth. Pregunta: "Del 0 al 10, ¿qué tan probable es que recomiendes [producto] a un colega?" Promotores (9-10), Pasivos (7-8), Detractores (0-6). NPS = %Promotores - %Detractores. Un NPS >40 en SaaS B2B es excelente. Mídelo trimestralmente vía email o in-app survey. Lo más valioso no es el número sino la pregunta abierta: "¿Qué mejorarías?" — las respuestas de detractores te dicen exactamente qué arreglar.
Configura un dashboard con estas 6 métricas visible para todo el equipo. Herramientas: Stripe Dashboard para MRR y churn financiero, PostHog o Mixpanel para activation y product usage, y una hoja de cálculo para NPS hasta que tengas volumen para automatizar. Revisa semanalmente. Las métricas que no revisas regularmente no influyen en decisiones — y métricas que no influyen en decisiones son ruido, no información.
- MRR: métrica norte. Descompón en New, Expansion, Contraction, Churned. Target: 15-20% MoM growth en primeros 6 meses.
- Churn Rate: <5% mensual para B2B SaaS. Si es mayor, haz exit interviews antes de cualquier otra acción.
- CAC: incluye costos de IA durante trial. Ratio LTV:CAC saludable >3:1.
- LTV: ARPU / churn mensual. Si LTV < CAC, ajusta pricing, churn o adquisición.
- Activation Rate: % de signups que completan acción core en 7 días. Target >25%. Optimiza antes de escalar adquisición.
- NPS: >40 es excelente en B2B SaaS. La pregunta abierta de detractores es tu roadmap de producto.
"Si no puedes medir activación en los primeros 7 días, no tienes producto — tienes un hobby con Stripe."
Checklist accionable
- Valida el problema con 10+ entrevistas antes de construir — el código más caro es el que resuelve el problema equivocado.
- Define tu stack con criterio de velocidad de iteración, no de escala teórica — MongoDB no es mejor que PostgreSQL porque "escala".
- Integra IA como feature core no como decoración — si puedes quitar la IA y el producto sigue teniendo sentido, es decoración.
- Implementa auth y billing antes de features de negocio — son los cimientos que no puedes refactorear fácilmente.
- Lanza con feature-set mínimo y métricas de activación definidas — shipping beats perfection.
- Mide MRR, churn y NPS desde la semana 1 post-lanzamiento — lo que no mides no puedes mejorar.
- Configura cost tracking de IA desde día 1 — los costos de inferencia escalan de forma no-lineal con users.
- Diseña pricing antes de construir features — el pricing framework determina qué features tienen sentido.