ORTHOSTOREOrthodontic Supplies Store

A catalogue for people who know the part number

The buyer here is an orthodontist, not a browser. Categories and subcategories carry manufacturer and country of origin, because a practice buys a specific bracket from a specific maker and a near-match is not a substitute.

So the catalogue is organised around those axes rather than around lifestyle merchandising, and search exists to confirm a choice that is already made.

Login by code, not by password

Customers sign in with a one-time code delivered by SMS or email, with a password option for those who want one. A clinic's purchasing is done by whoever is at the desk that day; a shared password would be written on a sticky note within a week.

The SMS sender sits behind an interface with console, HTTP and Twilio implementations, so the same code path runs in development without spending money on messages.

Four states, on purpose

An order is new, processing, done or cancelled. A store this size is worked by people who already know the customer; adding eight states would produce a dashboard full of rows nobody moves.

Cashback is credited when an order reaches done and is adjusted atomically on the customer record, so a balance cannot drift when two orders close at once.

Discounts that survive contact with reality

Discounts are percent or fixed, and promo codes are their own entity with their own rules, because a seasonal campaign and a negotiated price for a regular clinic are different things that expire at different times.

Keeping them apart means ending a campaign never touches the terms a long-standing customer was promised.

An admin panel that answers questions

The back office is a separate React application with charts over sales, so the owner sees what is moving without exporting anything. The API is documented in Swagger, rate-limited, and separated into customer and admin authentication, so a compromised customer session cannot reach the store's own data.