All case studies
Case Study — Custom Platform, Built and Maintained

O Lab Plus We built the platform an optical lab runs on

An independent optical laboratory in Brossard, Québec. It has served eyecare clinics since 1987. We designed and built the platform its orders run through, and we still maintain it release after release.

Book a call How we build platforms
The O Lab Plus website
Client
O Lab Plus
Sector
Optical laboratory
Engagement
Custom build → maintenance
Status
Ongoing mandate

The client

It runs the whole lab

O Lab Plus has been cutting and mounting lenses for eyecare clinics out of Brossard since 1987. Orders arrive through the platform, production is tracked in it, clinics are answered in it, and invoices come out of it.

  • Order intake
  • Production
  • Frame logistics
  • Inventory
  • Billing
  • Client portal

The one hard constraint

A lens can't be cut until the right frame is on the bench.

That single dependency explains the frame dashboard, the waiting status, and a delay report that withholds a date rather than guessing one.

The order path

How an order moves

Eight states that match real work on a bench. That is the resolution someone needs to answer “where is it?”

Draft

Started by the clinic, not sent.

To verify

The lab checks the Rx and lens build.

In progress

Accepted, on the floor.

Uncut production

Lenses surfaced, not yet cut.

Cutting and mounting

Cut to the frame and mounted.

Finishing

Final checks.

Shipping

Left the lab, on the way to the clinic.

Invoiced

On the clinic's statement.

Frame on hold

Waiting on the frame. The order parks here, and the delivery date is withheld instead of guessed.

Remake

The job runs again. Counted separately, so rework never flatters the month's numbers.

Inside the admin

What the lab works in

One console for every order, with the exceptions as counters along the top instead of filters someone has to remember to apply. The messages live on the same screens, attached to the order they are about.

Every order, and every exception, on one screen

Production runs from this console. The exceptions are counters along the top, not filters someone has to remember, so the orders that need a person are visible before anyone searches.

On this screen

  • Counts of drafts, orders to verify, and frames with no order
  • Search by order, invoice, patient or account
  • Bulk status change, so a finished tray moves in one action
  • Scan mode at the bench, a late-only filter, exports by period
The admin order console: a global search with PDF import, counters for drafts, orders to verify and frames without an order, supplier and report actions, quick controls with a scan-mode toggle and bulk status change, advanced filters, and the order table below.

Every message sits on the order it is about

A clinic asks about one job, so the thread opens with that job beside it: account, status, frame, both delay dates, shipping date. Nobody has to look the order up to answer.

On this screen

  • Order context above the thread, read from the order
  • Lab and clinic messages in one thread, with times
  • Six quick replies for the answers that repeat
  • A flag on threads still waiting for the lab
The client messages screen: a list of conversations with an À répondre flag, the order context for the open thread showing account, status, frame, internal and external delay and shipping date, the lab and client messages in order with timestamps, six quick-reply buttons and a message box.

New business lands in the same inbox

The public contact form writes into the Prospects tab, beside the client threads. When the lab takes a clinic on, one button turns the request into an account, so a new client is never typed in twice.

On this screen

  • Requests arrive in the same inbox as client messages
  • Role, date and the request itself on every card
  • Reply by email, or reopen a request marked as handled
The Prospects tab of the messages screen: account requests from the public contact form, each with the sender's role, the date, the message, a Traité status and buttons to reopen, reply by email or create the account.

Stock ordered, then reconciled

Supplier orders move through five states, and every row shows how much actually arrived: five of five, or none of seven. A part delivery is visible without opening the order.

On this screen

  • Counters for draft, sent, partial, received and cancelled
  • Received quantities per order, not just a status
  • A reorder list built from stock levels, not by hand
The purchase orders screen: buttons to generate a reorder list and create a purchase order, five status counters for draft, sent, partial, received and cancelled, and a table of orders showing supplier, status, received-versus-ordered quantities with a progress bar, total, order date and per-row actions.

