Una app multi-tenant 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 armamos el stack 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 (Node + React, microservicios sin necesidad, “lambdas 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é decimos cuando elegimos Go + Postgres + HTMX + Cloud Run

Go: un binario único de unos 30 MB con todas las dependencias adentro. Cero node_modules, cero pip install, cero bundle install. Deploy es literalmente gcloud run deploy o scp binary && systemctl restart. La mantención se acerca a cero.

PostgreSQL: 30 años de batallas. Hace el 90% de lo que la gente mete en Redis + Elasticsearch + algún message queue. Row-level security para multi-tenancy real, sin un servicio aparte. Se mantiene solo durante años si no lo provocas.

HTMX + Templ: HTML renderizado en el servidor más unos 14 KB de JavaScript. Sin compilación de TypeScript, sin webpack, sin yarn build tomando 3 minutos cada vez. El frontend se desarrolla más rápido y rinde mejor en móvil de gama baja, que es lo que usa la mayor parte de LatAm.

Cloud Run o Fly.io: pagas por CPU efectivamente usada. Si tu app está idle a las 3 AM, pagas casi nada. Si pega un peak, escala automático 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 GCP cada mes.

• Aplicación: multi-tenant SaaS, 12 clientes finales activos
• Tráfico: ~3.000 usuarios activos / mes, ~50.000 requests / día en horario hábil
• Memory footprint: 80–150 MB por instancia Cloud Run
• Cold start: 90 ms (los binarios Go arrancan rápido)
• Costo Cloud Run mensual: USD 4–8
• Costo Cloud SQL Postgres compartida: USD 7–15
• Total infra/mes: menos de USD 25

Esa misma aplicación escrita en Node + React + microservicios costaría fácil:

• 2x en compute (Node consume más memoria por request, React bundles agregan latencia y peso al cliente).
• 3x más tiempo para mantener (cada npm audit es una aventura, breaking changes en libs cada 6 meses).
• Más bugs en producción por la complejidad inherente de un SPA.

La parte incómoda: developers caros

Esto no es marketing, es matemática:

En Chile y LatAm, un developer senior de Go cobra 25–40% más por hora que un dev junior o mid de Node o PHP. 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 Go escribiendo 1 feature por semana supera a 3 mids descartables peleándose con bundlers, 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 technical debt acumulado.

La industria de “scaling teams” optimiza el lado opuesto: contratar barato y rápido. Funciona perfecto para una startup Series-B 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 Go + HTMX no es la decisión correcta

Honestamente:

• MVP descartable de 6 meses: Next.js + Vercel te lleva más rápido al primer usuario validando una hipótesis.
• Necesitas SDKs oficiales sólo disponibles en Node o Python: pelear con HTTP raw cuando existe una librería oficial es perder tiempo caro.
• El cliente quiere editar el front sin involucrar a tu equipo: WordPress, Webflow o Wix son lo correcto.
• Equipo sin experiencia en Go: la curva inicial cuesta. Forzarlo sin un senior 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 GCP o AWS se vuelva inmanejable.
• Lo mantenga un solo developer senior, no un equipo de cuatro mids rotativos.

…entonces Go + Postgres + HTMX + Cloud Run 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.

← Volver a notas