El stack de $100 al mes que sostiene 17 productos en produccion

Cada vez que hablo con fundadores de startups tech y les digo cuanto gasto en infraestructura, la reaccion es la misma: incredulidad. Algunos se rien. Otros asumen que estoy exagerando. Unos pocos se enojan, porque acabo de invalidar sus presupuestos de $30,000 mensuales en AWS.

Pero los numeros no mienten. Innova y Cree opera 17 productos SaaS en produccion, con usuarios reales, en un solo servidor, por aproximadamente $100 al mes. Y no estoy hablando de prototipos o demos — son productos completos con backends, frontends, bases de datos, IA propietaria, procesamiento de pagos y todo lo que necesitan para funcionar.

Este articulo es un desglose transparente y completo de como lo logramos. Sin secretos. Sin trucos. Pura arquitectura pragmatica.

El servidor: un VPS que hace el trabajo de 17

Todo corre en un Hostinger KVM 4. Las especificaciones:

• CPU: 4 cores AMD EPYC
• RAM: 16 GB
• Almacenamiento: 193 GB SSD NVMe
• SO: Ubuntu Linux
• Costo: ~$15/mes

Si, quince dolares. No es un typo. Un VPS con 4 cores y 16 GB de RAM es absurdamente barato en 2026, y es mas que suficiente para lo que necesitamos. ¿Por que? Porque la mayoria de los productos SaaS en etapa temprana no necesitan escala — necesitan existir, funcionar, y servir a sus primeros 100-1,000 usuarios de forma confiable.

La obsesion de la industria con "prepararse para escalar" antes de tener un solo cliente es una de las razones por las que las startups queman dinero sin sentido. Nosotros preferimos el enfoque contrario: empezar pequeño, crecer cuando hay razon real para hacerlo.

PostgreSQL 16: una base de datos para gobernarlas a todas

Una sola instancia de PostgreSQL 16 corre en el servidor. Dentro de ella: 17 bases de datos separadas, una por cada producto. LEXIMEX tiene su base. AbogadoIA tiene la suya. ColaboradorIA, el hostal, Licitometro, cada uno aislado en su propio espacio.

¿Por que PostgreSQL y no MongoDB, MySQL, o alguna base de datos "moderna"? Tres razones:

• pgvector: Extension nativa para busqueda vectorial. Nuestros productos de IA legal necesitan RAG con embeddings — pgvector nos permite hacer busqueda de similitud sin necesitar una base de datos vectorial separada como Pinecone o Weaviate. Cero costo adicional.
• JSONB: Cuando necesitamos flexibilidad de esquema (como almacenar configuraciones variables de cada marca en SocialAI), usamos columnas JSONB. Lo mejor de los dos mundos: la confiabilidad de SQL con la flexibilidad de NoSQL.
• Madurez: PostgreSQL tiene 30+ años de desarrollo. No crashea, no pierde datos, no tiene sorpresas. En produccion, boring es bueno.

Redis complementa como cache y almacen de sesiones. Una sola instancia, puerto 6379, compartida entre los productos que lo necesitan. Costo adicional: $0 (viene incluido en el servidor).

PM2: el director de orquesta invisible

PM2 es el process manager de Node.js, y es probablemente la pieza mas critica de nuestra arquitectura. Corre 19+ procesos simultaneos — backends API, frontends servidos, workers de procesamiento, bots de Telegram. Cada uno con su nombre, su puerto, su log independiente.

Lo que hace PM2 invaluable:

• Auto-restart: Si un proceso crashea (porque si, pasa), PM2 lo reinicia automaticamente en milisegundos. Sin downtime perceptible.
• Logs centralizados: Cada proceso tiene su propio archivo de log. Cuando algo falla, se exactamente donde buscar.
• Monitoreo de memoria: PM2 me dice cuanto consume cada proceso. Si alguno se dispara, lo detecto antes de que afecte a los demas.
• Startup persistente: Si el servidor se reinicia (actualizacion de kernel, por ejemplo), PM2 levanta todos los 19 procesos automaticamente. Sin intervencion humana.

¿La alternativa empresarial? Kubernetes, Docker Swarm, ECS de AWS. Cualquiera de esas opciones requiere un equipo DevOps dedicado y cuesta 10x-100x mas. PM2 hace lo mismo para nuestro caso de uso con un archivo de configuracion de 50 lineas.

Caddy: HTTPS automatico sin sufrir

Todos nuestros productos necesitan HTTPS y dominios propios. leximex.com, abogadoia.cl, colaboradoria.com, licitometro.cl, factoia.cl... mas de una docena de dominios apuntando al mismo servidor.

Caddy maneja todo esto. ¿Por que Caddy y no Nginx? Una sola razon que lo justifica todo: certificados SSL automaticos. Caddy obtiene, renueva y gestiona certificados Let's Encrypt para todos los dominios sin configuracion manual. Cero. Le digo "este dominio va a este puerto" y Caddy se encarga del resto.

Con Nginx, tendria que configurar certbot, crear cron jobs para renovacion, debuggear cuando un certificado expira a las 3am. Con Caddy, ese problema simplemente no existe. En 3 meses operando 17 productos, nunca tuve un problema de SSL.