This is a demonstration environment, not production. Every clinic, patient name, prescription and figure is invented. No O Lab Plus customer, patient or supplier appears on this page.

The clinic side

What clinics see

The same platform, deliberately smaller. Every question answered here is a call the lab doesn't have to take.

Ordering means dictating a prescription

A clinic is not filling in a contact form. It specifies something the lab has to be able to make, across three tabs with a live summary beside them, so the order is visible before it is sent.

On this screen

  • Prescription per eye: sphere, cylinder, axis, addition
  • Lens design, index, treatment, thickness, base curve, tint
  • Required fields set by the lens type chosen
  • Prescription orders and stock orders kept apart
The clinic order form on the lens tab: order type, lens design, index, treatment, extras, thickness and base curve, pupillary distances and segment heights with required-field warnings, tint colour and density, and a live order summary panel listing the prescription and lens details.

Told before they ask

The clinic hears when the order changes state, including the awkward states. A delivery date pushed back three working days is said plainly here, not left for someone to find out on the phone.

On this screen

  • Frame waiting, delivery date revised, shipping date pending
  • Order ready, frame received, lab closed for a holiday
  • An unread count, mark as read, and dismiss
The clinic notifications screen: tabs for all and unread with counts, and a list of notifications — frame awaited, delivery date revised, shipping date pending, order ready, frame received and a lab closure — each with an icon, a plain-language sentence, how long ago it arrived, and controls to mark read or delete.

The rest of it

And everything else

The unglamorous half. It still has to be right.

Frame tracking

Who is waiting on a frame, how long they have waited, and whose delay it is.

Statements & aging

Gross, discount, net, payments and balance per clinic, with aging across five buckets.

Inventory

Stock levels, shelf locations, below-minimum warnings and reorder recommendations.

Reports

Delay risk, shipping manifests, print lists, supplier anomalies — generated on demand.

Email & audit

Every email sent, an inbound triage queue, and a trail on every report.

Public site

The lab's product pages, with a contact form landing in the same inbox as client messages.

How we built it

We built it. We still run it.

There was no system to copy. We started at the bench, learned how the lab works, and built the platform around it.

  1. Learn the work

    Before we wrote code
    • We watched the lab cut and mount lenses, and asked why each step exists
    • We wrote down the rules nobody writes down, like a lens that waits for its frame

  2. Build it in pieces

    One module at a time
    • Order intake first, then production, frames, billing and the clinic portal
    • Each module went into real use before we started the next one

  3. Launch it safely

    Go-live
    • Prescriptions and patient names are health data, so each clinic reaches only its own
    • We tested the paths that fail: a supplier file that will not import, a frame that never arrives

  4. Keep it running

    Ongoing, no end date
    • We review every significant change before it reaches the lab
    • New modules land on a platform we wrote, so nobody has to guess how it works

The result

Where it stands

Prescription to invoice on one platform, built for a lab that has traded since 1987 — and shipped release after release.

For the lab

Production, frames, billing and every clinic conversation on one record.

For its clinics

Their own orders, and an honest answer about a late frame rather than a date that won't hold.

Next

New modules land on a platform we wrote. We review risky changes before they ship.

Your turn

If you need a platform like this

Off-the-shelf software rarely fits a business that has its own way of working. When it doesn't, we build the thing that does.

We learn the work first

Why a lens can't be cut before the frame lands is not in any brief. It is on the floor, and we go and look.

We build it in pieces

One module goes into real use before the next one starts. You see the platform work early, not at the end.

Then we keep it running

We don't hand you a repository and leave. We review every significant change and build what comes next.

Tell us how your business runs

Describe the work, the people who do it, and the parts no software you've tried can handle. We'll tell you what we can build, and what it costs.

Book a call Learn more about DevStudio

Next case study

Shiploose: material requisitions for a modular builder, off the spreadsheet

Read it

A platform like this oneWe build it, then we keep it running.

Book a call