Ejemplo Práctico: Cuánto Cuesta Lanzar Paneles para Clientes en un SaaS de 200 Clientes

Nota editorial: esto es un modelo ilustrativo, no un caso de cliente

ShiftStack no es un cliente. ShiftStack no existe. Lo hemos inventado para que las cifras de este artículo puedan ser concretas en lugar de vagas.

Dashrendr se lanzó públicamente en Product Hunt hace unas semanas. Todavía no tenemos un cliente con un año de histórico en producción y una página de resultados aprobada, y preferimos decirlo claramente antes que disfrazar un logo ficticio de cliente real. Lo que sí tenemos es la arquitectura, los precios publicados de todas las plataformas de esta categoría y muchas conversaciones con desarrolladores que están sopesando la misma decisión.

Así que esto es un ejemplo práctico. Cada cifra que aparece abajo es un supuesto, etiquetado como tal. Nada de esto es una afirmación sobre los resultados de ninguna empresa real, incluida la nuestra. El valor está en la estructura del cálculo, no en el resultado. Sustituye las cifras por las tuyas y el modelo sigue funcionando.

El escenario

ShiftStack es un SaaS B2B hipotético que vende planificación de turnos a empresas de logística y hostelería del mercado medio. Para este ejemplo, supongamos:

• 200 clientes de pago, con una media de 7.000 $ de ARR cada uno, es decir, unos 1,4 M$ de ARR
• Seis ingenieros, ninguno dedicado a datos
• PostgreSQL 15 en RDS como base de datos operativa principal, con unos 40 millones de filas en la tabla de eventos de turnos
• Sin data warehouse, sin analytics engineer, sin dbt
• Los clientes solo disponen hoy de un botón de exportación a CSV

El detonante es comercial, como suele ser. Tres operaciones del último trimestre se atascaron en compras porque el comprador quería informes que sus responsables de operaciones pudieran abrir por su cuenta. Soporte atiende un goteo constante de peticiones del tipo «¿me puedes sacar los números de marzo?». Alguien propone construir los paneles internamente. Otra persona propone comprarlos. Nadie tiene una cifra.

Paso uno: escribe los requisitos antes que el coste

La mayoría de los debates entre construir y comprar van mal porque cada bando está presupuestando un producto distinto. Fija primero los requisitos. Para ShiftStack, supongamos esta lista:

• Cada cliente ve únicamente sus propios datos, con aislamiento aplicado en el servidor y sin posibilidad de falsificar el identificador de tenant desde el navegador
• De seis a ocho gráficos estándar: cobertura de turnos, horas extra, tasa de ausencias y evolución del coste laboral
• Filtros de rango de fechas y de ubicación
• Paneles con el estilo visual del producto ShiftStack, no un iframe de terceros evidente
• Exportación a CSV y PDF, porque compras lo pidió
• Carga por debajo de dos segundos en el panel mediano
• Los administradores del cliente ven todas sus ubicaciones; los responsables, solo una

Fíjate en lo que no está en la lista: constructor de consultas ad hoc, creación de gráficos por parte del usuario final, capa semántica o subcuentas con marca blanca. Esos son precisamente los requisitos que encarecen de verdad la opción de construir, y ShiftStack todavía no los necesita. Ser honesto con el alcance es la mayor palanca de todo este cálculo.

Paso dos: la arquitectura es la misma en ambos casos

Un detalle que se pierde en los debates de construir contra comprar: las partes difíciles de las analíticas multi-tenant orientadas al cliente no desaparecen cuando compras. Solo cambian de sitio.

Aislamiento entre tenants

ShiftStack necesita seguridad a nivel de fila aplicada en la capa de datos, no en el código de la aplicación. En PostgreSQL eso significa ENABLE ROW LEVEL SECURITY en las tablas implicadas y una política ligada a una variable de sesión establecida a partir de un token verificado. Si el aislamiento vive en una cláusula WHERE dentro de tus controladores de API, una sola cláusula olvidada es una fuga de datos entre clientes. Esto aplica tanto si construyes los gráficos como si los embebes.

Carga de consultas

Cuarenta millones de filas son cómodas para Postgres hasta que 200 clientes abren sus paneles el lunes por la mañana. La respuesta realista para ShiftStack es una tabla de agregados preprocesada que se refresca cada 15 minutos, reservando la tabla en vivo para los desgloses. Supongamos que eso es aproximadamente una semana-ingeniero de trabajo por sí sola, y que es inevitable en ambos escenarios.

Réplica de lectura

Las consultas analíticas no deberían competir por conexiones con la aplicación de planificación. Supongamos una réplica de lectura en RDS por unos 280 $ al mes, es decir, 3.360 $ al año. De nuevo, en ambos escenarios.

Deja estos tres elementos aparte como costes comunes. La diferencia entre construir y comprar es todo lo que va por encima: la capa de gráficos, la fontanería de embebido y autenticación, la interfaz de filtros y exportación, y el mantenimiento continuo de todo ello.

Paso tres: calcular el coste de construir

Supongamos un coste de ingeniería totalmente cargado de 180.000 $ al año, unos 3.460 $ por semana-ingeniero, con dos ingenieros en el proyecto.

• Componentes de gráficos, maquetación responsive y temas: 6 semanas-ingeniero
• Autenticación, tokens firmados y alcance por tenant en los endpoints analíticos: 4 semanas-ingeniero
• Estado de filtros, persistencia en URL y estados vacíos o de error: 3 semanas-ingeniero
• Exportación a CSV y PDF, incluido el renderizado en servidor para el PDF: 3 semanas-ingeniero
• Caché, ajuste de rendimiento y pruebas de carga: 2 semanas-ingeniero
• QA, accesibilidad y correcciones entre navegadores: 2 semanas-ingeniero