Agregar un nuevo producto es literalmente agregar 3 lineas al Caddyfile, recargar, y listo. El producto nuevo ya tiene HTTPS funcionando.

Node.js + Express + React: el stack sin sorpresas

Todos los backends usan Node.js con Express. Todos los frontends usan React con Vite. Sin excepcion. ¿Es el stack mas moderno? No. ¿Hay frameworks mas "cool"? Claro. ¿Funciona de forma confiable, predecible, y con un ecosistema masivo de librerias? Absolutamente.

La homogeneidad del stack es una decision deliberada. Cuando todos los productos hablan el mismo idioma, las soluciones son transferibles. Un patron que funciona en LEXIMEX funciona en ColaboradorIA. Un middleware de autenticacion que escribi para AbogadoIA lo reutilizo en Licitometro. El conocimiento se acumula en vez de fragmentarse.

Vite para el frontend fue una decision de productividad pura: hot reload instantaneo, builds rapidos, configuracion minima. Cuando lanzas 17 productos en 3 meses, cada segundo de espera en el build se multiplica por miles.

El desglose real: donde van los $100

Total: aproximadamente $100 al mes. Eso incluye todo. Servidor, dominios, IA, email. No hay costos ocultos de balanceadores de carga, CDN enterprise, bases de datos managed, o clusters de Kubernetes.

Para poner esto en perspectiva: una startup promedio en Silicon Valley gasta entre $10,000 y $50,000 al mes solo en infraestructura cloud antes de tener un solo cliente pagando. Nosotros gastamos lo que cuesta un plan de celular.

Las decisiones que no tomamos (y por que)

Tan importante como lo que elegimos es lo que descartamos deliberadamente:

• No usamos AWS/GCP/Azure. Los cloud providers cobran por todo: transferencia de datos, requests, almacenamiento, certificados, load balancers. Para 17 productos, la factura seria astronomica. Un VPS es precio fijo predecible.
• No usamos Docker en produccion (casi). Solo para servicios especificos que lo requieren. Para nuestros productos Node.js, PM2 es mas simple, mas rapido, y no tiene el overhead de contenedores.
• No usamos microservicios. Cada producto es un monolito pequeño y contenido. Un backend Express, un frontend React, una base de datos PostgreSQL. Simple, debuggeable, mantenible.
• No usamos bases de datos managed. RDS de AWS cobra $50-200/mes por una instancia PostgreSQL basica. Nuestra instancia local hace lo mismo gratis.

¿Y la seguridad? ¿Y los backups?

Tener todo en un servidor no significa descuidar la seguridad. El servidor tiene:

• UFW firewall: Solo puertos 22 (SSH), 80 (HTTP) y 443 (HTTPS) abiertos. Todo lo demas esta cerrado.
• fail2ban: Bloqueo automatico de IPs que intentan fuerza bruta contra SSH.
• Variables de entorno: Todas las credenciales en archivos .env con permisos chmod 600. Nunca en el codigo.
• Backups automaticos: Cron job a las 4am que respalda las bases de datos criticas (LEXIMEX, AbogadoIA, Licitometro) diariamente.

¿Es tan robusto como un setup multi-region con replicas en 3 continentes? No. ¿Es suficiente para productos en etapa de crecimiento con cientos de usuarios? Absolutamente. La seguridad perfecta no existe — la seguridad adecuada al momento del negocio, si.

La filosofia detras del stack: pragmatismo radical

Todo se resume en una pregunta que me hago antes de cada decision tecnica: "¿Esto resuelve un problema real que tengo HOY, o un problema imaginario que podria tener algun dia?"

Kubernetes resuelve problemas de orquestacion a escala masiva. Nosotros tenemos 19 procesos. Microservicios resuelven problemas de equipos grandes que necesitan deployar independientemente. Nosotros somos un equipo de una persona con IA. Multi-region resuelve problemas de latencia global. Nuestros usuarios estan en Mexico y Chile.

Cada tecnologia "enterprise" que descartamos nos ahorra dinero, tiempo, y complejidad. Y esos recursos los invertimos en lo que realmente importa: construir productos que resuelvan problemas reales para clientes reales.

"La arquitectura perfecta no es la que puede escalar a un millon de usuarios. Es la que te permite llegar a tus primeros 100 clientes pagando sin quedarte sin dinero en el camino. Escalar es un problema de lujo — y prefiero tener ese problema a no tener clientes."

¿Cuando escalariamos?

No soy dogmatico. Hay un momento correcto para migrar a infraestructura mas robusta, y es cuando los numeros lo justifican. Si un producto individual genera suficientes ingresos para pagarse su propia infraestructura dedicada, lo migramos. Hasta entonces, el VPS compartido funciona perfectamente.

La señal clara seria: cuando el CPU se mantiene consistentemente arriba del 80%, cuando la RAM se llena, o cuando la latencia afecta la experiencia del usuario. Ninguna de esas cosas ha pasado todavia con 17 productos corriendo simultaneamente.

Mientras tanto, esos $100 al mes nos dan la libertad de experimentar, lanzar productos nuevos, iterar sin presion financiera, y demostrar que construir una empresa de tecnologia no requiere levantar capital de riesgo. Solo requiere tomar decisiones inteligentes sobre donde gastar — y donde no.