Ingeniería de producto
Desarrollo de SaaS
Un SaaS no es una app con login. Son datos de otras personas compartiendo tu base de datos, trabajo que tiene que ocurrir después de responder la petición, y una factura que escala con un uso que necesitas poder medir. Esa capa es la que construimos.
La tenencia se decide una sola vez
La primera decisión real de un SaaS es cómo se separan los tenants, y es casi irreversible. Un esquema compartido con una columna de tenant es barato y rápido hasta el día en que un cliente necesita sus datos en otro lado. Una base por tenant es limpia hasta que tienes cuatrocientas que migrar. Elegimos con criterio, escribimos por qué, y lo hacemos cumplir en la capa de datos en vez de confiar en cada consulta futura.
La segunda es qué pasa fuera de la petición. Ingerir eventos, correr experimentos, generar reportes y procesar subidas no pertenecen a un handler HTTP. Pertenecen a una cola y a un worker, con reintentos, dead letters y una forma de ver qué falló — que es la diferencia entre un producto que sobrevive su primera semana ocupada y uno que pierde datos en silencio.
- Aislamiento demostrable
- El alcance por tenant se aplica donde viven los datos, no a mano en cada consulta, así un filtro olvidado es una prueba en rojo y no una fuga.
- El trabajo ocurre fuera de la petición
- Colas y workers absorben ingesta, exportaciones y jobs largos, así un tercero lento nunca se convierte en un producto lento.
- Almacenamiento elegido por trabajo
- Datos transaccionales en PostgreSQL, estado caliente en Redis, volumen de eventos en almacenamiento analítico. Una sola base para las tres es como se vuelven lentos los SaaS.
Lo que cubre el trabajo
- Modelo de tenants, estrategia de aislamiento y aplicación en la capa de datos
- Planes, límites y contabilidad de uso
- Recolección de eventos y pipeline de ingesta
- Workers en segundo plano con reintentos y manejo de dead letters
- PostgreSQL, Redis y almacenamiento analítico cuando el volumen lo pide
- Object storage para subidas y artefactos generados
Tecnologías
- Node.js
- TypeScript
- PostgreSQL
- Redis
- ClickHouse
- Workers
- Object Storage
- Railway
Dónde ayuda más
Un producto de experimentación o analítica
Ingesta de eventos de alto volumen, dashboards por tenant y consultas que deben seguir siendo rápidas mientras la tabla de eventos crece.
Una herramienta que ya vendes como servicio
Una herramienta interna a la que ahora clientes quieren acceso, y que necesita tenencia, planes y límites antes de poder venderse.
Una app de Shopify que superó una sola base
Una app con suficientes instalaciones como para que el procesamiento de jobs, webhooks y reportes tenga que salir de la ruta de la petición.
Cómo lo entregamos
Tenencia y modelo de datos
Cómo se separan los tenants, qué limita un plan, y qué uso tiene que ser contable — decidido antes de la primera tabla, porque es lo caro de cambiar.
El producto central
La aplicación en sí, con el alcance por tenant aplicado en la capa de datos y las rutas de lectura pensadas para cómo se usa el producto de verdad.
Pipeline y workers
Eventos que entran, jobs que salen. Colas, reintentos, dead letters y la observabilidad para ver a qué tenant pertenecía un fallo.
Operarlo
Despliegue, migraciones que corren con seguridad contra tenants en vivo, y el runbook de los fallos que van a ocurrir.
Desarrollo de SaaS
¿Esquema compartido o una base por tenant?
¿Necesitamos una base analítica aparte?
¿Podremos auto-alojarlo o cambiar de proveedor después?
¿Cómo manejan migraciones con tenants en vivo?
¿Listo para empezar con desarrollo de saas?
Cuéntanos sobre tu tienda y tus objetivos. Volveremos con un plan claro y honesto y una cotización transparente.