Desarrollo de software B2B: de la idea al SaaS en producción

La mayoría de los SaaS B2B mueren no porque la idea sea mala, sino porque la arquitectura no soporta lo que el negocio necesita. Multi-tenancy mal implementada, billing que no escala, onboarding que pierde clientes antes de que prueben el producto. Vamos a las decisiones concretas.

Qué hace diferente a un SaaS B2B

Un SaaS B2B no es "una app web con login". Es un producto que:

1. Sirve a múltiples empresas (tenants) desde una sola instancia
2. Cobra recurrente (mensual/anual) con distintos planes
3. Necesita onboarding porque el usuario es un empleado, no un consumidor final
4. Requiere permisos granulares (admin, manager, operador, viewer)
5. Se integra con los sistemas que el cliente ya usa (ERP, contable, email)

Si tu "SaaS" no tiene al menos 3 de estas 5 características, probablemente estés construyendo una app web con suscripción, que es distinto y más simple.

La decisión #1: Multi-tenancy

Cómo aislar los datos de cada cliente. Las opciones reales:

Estrategia	Pros	Contras	Cuándo usarla
Base de datos por tenant	Aislamiento total, fácil de borrar un tenant	Costosa, difícil de mantener	Clientes enterprise con requisitos de compliance
Schema por tenant	Buen aislamiento, moderadamente escalable	Migraciones complicadas	10-100 clientes medianos
Row Level Security	Un solo schema, escala a miles, bajo costo	Requiere disciplina en queries	La mayoría de los SaaS B2B

En PairProgramming usamos Row Level Security (RLS) con PostgreSQL en el 90% de los casos. Cada tabla tiene una columna tenant_id, y las políticas RLS garantizan a nivel de base de datos que un tenant jamás ve datos de otro. Es lo que usamos en Newton Broker y en Mi Seguro.

La decisión #2: Billing desde el día uno

El error más común: "después agregamos los planes pagos". Después nunca llega, o llega mal. Lo que implementamos desde el sprint 1:

• Plan free con límites claros (X usuarios, Y registros, Z features)
• Upgrade path visible: el usuario ve qué obtiene con el plan siguiente
• Stripe o Mercado Pago integrado con webhooks para estado de pago en tiempo real
• Grace period: si falla un cobro, el tenant tiene 7 días antes de restricción
• Métricas por plan: cuántos están en free, cuántos pagan, MRR, churn

Esto no es over-engineering. Es la base mínima para que el producto genere revenue desde el primer cliente.

La decisión #3: Onboarding que no pierde usuarios

En B2B, el usuario que se registra no es necesariamente quien decidió contratar. Es un empleado que recibió un mail diciendo "registrate acá". Si el onboarding es confuso, ese usuario cierra la pestaña y le dice a su jefe que "no funciona".

Nuestro patrón de onboarding:

1. Registro en 30 segundos: email + password + nombre de empresa. Nada más.
2. Wizard de 3 pasos: configurar lo mínimo para ver valor (importar datos, o crear el primer registro)
3. Estado vacío útil: si no hay datos, mostrar ejemplos o templates, no una pantalla blanca
4. Invitar equipo: facilitar que el admin invite a sus compañeros. Cada invitación es un lock-in.

El caso Newton Broker: un SaaS B2B real

Newton Broker es una plataforma de intermediación de seguros. Los números:

• Multi-tenant: cada broker (PAS/corredor) tiene su instancia con datos aislados vía RLS
• Integraciones: APIs de 5 aseguradoras argentinas, cotización en tiempo real, emisión automatizada
• Billing: planes por volumen de pólizas emitidas
• Usuarios: brokers con sub-agentes, cada uno con permisos distintos
• Stack: Next.js + PostgreSQL + Vercel, mismo stack que usamos en todos los SaaS

El producto se construyó en 5 meses y hoy opera con brokers activos emitiendo pólizas diariamente.

Stack que usamos para B2B SaaS

No hay stack perfecto, pero este es el que repetimos porque funciona:

• Frontend: Next.js + TypeScript + Tailwind. Server components para SEO, client components para interactividad.
• Backend: API Routes de Next.js o Node.js con Express según complejidad. TypeScript siempre.
• Base de datos: PostgreSQL con RLS. Supabase para proyectos que necesitan auth + storage rápido, o Postgres raw para control total.
• Auth: NextAuth o auth custom con JWT + refresh tokens. 2FA para planes enterprise.
• Pagos: Stripe (internacional) + Mercado Pago (Argentina). Webhooks para todo.
• Deploy: Vercel (zero-config, edge, auto-scaling) o AWS (cuando hay requisitos enterprise).
• CI/CD: GitHub Actions. Tests en cada PR, deploy automático a staging, promote manual a producción.

Los 3 errores que matan SaaS B2B

1. No medir desde el principio

Si no tenés analytics de producto (qué features se usan, dónde se traban los usuarios, cuál es la tasa de activación), estás adivinando qué construir next. Herramientas: Mixpanel, PostHog, o un tracker custom con eventos en PostgreSQL.

2. Construir features que nadie pidió

El 60% de las features de un SaaS promedio no se usan nunca. Antes de construir, validá con al menos 3 clientes que efectivamente lo necesitan y lo usarían.

3. No tener un plan de migración de datos

Tus clientes ya tienen datos en algún lado (Excel, otro CRM, sistema contable). Si no ofrecés migración asistida, la fricción de cambio es enorme. Siempre incluimos scripts de importación en el scope.

---

Si estás pensando en construir un SaaS B2B, escribinos. Hacemos sesiones de scope gratis donde definimos juntos qué incluir en el MVP y qué dejar para después.

---

Por Esteban Aleart, Founder & Lead Engineer de PairProgramming.