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, but there is one that gets looked at every hour, and 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 is the heart of the system.** 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 day at the front desk is not the same as checking it 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: the contact funnel lives inside the system, not in a spreadsheet on the side.

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 pieces that are actually used**, not a menu of good intentions.

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

What you learn taking a system out of the network it was born in

To take these screenshots the whole thing had to run outside the client's infrastructure. None of this shows up until you try, and it is exactly what separates a system you can move from one you cannot:

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, and every one of them is a lost afternoon when you have to migrate, make a backup you can actually 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 →