Traxxus exists because two old Python services were doing one job between them, badly.

django-casetrack was the write side: orders as “cases”, their checkpoints as “stations”, a JSON API and a Django admin. tectrack-api was the read side: a read-only FastAPI site that pulled a case from casetrack’s API on every request and rendered a friendly Greek page for the customer. Two deployments, two databases in practice, and a customer page that was only as current as the last sync.

The replacement is one Elixir and Phoenix application. Rewriting it forced a question the old model had answered by accident: what is a tracked thing, exactly?

The domain, generalised

The legacy model tracked physical goods through checkpoints. That is too narrow. What a business tracks is work progressing through stations.

• A Flow is the thing progressing. Not a “case” (it collides with the language keyword and with the legal sense) and not an “order” (too physical).
• A StationTemplate is a blueprint: the kind of station, and which capabilities it supports — documents, a URL, geolocation, photos, voice notes.
• A Station is an actual entered station: an event with a timestamp, an author and the evidence attached to it.

Templates come from baskets — commercial_order, ticket_resolution, shipping — or a business defines its own and localises them, because the stages of a Greek installation are not the stages of a Dutch delivery.

That generalisation is the whole point. The same application now tracks an order, a support ticket and a shipment, and adding a fourth kind is configuration rather than a new model.

The customer side

A public tracking link per flow. No account, no login, just the stages that matter to the person waiting, plus notifications when a stage goes late. Most tracking software sells a portal; the customer wants a URL and a timeline, and everything else is account management somebody has to maintain.

Where it stands

Work in progress. The flow model, the stations, notifications and the public link exist. Reporting and permissions do not. The migration map is written, the legacy behaviour is documented from the code, and the missing parts are missing on purpose: I would rather ship a correct domain than a complete feature list.

When it replaces the two legacy services, the win will be modest and real: one deployment instead of two, one schema instead of a sync, and a customer page that is true the moment it is read.