← Back to the Forge
Shipped Next.jsIoTPaymentsWhatsApp

Lavvo — smart-locker sneaker laundry.

A premium sneaker-cleaning service that runs on unattended smart lockers installed in gyms and clubs. The customer drops the shoes into a locker from the app, operations collects by geographic cluster, and the pair comes back within 48 hours to the same door.

Client
Lavvo
Period
2026
Role
Architect & lead developer

Domain models

27

Application code

~18k LOC

User roles

4

Turnaround

48h

lavvo.app
lavvo.app
lavvo.app
lavvo.app
lavvo.app
lavvo.app
lavvo.app
lavvo.app
lavvo.app

The problem

A sneaker laundry only scales once collection and delivery stop depending on someone being physically present. The bet was unattended lockers inside partner venues — which turns a service business into a distributed hardware problem: doors that have to open at the right second for the right person, a courier route that has to know what sits behind each door, and a partner who has to trust the revenue split.

On top of that sits Brazilian tax compliance: every cleaning cycle is a service invoice, and NFS-e is not optional.

The solution

One system covering the four sides of the operation, each with its own interface and permission set: the customer app (deposit, tracking, retrieval), the operator queue (collection by cluster and rescheduling), the partner panel (traffic and revenue share) and the admin back office (lockers, doors, orders, coupons, ads, invoices).

  • Deposit is guided — the app walks the customer through photographing the pair from four angles before the door closes, which settles condition disputes before they can happen.
  • Payment is Pix through Asaas, with a simulated-payment path that keeps the whole flow demonstrable without touching a real gateway.
  • Notifications go out over the WhatsApp Cloud API on scheduled cadences, because that is where the customer already is.

Architecture

A single Next.js application on Server Actions and RSC — no separate API service to keep in sync — with Prisma over PostgreSQL and a strict four-role RBAC boundary.

  • Locker hardware. The vendor API expects signed requests over plaintext HTTP from a fixed IP, so it sits behind a dedicated HTTPS proxy. Request signing is covered by unit tests, and door events come back through an inbound webhook.
  • NFS-e Nacional. A full implementation rather than a third-party wrapper: DPS XML generation, an A1 e-CNPJ certificate stored encrypted at rest with AES-256-GCM, and XML-DSig signing.
  • Scheduled work. Cron routes drive the notification cadences and purge customer photos once their retention window closes.

Results

The full cycle runs unattended: the customer never meets an employee, and the partner venue does nothing beyond hosting the locker. Invoices are issued without a human in the loop, and the demo seed reproduces the entire operation locally — which is what made this case study possible without exposing a single real customer record.

Full stack

Next.js 16 (App Router)React 19TypeScriptPrisma 7PostgreSQL 17Auth.js v5Tailwind v4LeafletAsaas (Pix)WhatsApp Cloud APIVercel BlobVitest
João Afonso Assumpção Systems Architect · Automation Engineer · Solution Builder
© 2026 · All rights reserved. Built with SvelteKit