DayBook

Distributors who lend to shops and collect daily have a specific shape to their business: a rep walks a route, sees the same shops each cycle, records what was paid, and settles up at the end of the day. The software almost never matches that shape. It models customers and invoices, and the rep has to translate.

DayBook models the route instead. A route belongs to exactly one admin, and that ownership column is the tenant boundary — enforced in a single module rather than remembered at every query site. Everything else hangs off it.

The hierarchy is three deep. A super admin creates admins and routes and assigns one to the other. An admin owns routes and adds sales reps to them, receiving two portal URLs the moment their account is created. A rep walks one route and signs in with a four-digit PIN on their phone.

Creating an admin is deliberately a single act rather than a sequence of forms: name, email, phone, NIC, address, optionally a first route — and one transaction produces the account, a numbered route assigned to them, and both portal URLs. The alternative, half-created admins waiting for someone to finish the job, is the kind of state that causes support calls a year later.

Two authentication schemes run side by side: NextAuth with JWT sessions for password logins, and a custom signed cookie for the PIN logins, because a four-digit PIN on a shared phone should not mint the same session as an office password. Server actions are guarded by a permission table rather than scattered role checks.