Tipuleemo

I built the mobile app and backend around that workflow. Doctors, technicians, delivery staff, and the lab office need different views of the same order. The challenge is keeping the details consistent while giving each person an interface that fits their part of the job.

An order is more than a status

The order form captures the clinic, restoration type, selected teeth, material, and shade. An order can contain several items, including tooth-level selections. Lab staff can also place an order on a doctor's behalf. The interface needs to make those choices understandable on a phone, without hiding the information the technician will need later.

Doctor-created orders enter an approval queue before production. While an order is awaiting approval, the doctor can still edit or cancel it. Once work begins, the application keeps a history of status changes, edits, and staff assignments.

Inside the app

The order form and administrator home screen, captured from the mobile app.

View full size ↗

View full size ↗

Production has exceptions

Lab work moves through scanning, manufacturing, finishing, quality checks, packing, and dispatch. It can also go on hold or require a remake. Treating every order as a single forward-only progress bar would leave those ordinary exceptions outside the system.

The app distinguishes the next production step from a jump forward or a move backward and asks for confirmation where appropriate. Different roles have different authority. A delivery person can handle dispatch and delivery for their assigned orders; that does not give them the technician's production controls.

Pickup and delivery are part of the product

Doctors can schedule scanning visits and impression pickups. Scheduling has to account for the delivery person's availability and the physical scanner being reserved. Database constraints protect those bookings when two requests arrive together.

Delivery staff can work with assigned orders and claim available deliveries. Location updates provide the lab with a recent position while work is in transit. The app explains background location use before requesting the device permission, and supports a foreground fallback when that is what the person allows.

Prices and invoices need a memory

An order's unit price is captured when it is placed, including any applicable doctor-specific pricing or discount. Updating a price list later does not rewrite an existing order. That separation keeps historical work intelligible to both the clinic and the lab.

Invoices collect delivered orders for a billing period. Scheduled and manual invoice generation share database protections so the same work cannot be billed twice by competing requests. Drafts, sent invoices, payments, and cancellations have distinct handling. PDF and spreadsheet exports come from the same underlying records.

One mobile app, different working days

The client uses React Native and Expo, with Expo Router for navigation. TanStack Query handles server data, while Zustand stores client state. A NestJS API owns the domain rules and uses Prisma with PostgreSQL.

Access checks happen in the API as well as the interface. Cached data is cleared when the signed-in account changes. Session restoration distinguishes a network problem from an invalid login, so a temporary connection failure does not automatically become a sign-out.

Tipuleemo also exposes a read-only integration for Kaya Dental PMS. That lets the clinic see relevant lab work without turning the clinic's software into another lab administration interface.

What makes this project interesting to me is the handoff between people. The screen is one part of it. The order history, assignment rules, pricing, and delivery workflow have to agree about what happens next.