3 Proyectos en Sanity, 3 Decisiones de Pricing Distintas: Lo Que Nadie Explica Sobre Sus Tiers
Hay una pregunta que me llega cada semana desde que publiqué el artículo sobre cómo gestiono 12 idiomas en Sanity sin duplicar páginas: «¿Cuándo necesito pasarme al tier de pago?»
La respuesta corta: más tarde de lo que crees si construyes solo, antes de lo que esperas si trabajas con un equipo o tienes clientes.
La respuesta larga es este artículo.
Te cuento tres escenarios reales, el razonamiento detrás de cada decisión de pricing, y el framework que uso ahora para evaluar herramientas con tiers. Sin rodeos.
Por qué Sanity tiene el tier gratuito más honesto del ecosistema CMS
Mira, la mayoría de los tiers gratuitos son anzuelos. Te ofrecen algo inútil para que actualices rápido. Sanity no funciona así.
El tier gratuito incluye proyectos reales: múltiples datasets, acceso completo a la API de contenido (GROQ incluido), Sanity Studio personalizable y un número de usuarios admin que cubre perfectamente a un builder solo o a un equipo muy pequeño.
Lo que me hizo elegir Sanity en 2026 frente a otras alternativas headless es exactamente esto: puedes construir y lanzar un producto real sin pagar nada. No es un entorno de pruebas. Es producción.
Este tipo de queries complejas con references y joins están disponibles desde el primer día, en cualquier tier. Eso no es trivial si vienes de otros CMS.
Proyecto 1: Mi SaaS personal — Llevo meses en el tier gratuito
Tengo un proyecto de contenido donde soy el único editor. Blog, documentación de producto, páginas de marketing.
Decisión: tier gratuito. Sin planteármelo dos veces.
¿Por qué? Porque el tier gratuito de Sanity escala bien para proyectos de una sola persona. Los límites de API son generosos para tráfico real (no de juguete). Y el Studio personalizado con mis propios schemas está funcionando en producción desde el lanzamiento.
Lo que sí hago es monitorizar el uso desde el dashboard. Si veo que me acerco a los límites de peticiones, es la señal para evaluar el upgrade.
Takeaway del proyecto 1: Si construyes solo y lanzas un producto, quédate en el tier gratuito hasta que los límites te empujen a salir. Ese momento llegará de forma orgánica.
Proyecto 2: Trabajo para cliente — El momento en que el tier gratuito se quedó corto
Aquí la cosa cambia.
Un cliente necesitaba que su equipo de marketing (tres personas) accediera al Studio. Más un revisor externo. Más yo como desarrollador gestionando el proyecto.
El tier gratuito de Sanity es generoso con usuarios admin, pero cuando empiezas a sumar roles diferenciados (editor que solo puede publicar posts, revisor que solo puede leer, admin que gestiona schemas), necesitas el tier Growth.
El Growth tier añade lo que realmente importa en entornos con clientes:
→ Roles y permisos granulares — puedes definir exactamente qué puede hacer cada usuario en el Studio
→ Más datasets — útil si quieres entornos staging/production separados por proyecto
→ Soporte prioritario — cuando el cliente llama a las 9 de la mañana con un error, necesitas respuesta rápida
La decisión fue sencilla: los permisos granulares solos ya justifican el upgrade en proyectos con clientes. No es un lujo, es requisito operativo.
Takeaway del proyecto 2: En trabajo para clientes, el tier Growth no es un gasto, es una inversión en no tener conversaciones incómodas sobre quién borró qué contenido.
Proyecto 3: Plataforma de contenido en equipo — El caso Enterprise
Este es diferente. Una plataforma donde el contenido es el producto, con un equipo editorial de más de diez personas, publicación en múltiples marcas y mercados (incluida la casuística de GDPR que en España y Europa no podemos ignorar).
Aquí el tier Enterprise tiene sentido por razones específicas:
→ SLA garantizado — necesitas compromisos de disponibilidad por contrato
→ Residencia de datos en Europa — relevante para cumplir con el RGPD cuando el contenido incluye datos de usuarios
→ Soporte dedicado — no tickets, sino una persona asignada
→ Custom domains para el Studio — tu Studio en tu dominio, no en sanity.io
La regulación europea no es negociable. El RGPD obliga a saber exactamente dónde residen los datos que procesas. Enterprise de Sanity resuelve eso con opciones de data residency que los tiers inferiores no ofrecen con el mismo nivel de control contractual.
Takeaway del proyecto 3: Enterprise es para cuando el CMS es infraestructura crítica y necesitas garantías legales y operativas. No antes.
El framework que uso para decidir cuándo subir de tier
Después de estos tres proyectos, tengo tres preguntas claras:
1. ¿Cuántas personas editan contenido y con qué roles distintos?
- Solo tú → tier gratuito
- Hasta 3-4 personas con el mismo nivel de acceso → tier gratuito se aguanta
- Roles diferenciados (editor, revisor, admin) → Growth
- Equipo grande con compliance europeo → Enterprise
2. ¿El CMS es infraestructura crítica para el negocio del cliente?
- Si una caída de 2 horas es un problema menor → Growth
- Si una caída de 2 horas cuesta dinero real al cliente → Enterprise
3. ¿Hay implicaciones RGPD con el contenido?
- No hay datos personales en el CMS → cualquier tier
- Hay datos personales de usuarios europeos → evalúa Enterprise con data residency europea
La conclusión que nadie dice
Sanity es una de las pocas herramientas del ecosistema headless donde el tier gratuito es suficientemente honesto para lanzar cosas reales. En 2026, con los costes de infraestructura que manejamos como builders independientes, eso importa.
Pero la clave no es quedarte en el tier más barato posible. Es entender exactamente qué necesitas y en qué momento.
Yo llevo proyectos en los tres tiers simultáneamente. Cada uno donde corresponde.
Acción concreta para esta semana:
Si tienes un proyecto en Sanity, abre el dashboard y revisa el uso real de API de los últimos 30 días. Si estás por debajo del 60% del límite gratuito, no tienes nada que hacer. Si estás por encima del 80%, empieza a evaluar Growth antes de necesitarlo con urgencia.
Las decisiones de infraestructura reactivas siempre cuestan más que las proactivas.
