Backend Supabase: modelo de datos, Auth y Rls multi-organización para Erp interno

Somos una importadora y distribuidora de cosmética en Uruguay, construyendo un ERP interno propio. Buscamos al ingeniero que construya su base.
La especificación ya está cerrada: prototipo navegable completo (9 módulos, 31 secciones, con interfaz, flujos y datos de ejemplo) y matriz de permisos en Excel de 9 hojas, con 13 roles por 31 secciones por 9 acciones y sus 403 combinaciones resueltas una por una, más 21 usuarios identificados con rol e instancia. No buscamos que definan qué hacer, sino que construyan bien lo ya definido.

por qué esta fase es crítica
conviven cuatro tipos de organización en la misma base: la empresa (7 roles internos); cadenas retailer partner (2 roles), donde hoy entra una y más adelante su competidora directa; casas matrices de marcas, que ven solo lo de su marca; y proveedores de servicios (estudio contable, despachantes, química). El aislamiento no es una preferencia de interfaz, es un requisito comercial: el frontend esconde, la base tiene que impedir. Por eso esta fase es solo backend y seguridad.

ALCANCE
1. Modelo de datos en PostgreSQL sobre Supabase con migraciones versionadas: organizaciones, instancias, roles, secciones, acciones, matriz de permisos, usuarios y auditoría, con la carga de datos semilla.
2. Tabla intermedia usuario-rol desde el inicio, aunque arranque con un rol por usuario: pedida así para no migrar datos más adelante.
3. Autenticación: Google OAuth restringido al dominio corporativo para internos y correo con contraseña para externos, con un campo que distingue el método. Baja lógica obligatoria: los usuarios nunca se borran físicamente, porque de eso depende la autoría del histórico. Los externos llevan expiración.
4. Row Level Security completo. El tipo de organización determina a qué secciones se llega; la instancia, qué filas se ven dentro de ellas. Cinco alcances ya definidos: global, por retailer, por marca, por embarque y global con notas propias. La lectura total ignora el alcance y solo la tienen roles internos.
5. La pantalla de administración de roles y permisos funcionando de punta a punta: es la única incluida, porque administra todo lo demás. Su comportamiento y sus reglas de integridad están al detalle en el prototipo.
6. Alta de roles, secciones y acciones como datos, no como código: una sección nueva debe poder incorporarse desde la interfaz y quedar disponible en la matriz, sin tocar código ni desplegar.
7. Suite de pruebas automatizadas del aislamiento y documentación en español del modelo y las políticas.

criterios de aceptación
1. Un usuario de prueba de una cadena retailer, autenticado y consultando directamente contra la API sin pasar por la interfaz, recibe cero filas al pedir datos de la otra cadena, cualquier sección interna y el listado de usuarios. Cero filas, no error de pantalla.
2. Un usuario de casa matriz solo obtiene lo de su marca, y uno de proveedor solo lo que su rol tiene asignado. Ningún rol externo obtiene resultados con la lectura total.
3. Los 21 usuarios llegan exactamente a las secciones que la matriz les asigna, verificado rol por rol, y el sistema no puede quedar sin administrador.
4. Alta de una sección nueva desde la interfaz: aparece en la matriz, nace visible solo para el administrador, sin tocar código ni desplegar.
5. Los puntos 1 y 2 quedan como suite automatizada ejecutable con un comando, en el repositorio.

Cómo trabajamos y perfil
stack: supabase (postgresql, auth, rls, storage) y next.js, repositorio en GitHub con commits incrementales. Si creen que otro enfoque es mejor en algún punto, queremos el argumento antes de empezar, no a mitad de camino.
El contacto es directo con el dueño de la empresa, que especificó el sistema y no es técnico: se necesita alguien que explique decisiones en lenguaje llano. Trabajamos por entregas chicas y verificables, con pago contra hitos. Preferimos que algo tarde y quede bien fundado antes que rehacerlo: no hay presión de fecha.

Lo que más pesa en el perfil, por encima de todo: experiencia real en PostgreSQL con Row Level Security en un sistema multi-organización en producción. Además, Supabase con Auth y políticas, migraciones versionadas y pruebas automatizadas como práctica habitual, y explicar en español sin jerga.

para postularse
las postulaciones genéricas se descartan sin responder. Pedimos cuatro cosas:
1. Un caso propio de RLS multi-organización: qué problema resolvía, cómo modelaron el aislamiento y cómo lo probaron.
2. El frontend esconde las secciones que un rol no tiene permitidas. ¿Por qué eso no alcanza cuando el backend es Supabase? En pocas líneas, en lenguaje llano.
3. ¿Cómo harían que una sección nueva se dé de alta desde la interfaz y quede disponible en la matriz de permisos, sin desplegar código?
4. Cotización a precio fijo por la fase 1, con plazo estimado y división en hitos.

El prototipo y el Excel se comparten con los finalistas bajo acuerdo de confidencialidad. Si el proyecto avanza bien hay continuidad: 30 secciones más.