El stack mínimo para lanzar un SaaS en Chile en 2026

El principio fundamental: retrasar la complejidad

Todo stack complejo fue alguna vez un stack simple que creció. El error clásico es diseñar para el millón de usuarios antes de tener el primer usuario de pago. Kubernetes, microservicios, colas de mensajes, múltiples bases de datos — todo eso es deuda técnica disfrazada de ambición.

Nuestro criterio: si la decisión arquitectural no mejora la experiencia del usuario en los próximos 90 días, no la tomas ahora.

La capa de frontend: Next.js con export estático

La decisión más contraintuitiva que tomamos: deshabilitar el SSR de Next.js y exportar el sitio como archivos estáticos.

// next.config.ts
const nextConfig = {
  output: "export",     // SPA pura, sin servidor Node
  trailingSlash: true,
  images: { unoptimized: true },
};

¿Por qué? Porque con Firebase Hosting el deploy toma 30 segundos, el CDN es global automáticamente, el SSL se configura solo y el costo marginal de tráfico es prácticamente cero. Todo el SSR que “necesitábamos” lo reemplazamos con Cloud Functions para la lógica real.

El App Router de Next.js 15 nos da Server Components, metadata dinámica, y tipado completo con TypeScript — sin necesidad de un servidor Node corriendo 24/7.

La capa de datos: Firebase Firestore

No PostgreSQL. No MongoDB. Firestore. La razón no es dogma — es pragmatismo:

• Sin migraciones de esquema: Iteras el modelo de datos sin fricciones. Agregar un campo es agregar un campo.
• Tiempo real nativo: El chat de Perfil Primero funciona con onSnapshot, sin websockets propios ni polling.
• Reglas de seguridad declarativas: firestore.rules reemplaza toda una capa de autorización en el backend.
• Sin servidor de base de datos: No hay que parchear, escalar, ni monitorear nada. Google lo hace.

¿Cuándo usar PostgreSQL en cambio? Cuando tienes queries relacionales complejas que Firestore no puede satisfacer eficientemente, o cuando ya tienes un equipo con experiencia en SQL y la curva de Firestore costaría más que el beneficio.

La capa de backend: Cloud Functions v2

Toda la lógica de negocio que no puede vivir en el cliente va a Cloud Functions. El criterio es claro: si la operación involucra dinero, permisos sensibles o datos privados — va al servidor.

// Ejemplo real de nuestra arquitectura
exports.createWorkerCheckout = onCall(async (request) => {
  // Solo Cloud Functions escriben en 'payments'
  // El cliente nunca toca esta colección directamente
  const session = await mercadopago.preferences.create({...});
  await db.collection('payments').add({
    userId: request.auth.uid,
    status: 'pending',
    ...
  });
  return { checkoutUrl: session.init_point };
});

Esto elimina una clase entera de vulnerabilidades: el cliente no puede falsificar un pago porque nunca escribe en la colección de pagos. Solo el webhook de Mercado Pago — corriendo en Cloud Functions con firma verificada — puede hacerlo.

La capa de pagos: Mercado Pago (y solo Mercado Pago en Chile)

Si tu mercado es Chile, no pierdas tiempo evaluando Stripe como opción primaria. Mercado Pago tiene:

• Webpay integrado (tarjetas chilenas sin comisión extra)
• Transferencia bancaria directa
• Cuotas sin interés con bancos chilenos
• Soporte en español con equipo local

Lección dolorosa que aprendimos: el sandbox de Mercado Pago no simula todos los estados de pago. Prueba en producción con montos reales desde el día 1 usando tarjetas de prueba de su documentación. El webhook funciona diferente en sandbox y producción — no te enteres de eso el día del lanzamiento.

El costo real de esta arquitectura

Después de 6 meses en producción con Perfil Primero, aquí están nuestros costos reales:

Sí: menos de $25 USD al mes. Y escala automáticamente. Sin DevOps. Sin factura sorpresa. Firebase tiene un límite de gasto configurable que previene costos inesperados.

Lo que no está en este stack (y por qué)

• Redis / caché: Firestore tiene caché offline nativa en el cliente. Para el servidor, los resultados de Functions se cachean via HTTP cuando corresponde.
• Kubernetes / Docker: Zero-config deployment con Cloud Functions. Si escala, Google escala. No hay contenedores que mantener.
• GraphQL: REST simple via Cloud Functions. GraphQL agrega complejidad que no necesitas hasta tener múltiples consumidores del mismo API.
• Testing unitario extensivo al inicio: Esto va a generar controversia: priorizamos tests de reglas Firestore (críticos para seguridad) y tests E2E de los flujos de pago. El resto vino después de tener usuarios reales.

El checklist real antes de lanzar

• firestore.rules auditadas — colecciones sensibles bloqueadas al cliente
• Webhook de pagos con verificación de firma (no confíes solo en el payload)
• Variables de entorno en .env — nunca hardcoded en el código
• Límite de gasto en Firebase configurado
• SSL automático verificado (Firebase lo hace, pero compruébalo)
• Error handling en todas las Cloud Functions con logging
• Test de pago real con monto mínimo antes de lanzamiento público