Cuando empezamos a construir Commet, modelamos nuestro sistema de cobros y pagos como las plataformas de comercio electrónico tradicionales. Productos, precios, variantes, niveles. El enfoque de catálogo que usan procesadores de pago como Stripe.
Pasamos tres meses construyendo y lanzamos.
Una semana después, sabíamos que algo estaba mal.
Cada llamada con un cliente se sentía más difícil de lo que debería. Explicar cómo armar una página de precios simple requería recorrer productos, precios de lista, variantes de precio y los elementos que componen una suscripción. Los fundadores asentían, pero les veías la confusión en la cara.
La conclusión fue simple: las empresas SaaS no venden productos. Venden planes.
Tomamos una decisión: reconstruir la arquitectura central. Dos semanas de trabajo intenso después, lanzamos un modelo completamente nuevo.
El enfoque basado en productos
Nuestra arquitectura original se veía así:
Producto: "API Platform"
├── Precio de lista: "Plan Starter" → $50/mes, 10K llamadas
├── Precio de lista: "Plan Professional" → $200/mes, 100K llamadas
├── Precio de lista: "Plan Enterprise" → $500/mes, 1M llamadas
└── Variante de precio: "Acme Corp" → 20% descuentoAsí funcionan la mayoría de las plataformas de cobros y pagos. Creás productos, les adjuntás precios, creás variantes para acuerdos personalizados y cableás todo con suscripciones que referencian múltiples productos.
Para procesadores de pago y marketplaces, tiene sentido. Pero para SaaS, generaba complejidad innecesaria.
Cada vez que un fundador quería crear una página de precios simple con tres niveles, tenía que pensar en productos, precios de lista, variantes de precio y cómo se conectaban entre sí. El modelo mental no coincidía con cómo realmente pensaban su negocio.
Cómo venden las empresas SaaS en la realidad
Cuando mirás cualquier página de precios de un SaaS, no ves un catálogo de productos. Ves planes.
Notion no vende "Almacenamiento de Documentos" y "Colaboración en Equipo" como productos separados. Vende planes Free, Plus, Business y Enterprise. Cada uno agrupa distintas capacidades.
Linear no vende "Gestión de Tareas" con complementos. Vende planes Starter, Pro y Business que incluyen todo.
Vercel no te hace elegir entre productos de "Alojamiento" y "Funciones de Borde". Vende planes Hobby, Pro y Enterprise con distintos límites.
Los planes son la unidad de venta. Las funcionalidades son lo que incluye cada uno. El uso determina los excedentes.
El modelo basado en planes
Reconstruimos Commet alrededor de esta conclusión:
Plan "Pro" - $99/mes
├── Llamadas a la API: 10.000 incluidas, $0,01/extra
├── Miembros del equipo: 5 incluidos, $25/extra
├── Marca personalizada: habilitado
└── Soporte prioritario: habilitado
Cliente → Suscripción → Plan → Cobro automáticoEn vez de productos que referencian precios que referencian variantes, tenés:
- Funcionalidades: Las capacidades que vendés (booleanas, de consumo o de puestos)
- Planes: Paquetes que configuran funcionalidades con límites y precios
- Suscripciones: El contrato entre el cliente y el plan
Eso es todo. Sin gestión de catálogo. Sin jerarquías de variantes de precio. Sin preguntarte qué producto va con qué elemento de la suscripción.
Por qué esto importa
1. Coincide con cómo piensan los fundadores
Cuando un fundador dice "quiero un plan Pro a $99/mes con 10K llamadas de API incluidas", puede crear exactamente eso. El modelo mental que tiene en la cabeza coincide con el modelo de datos en Commet.
Sin capa de traducción. Sin "primero creá un producto, después un precio de lista, después configurá los elementos de la suscripción."
2. Las funcionalidades impulsan el modelo
En el modelo basado en productos, el registro de uso y los tipos de puestos eran complementos incómodos. Creabas entidades separadas para registrar consumo y esperabas que todo se conectara bien.
En el modelo basado en planes, las funcionalidades son los bloques de construcción:
- Funcionalidades booleanas: Marca personalizada, SSO, acceso a la API
- Funcionalidades de consumo: llamadas a la API, correos enviados, almacenamiento utilizado
- Funcionalidades de puestos: miembros del equipo, usuarios administradores, editores
Cada plan configura estas funcionalidades con límites específicos y precios de excedente. El motor de cobros sabe exactamente qué cobrar porque el modelo es explícito.
3. Los Grupos de Planes habilitan el autoservicio
Con productos, los cambios de plan eran complicados. ¿Qué productos pueden subir a cuáles? ¿Cómo manejás las proraciones entre múltiples elementos de la suscripción?
Con Grupos de Planes, definís qué planes pueden cambiarse entre sí. El Portal de Cliente se encarga del resto:
Grupo de Planes "Precios Principales"
├── Starter ($29/mes)
├── Pro ($99/mes)
└── Business ($299/mes)
Un cliente en Starter puede subir a Pro o Business por su cuenta.
Las proraciones se calculan automáticamente.La reconstrucción
Una vez que vimos el problema, nos movimos rápido. En dos semanas, rearquitecturamos todo el modelo de cobros y pagos:
- Migramos de productos y variantes de precio a planes y funcionalidades
- Reconstruimos el motor de cobros para manejar el nuevo modelo
- Nos aseguramos de que cada modelo de precios siga funcionando (fijo, basado en uso, escalonado, puestos)
- Actualizamos el SDK y la documentación
Lo que aprendimos
Construir software de cobros y pagos nos enseñó que la mejor arquitectura no es la más flexible. Es la que coincide con el modelo mental de tus usuarios.
Los procesadores de pago necesitan catálogos de productos porque sus clientes venden bienes físicos, descargas digitales y servicios. La flexibilidad es esencial.
Las plataformas de cobros y pagos para SaaS necesitan una arquitectura basada en planes porque sus clientes venden suscripciones con funcionalidades y uso. La simplicidad es esencial.
Lo más difícil no fue el trabajo técnico. Fue admitir, una semana después del lanzamiento, que habíamos construido la abstracción equivocada. Pero es la única forma de construir algo que la gente realmente quiera usar.
Si estás construyendo un producto SaaS o de IA y querés un sistema de cobros y pagos que coincida con cómo realmente pensás tus precios, revisá nuestra documentación o explorá la vista general de la plataforma.
Creemos que vas a encontrar que el modelo basado en planes simplemente tiene sentido.