Total: 20 semanas-ingeniero, o unos 69.200 $ en el primer año.

Y luego el mantenimiento. Los paneles no son una funcionalidad que se lanza y se olvida. Actualizaciones de la librería de gráficos, nuevas métricas pedidas por ventas, regresiones de navegador y trabajo de rendimiento a medida que crecen los datos. Supongamos un 15% del tiempo de un ingeniero de forma continua, unos 27.000 $ al año.

Hay además un coste que nadie mete en la hoja de cálculo: esas 20 semanas-ingeniero no se dedicaron al producto de planificación. Si crees que tu hoja de ruta tiene valor comercial, ese coste de oportunidad es la partida más grande de esta página, y es justo la que más probabilidades tiene de despacharse con un gesto en la reunión.

Paso cuatro: calcular el coste de comprar

Las plataformas de analíticas embebidas en 2026 se agrupan en tres bandas de precio: herramientas de desarrollo basadas en uso por unos pocos miles al año, plataformas de mercado medio entre 10.000 y 30.000 $, y suites empresariales que arrancan cerca de las seis cifras y escalan con los usuarios finales. Para ShiftStack, supongamos una plataforma de mercado medio a 12.000 $ al año. Comprueba los precios reales antes de reutilizar esa cifra, incluido cómo escalan con usuarios finales en lugar de con cuentas de cliente, que es donde estos contratos suelen dar sorpresas en el segundo año.

El trabajo de integración no desaparece:

• Conectar la fuente de datos y modelar los seis u ocho gráficos: 1 semana-ingeniero
• Embebido, entrega de token firmado y aplicación de estilos: 1 semana-ingeniero

Total: 2 semanas-ingeniero, unos 6.920 $, más 12.000 $ de licencia. El primer año se sitúa cerca de los 18.900 $.

Paso cinco: la comparación a tres años

Los costes comunes (tabla de agregados, réplica de lectura) quedan excluidos porque aplican por igual a ambos caminos.

Construir: 69.200 $ el primer año, después 27.000 $ anuales de mantenimiento. Total a tres años: 123.200 $.
Comprar: 18.900 $ el primer año, después 12.000 $ anuales de licencia. Total a tres años: 42.900 $.
Diferencia: unos 80.300 $ en tres años, y alrededor de 18 semanas-ingeniero devueltas a la hoja de ruta de producto.

El tiempo hasta el primer panel visible para el cliente también cuenta. En este modelo, comprar se lanza en dos o tres semanas y construir en diez o doce. Para un equipo con tres operaciones atascadas, esa diferencia no es un error de redondeo.

Dónde falla este modelo

Un ejemplo práctico solo es honesto si muestra sus propios puntos de ruptura. Comprar deja de ganar cuando:

• Las analíticas son el producto. Si tus clientes te pagan principalmente por el análisis, la capa de gráficos es propiedad intelectual central y externalizarla es un error estratégico, no un ahorro.
• Tus visualizaciones son realmente atípicas. Los gráficos estándar son un commodity. Una vista interactiva específica de tu dominio que ninguna plataforma soporte peleará contra la abstracción para siempre.
• El precio por usuario final choca con tu modelo. Una plataforma de 12.000 $ para 200 cuentas puede convertirse en 60.000 $ si esas cuentas tienen 40 usuarios cada una. Modela el tercer año, no el primero.
• La residencia de datos o el despliegue aislado son contractuales. Esto reduce rápidamente la lista de proveedores y puede eliminarla por completo.
• Ya tienes el equipo. Una empresa con equipo de plataforma y sistema de diseño tiene un coste de construcción sensiblemente menor que las 20 semanas modeladas aquí.

Cambia los supuestos y la conclusión cambia con ellos. Ese es justamente el motivo de escribirlos.

Cómo aplicar esto a tu propia empresa

Copia la estructura, no las cifras:

1. Escribe primero la lista de requisitos y sé implacable con lo que de verdad hace falta en la versión uno.
2. Separa los costes comunes que aplican a ambos caminos, para comparar solo la diferencia real.
3. Estima la construcción en semanas-ingeniero y multiplica por tu coste real totalmente cargado.
4. Añade mantenimiento continuo del 10% al 20% de un ingeniero. No lo pongas a cero.
5. Pide presupuestos reales y modélalos contra tu número de usuarios del tercer año.
6. Pon una cifra al tiempo de lanzamiento, sobre todo si hay ingresos esperando.

Incluso una versión aproximada de esto es mejor que el proceso habitual, que consiste en hacer caso a quien defienda su postura con más seguridad en la reunión.

Conclusión

ShiftStack es ficción. La decisión no lo es, y es una que los desarrolladores nos plantean casi cada semana. En este hipotético concreto, comprar gana por unos 80.000 $ en tres años y se lanza dos meses antes, sobre todo porque los requisitos son convencionales y el equipo es pequeño. Cambia cualquiera de esas dos cosas y la aritmética se mueve.

Cuando tengamos clientes con cifras reales de producción y permiso para publicarlas, sustituiremos este artículo por el caso auténtico. Hasta entonces, la versión honesta es aquella en la que puedes ver cada supuesto y discutirlo.

Si quieres poner a prueba el lado de «comprar» de este modelo, nuestros precios son públicos. Trae tus propias cifras.