The Problem

The client is a dental specialist who makes custom mouthguards for martial-arts athletes — MMA, boxing, BJJ. The process is document-heavy: medical forms, X-rays, photos, 3D jaw scans, delivery details, back-and-forth about fit and timing.

Before the app, everything happened over email and messengers. Files got lost, statuses lived in his head, and clients kept asking the same questions between production stages.

He needed a single system where a fighter can register, send all the medical material at once, pick where to drop off the scan (or ship it), and message him about the order — and where he can run the whole operation from one admin panel.

Design

I designed the app from the ground up around the actual production workflow, not a generic e-commerce template. Two separate experiences share the same codebase: a clean client portal focused on placing and tracking a single order, and a dense admin panel built for someone managing dozens of orders in parallel. Approved before development started.

Approach

Two apps, one codebase. Next.js App Router with route groups — (client) for the fighter-facing portal, admin/ for the clinic. Middleware gates everything by role; clients can’t even see admin routes exist.

Orders as the core entity. Every order carries its client, its dentist location (or an “I’ll deliver scans myself” flag), its delivery method (courier or InPost paczkomat), its documents, its status history, and its message thread. One record, one page, everything.

File handling built for medical workflows. UploadThing handles the uploads — medical documents, X-rays, photos, and 3D jaw scans (STL/OBJ). Admin can preview, download, add files on behalf of the client, or grab the full package as a ZIP via JSZip for the lab.

Auth that matches the business. NextAuth with credentials provider, email verification for self-registered users, and a separate admin-initiated flow: the clinic creates the account, the client gets a signed set-password link by email. Password resets, resend-verification, and resend-set-password all run through rate-limited endpoints.

Status history, not status updates. Every status change writes a StatusChange row with the previous state, the new state, who did it, and an optional note. The client sees a clean timeline; the admin has full auditability.

Messaging as part of the order, not a separate inbox. Each order has its own thread. Unread flags flip per recipient, so both sides see exactly what’s new without hunting through a global inbox.

Locations as first-class data. The dentist office network is its own model — the admin manages it from the panel, deactivates offices that aren’t taking scans, and only active ones show up in the client’s checkout picker.

Prisma + PostgreSQL. Strongly-typed schema across the whole stack — users, orders, documents, status changes, notes, locations — with indexes on the fields that actually get queried (email, order number, status, unread messages).

Challenges

Two completely different user experiences. A fighter placing one order has different needs from an admin processing twenty. Same codebase, shared components where they made sense, entirely separate UX where they didn’t — the client flow is guided and minimal, the admin side is table-dense and keyboard-friendly.

Scan delivery logistics. Not every client uses the same path. Some ship via courier, some use InPost parcel lockers (with a point number), some drop scans off at a partner dentist, some deliver them personally. The order model and UI both had to cover all four without turning into a mess.

Admin-created accounts without passwords. When the clinic creates a client on their behalf, that user doesn’t exist yet in any meaningful sense — no password, no verification. The set-password flow uses signed tokens with expiry, a dedicated email template, a resend endpoint, and rate limiting, so an admin can onboard a fighter with just an email address and a phone number.

File volume per order. A single mouthguard order can carry a dozen files including large 3D scans. The admin needs to preview them, add more on the client’s behalf, and hand the whole bundle to the lab — which is why every order has a one-click ZIP export.

Secure-by-default flows. Every auth endpoint — register, forgot-password, reset-password, resend-verification, resend-set-password — is rate-limited. Tokens are signed and time-bound. Uploads are scoped to the authenticated user’s own orders. No shortcuts for “internal” endpoints.