No existe un stack universal para un SaaS. La decisión correcta depende del producto, los datos, el modelo de acceso, los pagos y la capacidad operativa del equipo. Un conjunto administrado puede acelerar la entrega, pero sólo si sus límites coinciden con el problema que se quiere resolver.
El principio: complejidad proporcional y verificable
Antes de escoger tecnologías, define qué debe ocurrir en el navegador, qué datos requieren control de acceso, qué operaciones necesitan un entorno servidor y cómo se comprobará un pago. Diseñar para una escala hipotética agrega costo; ignorar seguridad, pruebas u operación agrega riesgo.
Nuestro criterio es simple: cada componente debe responder a un requisito actual, tener un responsable y contar con una forma concreta de validación.
4 decisiones
Interfaz, datos, servidor y pagos
Evidencia
Costos y límites medidos
Gates
Seguridad y pruebas antes de publicar
Frontend: cuándo sirve el export estático de Next.js
Con output: "export", Next.js genera durante el build un archivo HTML por ruta y los recursos necesarios para la navegación cliente. No es una SPA estricta: cada ruta tiene un documento estático y las transiciones posteriores pueden comportarse como una aplicación cliente.
// next.config.ts
const nextConfig = {
output: "export", // un HTML estático por ruta
trailingSlash: true,
images: { unoptimized: true },
};Este modo funciona bien para contenido y rutas que pueden resolverse al compilar. Las características que requieren un servidor en cada solicitud no están disponibles en un export estático. Si el producto necesita respuestas privadas, datos dinámicos protegidos o lógica por solicitud, esa responsabilidad debe ir a un backend diseñado y autenticado para ello.
La documentación de Next.js también aclara que los Server Components compatibles se ejecutan durante el build. Por eso hay que revisar las capacidades vigentes del framework y probar el artefacto final, no asumir que una característica del App Router funcionará en runtime.
Datos: escoger Firestore por el modelo de acceso
Firestore puede ser una buena alternativa cuando el producto trabaja naturalmente con documentos, necesita sincronización cliente o quiere reducir la administración de infraestructura. No elimina el diseño de datos ni es automáticamente superior a una base relacional.
- Modelo documental: Conviene cuando las consultas y agregados del producto encajan con documentos y colecciones previamente diseñados.
- Tiempo real disponible: Sus listeners ayudan en flujos que necesitan cambios visibles sin operar un servidor de WebSocket propio.
- Reglas de seguridad: Permiten controlar solicitudes directas de clientes autenticados, pero deben probarse contra accesos permitidos y denegados.
- Servicio administrado: Reduce tareas de infraestructura; la observabilidad, los índices, los costos y la respuesta a incidentes siguen siendo responsabilidad del proyecto.
Las bibliotecas de servidor de Firestore omiten las reglas de seguridad y se autentican mediante credenciales e IAM. Por eso las reglas no reemplazan toda la autorización del backend: la lógica servidor debe validar identidad, permisos y datos de entrada.
Una base relacional suele ser preferible cuando predominan relaciones complejas, transacciones entre múltiples entidades, reportes SQL o restricciones de integridad que el equipo necesita expresar directamente. La elección se valida con consultas y volúmenes representativos.
Backend: incorporarlo donde existe una frontera de confianza
Una operación que usa secretos, procesa pagos, modifica permisos o accede a datos privados no debe resolverse sólo en el navegador. Cloud Functions es una opción posible dentro del ecosistema Firebase; un servicio dedicado u otra plataforma administrada también pueden ser correctos según latencia, portabilidad, regulación y experiencia del equipo.
El backend debe autenticar al usuario, autorizar la acción, validar el payload, limitar abusos y registrar errores sin exponer datos sensibles. En pagos, el cliente sólo inicia el flujo: el estado definitivo debe reconciliarse desde una notificación verificada y mediante operaciones idempotentes.
Pagos: evaluar el proveedor y separar los entornos
Mercado Pago es una alternativa disponible en Chile, no una elección universal. Antes de decidir, compara medios de pago requeridos, comisiones vigentes, liquidación, contracargos, soporte, conciliación, experiencia de integración y condiciones comerciales del producto.
- Usar credenciales y usuarios de prueba durante desarrollo y validación.
- Simular los estados documentados con tarjetas de prueba, sin realizar cobros reales.
- Verificar la firma secreta del webhook y responder de forma idempotente.
- Activar credenciales de producción sólo después de completar la integración y el checklist de seguridad.
Nunca uses tarjetas de prueba con credenciales de producción. Si el plan exige una comprobación final en producción, debe realizarse después de aprobar el entorno de prueba, con un medio de pago real autorizado, un monto controlado, trazabilidad y un procedimiento de reversa. Esa prueba no sustituye el sandbox ni justifica experimentar con clientes reales.
Costos: presupuestar con consumo observable
El costo depende del tráfico, las lecturas y escrituras, el almacenamiento, las funciones, la transferencia y las comisiones del proveedor de pago. Debe medirse con la calculadora y la facturación del proyecto, no extrapolarse desde otro producto.
En Firebase, los presupuestos y alertas no detienen automáticamente el uso ni los cargos, y sus avisos pueden tener demora. Algunos servicios ofrecen límites propios, pero tampoco deben asumirse como una protección instantánea. La defensa práctica combina alertas, cuotas compatibles, límites de aplicación, monitoreo y un runbook de respuesta.
Pruebas y operación: no dejarlas para después
- Dominio: Pruebas unitarias para reglas de negocio, cálculos, estados y validaciones que pueden fallar sin navegador.
- Acceso: Pruebas de reglas e IAM con casos permitidos y denegados, incluyendo pertenencia a recursos y privilegios.
- Integración: Pruebas de webhooks, reintentos, firmas, duplicados, errores parciales y conciliación.
- Experiencia: Pruebas end-to-end de registro, recuperación, compra y cancelación en los entornos correspondientes.
También se necesitan logs útiles, alertas accionables, copias o exportaciones cuando correspondan, responsables y un plan de rollback. Un proveedor administrado reduce trabajo operativo, pero no transfiere la responsabilidad del producto.
Checklist antes de producción
- Alcance, modelo de amenazas y responsables documentados
- Reglas de Firestore e IAM probados con accesos permitidos y denegados
- Secretos fuera del cliente, con rotación y mínimo privilegio
- Webhook con firma verificada, idempotencia, reintentos y conciliación
- Credenciales, usuarios y tarjetas de prueba limitados al entorno de prueba
- Presupuesto, alertas, cuotas aplicables y runbook de costos anómalos
- Logs sin datos sensibles, alertas, respaldo y rollback verificados
- Pruebas unitarias, de integración, seguridad y end-to-end aprobadas
- HTTPS, dominios, errores y artefacto final comprobados
Fuentes primarias consultadas
Revisadas el 7 de septiembre de 2026. Las condiciones comerciales y capacidades de los proveedores pueden cambiar; confirma su documentación vigente antes de implementar.
¿Quieres que construyamos tu SaaS con este stack?
Alcance, hitos, supuestos y costos por escrito antes de implementar. La estimación depende del producto y se valida durante el descubrimiento.
Recibe el próximo artículo en tu correo
Sin spam. Un artículo al mes sobre desarrollo web real, SaaS y tecnología en Chile.
Estamos preparando un formulario de suscripción seguro. Vuelve pronto para activar tus avisos.