Case · custom system

Twenty modules around the day's schedule

A therapy center with several locations: patients, sessions, specialists, treatment beds, payments with an electronic invoice, and staff. The system has twenty modules, and one of them gets looked at every hour: the day's schedule. Everything else exists to keep it up to date.

Why there is no demo here you can open

This is the system a client works with every day, with patient data inside it. There is no public version and there never will be. What you see are screenshots of a separate instance, with the branding replaced, a sample tax ID and patients, specialists and contacts generated by the project's own test data: nobody in them is a real person.

The day's schedule with one column per specialist, their hours and the sessions placed in their time slot — **The day's schedule.** One column per specialist and each session in its slot, with the location at the top. You can look at it by specialist, by treatment bed or by patient, compare what was *planned* against what *happened*, and tighten or loosen the density of the grid, because going over the whole day at the front desk needs a different view from a quick check mid-morning.

Screen for issuing an electronic invoice, with its validations — Issuing the invoice. At the bottom, a list of checks that turns green as the form is filled in: **nothing is issued until every one of them passes**. An invoice issued wrong costs a credit note and a phone call.

Consultations dashboard with the contact funnel and its metrics — The people who answer the phone and the people who treat patients are the same team, so the contact funnel lives inside the same system.

The system's home screen with its modules grouped by area — The modules, grouped by area: patients, scheduling, packages, inventory, pharmacy, front desk, invoicing, human resources, projects. **Twenty modules, and all of them are in use**.

How it is built

A Django backend running on ASGI with Daphne and Redis behind it, PostgreSQL, and the frontend as a separate application that talks to the API.

Django
ASGI · Daphne
Redis
PostgreSQL
Docker
nginx

Running it outside the client's network

To take these screenshots the whole system had to run outside the client's infrastructure. These problems only show up when you try, and each one makes a system harder to move:

Host names with an underscore are not valid domains, and Django rejects that header. The error you get looks like a credentials problem and has nothing to do with one.
Startup depended on variables nobody uses any more: a legacy database and an external image service. Without them the system would not come up, even though nothing needed them.
The server configuration carried fixed addresses from the client's network and their own certificates, so outside that network not even the proxy would start.

None of the three is a serious fault in production, but each one costs an afternoon when you have to migrate, make a backup you can restore, or show the system to someone.

Do you have a system like this, or are you asking for one?

Custom management systems that hold up to the daily running of a business, with the boring part already done: permissions, valid invoices and numbers that add up.

Let's talk →