Una sola plataforma multi-tenant maneja el cerebro: usuarios, roles, cobros y apertura remota en cascada. Lo único que cambia entre modelos es la barrera de acceso y quién carga el contenido. El hardware es el mismo mueble sin pantalla.
Todos los modelos corren sobre la misma arquitectura: panel Debian autocontenido en cada mueble, backend Node + Postgres local, y una capa cloud que orquesta consorcios, roles y cobros. Enchufar un panel nuevo no es reescribir software, es aprovisionar una config.
Lo único que define el modelo de negocio: pago por tiempo, padrón fijo, u orden de compra. Es una config, no un fork.
Consorcios, jerarquía de roles en cascada, cobros con Mercado Pago validados por webhook, auditoría. Aislamiento por consorcio con Row Level Security.
Cada mueble corre todo local: Node + Postgres + Nginx. Opera aunque se caiga internet; solo el cobro necesita salir a la red.
Placa de relés + cerraduras. Sin pantalla: la persona opera desde su celu por QR, o el mueble lee un QR/credencial con lector físico.
Nada de esto es propietario ni depende de un solo proveedor — el mismo tipo de stack que corre bancos, e-commerce y sistemas críticos, elegido porque es probado. Los datos sensibles se validan y guardan siempre en el backend, nunca expuestos en el frontend, y cada mejora se despliega de forma versionada sin interrumpir los puntos ya instalados.
Benchmark real contra el servidor del panel — una PC de gama baja, 2 vCPU y 3.7GB de RAM. 1000 requests por nivel de concurrencia desde la misma LAN. Los tres modelos corren sobre el mismo backend, así que esta capacidad aplica por igual a los tres.
Estos números están muy por encima de lo que genera el uso real de un locker en la calle (gente escaneando de a una, no ráfagas). Y lo logra con una compu chica — el mismo sistema corre cómodo hasta en una Raspberry Pi.
QR fijo pegado en el mueble. Cae en la web del panel desde su propio celu.
Selecciona casillero libre y duración. Paga con Mercado Pago en ARS.
MP confirma el pago contra el backend. Nunca se confía en el front.
El panel habilita la apertura. Guarda sus cosas por el tiempo pagado.
Al vencer o al terminar, el casillero vuelve a estar disponible.
El admin da de alta a cada persona y le asigna un casillero fijo, con contraseña generada automáticamente.
Cada persona recibe su asignación: el casillero es suyo por tiempo indeterminado.
Inicia sesión con su usuario y contraseña desde el navegador del celular.
El sistema identifica al usuario y abre únicamente su puerta asignada.
Al irse la persona, el admin desasigna y libera el casillero para otro.
El cliente compra el producto online y paga. La orden queda registrada.
Abre el casillero con un link/QR de entrega y deja el pedido. Recién cuando el sistema detecta el cierre de la puerta se genera el link de retiro.
El link de retiro se manda por email o WhatsApp — nunca antes de que el pedido esté físicamente adentro.
El cliente valida su DNI contra el pedido y recién ahí puede abrir, con botón o escaneando el QR.
Al retirar, el casillero se libera automáticamente para el próximo pedido.
Toda apertura se autoriza con un código propio de esa operación. Encima, cada modelo suma solo las capas que necesita: la verificación de DNI es un módulo de Distribución, no un requisito de la plataforma.
Solo para el modelo de retiro de compras: antes de mostrar el botón de apertura, el cliente valida su DNI contra el pedido, con rate-limit de 5 intentos. Ata la apertura a la identidad del comprador, no solo a tener el link. Renting y Corporativo no lo llevan: es una función que se activa por modelo.
Cada retiro o alquiler genera un código propio: largo, imposible de adivinar, con vencimiento y atado a esa operación. Se invalida al usarse (con un par de reintentos dentro de la ventana, por si la puerta se cierra sola) y cada apertura queda registrada. Si el QR se reenvía después de usarse, no abre nada. Sin pedir documento y sin fricción extra.
Quien pagó o reservó puede delegar el acceso con un link propio, distinto del QR original: se usa una vez, se puede revocar y queda auditado. Compartir es delegar, no copiar: el acceso del titular sigue siendo privado.
Validar el DNI del comprador cae bajo la Ley 25.326 de Protección de Datos Personales: es dato sensible y guardarlo implica obligaciones de resguardo y posible registro ante la AAIP. Con el acceso único por operación no se toca ningún dato personal — otra razón para que el DNI sea un módulo que se activa solo donde el modelo lo pide.
Estamos evaluando Apple Wallet y Google Wallet: la credencial de acceso dejaría de vivir solo en la web y pasaría a un pase que la persona guarda en su billetera nativa. Se prototipó una versión de los botones con detección iOS/Android en una instalación anterior (sin generación real del pase); en el sistema actual todavía no hay desarrollo hecho sobre esto.
El QR de acceso queda como pase en el celu. Se abre sin entrar a la web ni buscar el mail. Menos fricción que el flujo actual, sobre todo en el uso diario.
Donde más rinde es en el modelo por asignación: la persona usa su casillero fijo todos los días. Tener el pase siempre a mano en la billetera es la vía más cómoda.
La interfaz muestra "Agregar a Apple Wallet" en iOS y "Agregar a Google Wallet" en Android, según el dispositivo. Nada de mostrar el botón equivocado.
No arrancado en el sistema actual. Se prototipó una vez la lógica de detección iOS/Android en una instalación anterior, sin generación real del pase. Falta desde cero: vínculo con las cuentas de desarrollador de Apple y Google, y la generación/firma del pase.
| Renting / Eventos | Corporativo | Distribución | |
|---|---|---|---|
| Barrera de acceso | El pago | El padrón | La orden de compra |
| Cobro | Por tiempo (ARS) | Sin cobro por uso | En la compra web |
| Usuario | Identificado (cuenta al alquilar) | Identificado / fijo | Comprador identificado |
| Quién carga | El propio cliente | El dueño del casillero | El staff del local |
| Asignación | Temporal por tiempo | Fija, indeterminada | Efímera por orden |
| Método de apertura | QR fijo lleva a la webapp; abre el acceso único del alquiler | Celu auth o lector QR | OTP / QR de un solo uso |
| Identidad | No requiere | Padrón (auth) | DNI contra el pedido (módulo) |
| Wallet (en evaluación) | — | Apple / Google Wallet | Pase por orden (a futuro) |
| Rotación | Alta | Nula (fijo) | Media (por pedido) |