Notas · 10 de julio de 2026
Una plataforma que tenemos en producción atiende 12 clientes finales con cerca de 3.000 usuarios activos al mes y cuesta menos de USD 25 al mes en infraestructura. El developer senior que la construyó cobra varias veces eso por hora. Esa proporción no es accidente: es el centro de cómo elegimos la tecnología en Pudu Studio.
La regla que casi nadie publica
El costo total de un sistema SaaS, sumando 5 años de vida útil, se reparte aproximadamente así:
- 95% en personas: developers, soporte, fixes, features nuevas, refactors.
- 5% en infraestructura: servidores, base de datos, CDN, monitoring.
La mayoría de los stacks modernos (frameworks de cliente por defecto, microservicios sin necesidad, “funciones para todo”) optimizan el 5% asumiendo que la infra va a ser barata, y descuidan el 95% con código que se rompe seguido y necesita tres developers para mantenerse.
Nosotros hacemos exactamente lo contrario.
Qué priorizamos al elegir la tecnología
Despliegue simple. Un solo artefacto con todo adentro. Cero cadenas de dependencias frágiles, cero instalaciones que se rompen en cada máquina. La mantención se acerca a cero.
Una base de datos que hace el trabajo. Una base de datos madura resuelve el 90% de lo que otros reparten en servicios aparte. Menos piezas que pagar, menos cosas que se caen y que monitorear.
Interfaz liviana. HTML renderizado en el servidor y unos pocos KB de JavaScript. Sin compilaciones de minutos ni capas de frontend que rinden mal en móviles de gama baja, que es lo que usa la mayor parte de LatAm.
Infraestructura por uso. Pagas por lo que efectivamente se usa. Si la app está idle a las 3 AM, pagas casi nada. Si pega un peak, escala sola sin que toques una línea.
Números reales de un caso en producción
Sin nombres, pero los números son los que vemos en la consola de nuestro proveedor de nube cada mes.
- Aplicación: plataforma para varios clientes, 12 clientes finales activos
- Tráfico: ~3.000 usuarios activos / mes, ~50.000 requests / día en horario hábil
- Memoria por instancia: 80–150 MB
- Arranque en frío: 90 ms
- Costo de cómputo mensual: USD 4–8
- Costo de base de datos compartida: USD 7–15
- Total infra/mes: menos de USD 25
Esa misma aplicación sobre un stack más pesado costaría fácil:
- 2x en cómputo (los frameworks de cliente agregan peso y memoria por request).
- 3x más tiempo para mantener (cada actualización de dependencias es una aventura, con breaking changes cada 6 meses).
- Más bugs en producción por la complejidad inherente de una app de cliente pesada.
La parte incómoda: developers caros
Esto no es marketing, es matemática:
En Chile y LatAm, un developer senior cobra 25–40% más por hora que un dev junior o mid. Y eso es exactamente la decisión correcta.
Por qué:
- Un senior produce código que corre en menos servidores y falla menos.
- 1 senior escribiendo 1 feature por semana supera a 3 mids descartables peleándose con dependencias y deploys frágiles.
- Cuando el proyecto tiene que vivir 5 años, el ahorro de tiempo total supera con holgura el costo por hora de cualquier mid.
- La rotación entre seniors es menor: menos onboarding, menos drift, menos deuda técnica acumulada.
La industria de “scaling teams” optimiza el lado opuesto: contratar barato y rápido. Funciona perfecto para una startup que se va a vender en 18 meses. No funciona para una PYME en LatAm que necesita que su sistema aguante una década sin que el bill mensual se le coma el margen.
Cuándo este enfoque no es la decisión correcta
Honestamente:
- MVP descartable de 6 meses: un framework de cliente con hosting gestionado te lleva más rápido al primer usuario validando una hipótesis.
- Necesitas SDKs oficiales sólo disponibles en otro lenguaje: pelear con HTTP a mano cuando existe una librería oficial es perder tiempo caro.
- El cliente quiere editar el front sin involucrar a tu equipo: un CMS o un constructor visual son lo correcto.
- Equipo sin experiencia en este enfoque: la curva inicial cuesta. Forzarlo sin alguien que lo domine es la receta del fracaso.
Para quién sí
Si eres una PYME, un operador o un equipo de operaciones en LatAm que necesita un sistema que:
- Atienda múltiples clientes finales sin que cada uno cueste un servidor aparte.
- Aguante 5+ años sin tener que reescribir el frontend cada 18 meses por el último framework de moda.
- Pueda crecer 10x en tráfico sin que la cuenta de tu proveedor de nube se vuelva inmanejable.
- Lo mantenga un solo developer senior, no un equipo de cuatro mids rotativos.
…entonces este enfoque te conviene. Eso es exactamente lo que armamos para clientes en Pudu Studio.
¿Tienes algo que automatizar y quieres que dure varios años sin que el servidor te coma el margen? Cuéntanos por WhatsApp o correo. Primera conversación, 30 minutos, gratis.