Milsaca

CONTEXTO

Un sector entero funcionaba a la improvisada, entre planillas y WhatsApp, sin un sistema único.

QUÉ SE HIZO

SaaS multi-tenant (web + mobile) con paneles por rol, automatizaciones y datos seguros (RLS). Prueba de que entrego producto complejo de punta a punta.

MULTI-TENANT · WEB + MOBILE · RLS

SOLUCIONES

• Multi-tenant vía RLS

  Aislamiento por corretora_id garantizado en la base de datos, no en la aplicación. RLS en toda tabla.

• Informe COB digital

  Motor de clasificación de la IN 8/2003 (MAPA) en paquete puro, con PDF + QR de verificación pública.

• Cotizaciones en vivo

  CEPEA, ICE NY Coffee C y PTAX (BCB) sincronizados vía edge function programada.

• Web + mobile, un solo backend

  Next.js 16 y Expo Router compartiendo el mismo Supabase por un paquete de clients en capas.

DETALLE TÉCNICO

• 01Monorepo Turborepo + pnpm con tres frentes sobre un solo backend: Next.js 16 (App Router) para la web, que por sí sola ya cubre tres paneles…+

  Monorepo Turborepo + pnpm con tres frentes sobre un solo backend: Next.js 16 (App Router) para la web, que por sí sola ya cubre tres paneles (productor, corredora y admin de la plataforma), y Expo Router para la app mobile del productor. Web y mobile hablan con el mismo Supabase a través de un paquete compartido (@milsaca/db) con tres capas de client: una con cookie de sesión para el server, una sin cookie (solo la clave pública) para rutas con caché, y una con secure-store para mobile.

• 02Multi-tenant de verdad, no solo "un filtro en el WHERE": toda tabla del schema público tiene Row Level Security habilitado, sin excepción, c…+

  Multi-tenant de verdad, no solo "un filtro en el WHERE": toda tabla del schema público tiene Row Level Security habilitado, sin excepción, con aislamiento por corretora_id garantizado en la base de datos, no en la aplicación. Los roles (productor/corredora/admin) viven en un array en la tabla de perfil, lo que permite que el mismo e-mail acumule más de un rol; el admin de la plataforma está en una tabla propia, fuera del enum de roles, para que no se filtre por error en un RLS mal escrito.

• 03La decisión de autenticación es un buen ejemplo de aprender del propio producto: empezó con magic link y se cambió por OTP de 6 dígitos por …+

  La decisión de autenticación es un buen ejemplo de aprender del propio producto: empezó con magic link y se cambió por OTP de 6 dígitos por e-mail, porque Gmail Safe Links hace prefetch automático del link (para escanearlo por seguridad) y termina "quemando" el token de un solo uso antes de que el usuario haga clic. Es un bug sutil que solo aparece en producción, con e-mails reales.

• 04El diferencial de dominio es la clasificación COB (Instrucción Normativa MAPA nº 8/2003): la lógica de tipos, defectos, criba y bebida del c…+

  El diferencial de dominio es la clasificación COB (Instrucción Normativa MAPA nº 8/2003): la lógica de tipos, defectos, criba y bebida del café verde se extrajo a un paquete puro (@milsaca/cob), sin dependencias de runtime, testeable de forma aislada. El informe generado tiene PDF con código QR y una página pública de verificación, y le da al productor algo que hoy se hace en papel o de memoria.

PANTALLAS

RESULTADO

SaaS multi-tenant (web + mobile) con paneles por rol, automatizaciones y datos seguros (RLS). Prueba de que entrego producto complejo de punta a punta.

SaaS en desarrollo activo.

QUIERO ALGO PARECIDO ↗