The status is a claim
A cell that reads "Milling" is a claim someone typed. Nothing checked whether the item was ever measured, and nothing will notice if it skipped a step.
Multi-tenant production tracking
Your process. Enforced.
Trakelix™ follows physical things through the process you draw — your statuses, your locations, your idea of what an item is. A move your process does not allow is refused at the door, and recorded as a refused attempt.
Built for workshops, repair benches, labs and small production floors. Driven by printed QR stickers, a phone in someone's hand, and screens on the wall that nobody has to log into.
One organization's board. Every status, location and field on those cards is something they defined — none of it ships with the product, and the next tenant's board has none of these words on it.
Hosted in the EU
Keycloak single sign-on
PostgreSQL
Localises to any language
No third-party trackers, no ad cookies
The problem
A whiteboard cannot refuse a move.
Most workshops already track work — in a spreadsheet, on a magnetic board, in somebody's head. All three record what people say happened. None of them can say no.
The location is a memory
Where a thing physically sits lives in whoever moved it last. Finding it means asking, and asking costs more than the move did.
The history evaporates
Overwrite the cell and the previous value is gone. "How long does Milling actually take?" has no answer, so the estimate stays a guess forever.
Process
Statuses are a graph, not a list.
Every organization draws its own flow on a canvas — drag the boxes, connect them. It can branch wherever a status has more than one legal next step, rejoin further down, and loop back on itself. It is not a fixed list and not a straight line.
- Roles mark the ends. Every status is Start, Inner or End, so the system knows where a process begins and where an item counts as finished.
- Transitions are enforced. Advancing an item to a status the graph does not reach is refused. Where several next steps are legal, the API returns the candidates instead of guessing.
- Deactivating a status moves nothing. An item's position is a real reference to a status, not a counter that shifts when the list changes.
One product, five organizations
Nothing here ships with a process.
Five tenants on the same installation. They share no status, no location and no field, they do not agree on how many steps there are, and none of them were set up by us. Pick one and watch the vocabulary change — the board underneath is the same board.
- Received
- Measuring
- Design
- Milling
- Forming
- Finishing
- Dispatched
Measuring6
ITM-2026-0118
Custom insoles · EU 41
ITM-2026-0121
Sport insoles · EU 38
Design3
ITM-2026-0109
Shoe mould · EU 43
ITM-2026-0114
Orthotic insoles · EU 37
Milling4
ITM-2026-0098
Carbon insoles · EU 42
Two products, two routes: a carbon pair goes straight from Measuring to Milling while a custom pair goes through Design first. Both are legal, so the app hands back both candidates instead of guessing.
An insole job as it opens in the app. Everything under Details is a field this lab defined — none of it ships with the product. The scan, the pressure map and the order are dragged onto the job and stored outside the database, and the preview opens beside the form rather than on top of it, so you read the scan while filling in the fields it belongs to. Meshes render as 3D you can orbit, PDF and Word render inline, and the code carries its own QR label for the tray. Beside it, the screen above the mill: that bench's queue oldest-first, how long each pair has been waiting, and the bench's own sticker on the glass so the next one is scanned in without anybody hunting for the printed label.
- Received
- Diagnosed
- Awaiting parts
- Repaired
- Tested
- Collected
Diagnosed4
JOB-2026-0118
Handset · cracked screen
JOB-2026-0121
Laptop · no power
Awaiting
parts3
JOB-2026-0109
Espresso machine · pump
JOB-2026-0114
Tablet · battery
Repaired2
JOB-2026-0098
Amplifier · mains hum
Awaiting parts is a status of its own because a job can sit there for a week, and a week that nobody can see is a week the customer chases you about.
- Artwork
- Proofed
- Printed
- Trimmed
- Dispatched
Proofed5
ORD-4412
Menu cards × 500
ORD-4418
Exhibition banner
Printed2
ORD-4405
Wedding invites × 120
Trimmed4
ORD-4409
Book · perfect bound
ORD-4396
Business cards × 1000
Proofed leads back to Artwork as well as forward, because a customer who wants one word changed should not need a new job number.
- Sample in
- Preparation
- Analysis
- Review
- Reported
Preparation6
SMP-9931
Soil · heavy metals
SMP-9934
Water · microbiology
Analysis4
SMP-9928
Water · nitrates
SMP-9925
Feed · mycotoxins
Review2
SMP-9919
Soil · pH and texture
Review is its own step because a result nobody checked is not a result — and the transition rules mean nothing can reach Reported without passing through it.
- Returned
- Cleaned
- Serviced
- Available
- Out
- ↺ back to Returned
Cleaned7
KIT-0207
Scaffold tower · 4 m
KIT-0212
Floor sander
Serviced3
KIT-0198
Mini excavator
KIT-0201
Generator · 5 kVA
Available12
KIT-0188
Pressure washer
This is the one that could not be a list at all: Out leads back to Returned, so the same item goes round the process for years. Statuses in a fixed order have no way to say that.
The diagrams elsewhere on this page happen to be the insole lab — that is one of these five tabs, not the product. Everything else, the stickers, the wall, the reports, works identically for all of them.
The floor
One scan does both jobs.
Locations have codes, types, and an optional linked status. Scanning an item into a location records the physical move and advances the status that location represents — because on a floor those are the same event, and asking someone to do it twice means it gets done once.
- Statuses and locations print as QR stickers. A sheet off the office printer, taped to a bench, is the entire hardware requirement.
- An impossible move names both ends. If the graph has no route from where the item is to where the scan implies, the move is refused and the message says which two statuses failed to connect.
- Scan to identify. Point the phone at any sticker — item, status or location — and see what it is without starting anything.
Item fields
Define what an item is.
Rather than a fixed set of columns, an admin designs the item's shape. Values live in a
single jsonb column, so adding a field needs no schema change and no
deployment — and an unknown key is rejected rather than silently swallowed.
-
Purpose outlives the name. A field carries a semantic tag —
customer-email,due-date,owner— so anything that matches on meaning survives somebody renaming the label. - Choice options can carry a colour, from the same swatch grid statuses use. That is what lets the board tint cards by something other than status.
- Links and files behave carefully. A Link accepts http and https only, because the value is rendered as a real anchor. Attachments are dragged onto the item and stored outside the database.
Field types
Text
Long text
Number
Date
Yes / no
Choice
E-mail
Phone
Link
Attachments
customer-email
due-date
owner
+ your own
{
"type": "orthotic-insoles",
"size": "EU 37",
"customer_email": "a.morgan@example.invalid",
"order_link": "https://…/orders/8814",
"due_date": "2026-08-24"
}
One jsonb column. The English key is immutable — it is what the CSV
header uses, so an export written last year still opens. These particular keys are
one organization's invention; the next has none of them.
Dashboard
Two views, one set of numbers.
A board — a column per status, cards oldest first, drag one across to move it — and counts: the same figures as tiles, a donut and bars. Neither is a report that has to be run.
- Illegal targets fade before you let go. The board already knows which columns the graph allows, so it says no while you are still holding the card — and the API checks again regardless.
- Refused attempts surface as red chips on the card itself, not buried in an audit screen nobody opens.
- Colour by adds a second axis. The status is already the column, so tinting by a Choice field answers a different question: what kind of work is sitting where.
- A status can carry a WIP limit. Over it, the column header turns amber. It is a signal and not a rule — nothing refuses to move an item into a full status, because a queue that has grown is information, not an error.
Reports
The history is the report.
Nothing here is a report you have to run or a warehouse you have to fill. Every create, status change, move, edit, attachment and refused attempt is already one append-only row with who did it — the audit screen just reads them three ways.
- One scan is one row. A scan that changes both the location and the status is a single event with both pairs recorded — because it was one physical thing happening, not two records to reconcile later.
- Refused attempts are counted, not discarded. A station being skipped every morning is a fact about the workshop. Refusing the move silently would throw that fact away, so the overview breaks the refusals down by which status people keep reaching for.
- Narrow it down without writing a query. A window from the last 24 hours out to everything, one event type, one person, and a search across item code, name and note.
Overview
The shape of a period: started, completed, the net change between them, the total event count, and how many times somebody tried to skip a step. Then what kind of activity it was, how it fell across the days, and who did the most.
Activity
The log itself — when, which item, what happened, who. Filter by event type or by person, search the item code, name or note, and page through it. Double-click a row to open the item it belongs to.
Time in status
The same events read as durations: how long items actually sit in each status, worked out from the gap between entering it and leaving it. Per status: how many passed through, the median, the average, the longest, and how many are still there.
Trust the median, not the average.
One item left on a bench over lunch drags an average up on its own, which is why the median is the column set in bold. This is the table that answers "how long does Milling actually take?" — and it answers it from what happened, not from what somebody estimated when the process was drawn.
One honest limit: only movements recorded since history started are counted. An item that was already sitting in a status before then has no entry time, so it is not measured rather than being measured wrongly.
| Status | Passed | Median | Average | Longest | Still there |
|---|---|---|---|---|---|
| Measuring | 42 | 8 m 20 s | 11 m 05 s | 34 m 12 s | 6 |
| Design | 28 | 12 m 40 s | 15 m 30 s | 48 m 05 s | 3 |
| Milling | 39 | 14 m 10 s | 18 m 45 s | 1 h 06 m | 4 |
| Forming | 37 | 7 m 55 s | 9 m 20 s | 26 m 40 s | 2 |
| Finishing | 35 | 10 m 30 s | 13 m 15 s | 41 m 50 s | 5 |
The items list is its own view — server-paged, sorted and filtered, with one search
box across the code, name, description and every custom field. Export is CSV, UTF-8
with a BOM and a sep=, line, so Croatian and Slovenian Excel open it in
columns rather than one.
Displays
Screens nobody logs into.
A wall display, a station display, or a screen you designed yourself — each running on a credential that belongs to the screen rather than to a person. It never expires, it can only read the board, and it recovers on its own. A display that needs a keyboard to come back is a display nobody trusts.
Wall and station
The wall shows one tile per status, scaled to be read across a room. A station shows what is physically at one bench, with that location's QR sticker on screen so it can be scanned straight off the glass.
A spare tablet will do
Open the app, tap Use this device as a display, and it shows a short code. Approve the code in Setup, choose whether it watches the whole board or one location, and it is a display from then on. Nothing to sign in, nothing to expire.
Design your own screen
A screen is rows of blocks — status tiles, a big number, a station's queue, a list, what needs attention. Six units of height to share between rows, four of width within each. It can never scroll and never leave a dead band of wall.
The editor cannot lie about the result.
The preview beside the designer is the real display page in an iframe — not a drawing of it. Save the screen and it appears wherever a display is pointed, and every wall already showing it redraws within twenty seconds. Nobody walks over to the television.
Six blocks to build one out of.
A row is four units of width to share between its blocks. That is the whole vocabulary — and it is a budget rather than a ratio on purpose: out of a fixed four, "2" is half the television and needs no explaining.
Status tiles
The coloured tiles the wall board is made of. Choose which statuses appear, and whether each one draws its WIP limit under the count.
Big number
One count, as large as the cell allows: everything still open, one status, finished today since local midnight, or what is sitting at one location. Write your own caption or let it write one.
Station queue
One location's waiting list, as many rows as you ask for or as many as fit. The block a bench actually wants above it.
Station card
One location's identity — name, colour, count, and its QR sticker on screen. This is the block somebody scans straight off the glass.
Item list
Items across the organization or at one location, longest-waiting first — which is the bottleneck, and the bottleneck is what a wall is for — or most recently moved.
Attention
Statuses over their WIP limit, and moves the process refused in the last few hours. It says Nothing to flag when there is nothing: a block that draws nothing when all is well is indistinguishable from a block that has broken.
Android app
A scanner in the hand.
For the person actually holding the thing. Set a target status and scan items into it; scan a location and then scan items to move them there; or scan either one just to see what it is. Plus a small dashboard of counts.
- It signs in as a person, not a device. Through the system browser with PKCE, so every move it makes carries a real name in the audit trail.
- Same stickers, same rules. It reads exactly the QR codes the web app prints, and an illegal move is refused on the phone for the same reason it is refused in the browser.
- Android. The same build also runs as an unattended board, so a retired phone becomes a station display.
Events & rules
When this happens, tell someone.
Four triggers, three audiences, and a message you write. Deliberately not a rule engine: a condition language would be more powerful and nobody would write one correctly. Every rule here is a sentence you can read back to the person who asked for it.
- Four triggers. An item entered a status — optionally only when it arrives from one particular status, which is what makes "when it comes back for rework" expressible. It has been stuck in a status too long. It has been open too long wherever it is. Or it reached an End status.
- The audience is a purpose, not an address. Fixed addresses if you want them — but also "whatever this item's customer e-mail field holds" or "everyone with access to that status", so the rule keeps working after somebody renames the field.
-
Five placeholders, not a template language.
{code},{name},{status},{location}and{age}— a small fixed set, for the same reason the triggers are fixed.
A rule, as it reads
When an item has been stuck in Milling for 2 days, tell everyone with access to that status.
Subject {code} is still in {status} after {age}
Body {name} has not moved since it entered
{status}. It is at {location}.Nothing sends yet
Rules can be written, stored, listed and switched on and off today. The part that watches the clock and actually delivers the message is a separate piece of work and it is not finished. We would rather you read that here than find it out afterwards.
What gets recorded
Eight kinds of event, append-only, each carrying the person who caused it. This is the same log the reports read and the same one a rule would watch.
Created
Status changed
Location changed
Fields changed
Completed
Attachment added
Attachment removed
Refused attempt
Control
Who may do what, and what already happened.
Every rule below is enforced at the API rather than by hiding a button, because a hidden button is a suggestion.
Nothing overwrites the past
The history is append-only and always carries the person, so a record cannot be quietly corrected after the fact. Reading it is a right you grant separately — see Reports.
Access per status and location
Per-user rows applied to the items list, the CSV export and the dashboard alike. A filtered board says that it is filtered rather than looking empty.
Program rights
Export the list, open Setup, open the audit screen, delete items — each granted separately, and each narrower than the role it used to take. Delete is off by default: it destroys the history and the files, and there is no undo.
Retention that runs itself
Finished work is kept for a set number of days — two years by default — then deleted with its history and files by a daily sweep. Work still moving is never touched however old it is. Setup shows what the next sweep would remove before you save.
Sign-in is Keycloak
OIDC with a branded login page and invite e-mails. Three separate clients: the browser, the API's admin access, and the phone. Nothing shares a secret it does not need.
Files stay out of the database
Attachments go to object storage or disk; only their description is a row. Paths are
built from server-generated ids, downloads are always
attachment; nosniff, so an uploaded page cannot execute on this origin.
Data protection decisions
EU region, per-organization retention, self-hosted fonts, no third-party analytics. These are engineering decisions we can point at — not a compliance certificate, and we will not pretend otherwise.
One example of many
An insole workshop, end to end.
One tenant, followed the whole way through — because a concrete story is easier to judge than a list of capabilities. Read insole as whatever you make or handle: nothing in the application knows what an insole is, and the same six steps could as easily be a repair, a print job or a lab sample.
Everything below happens in the app today. The one thing it does not do yet is tell anybody about it by itself — see Events & rules.
1
An order arrives. An item is created at Received with its type, size, customer contact and a link back to the order. The customer's foot scan is dragged onto it as an attachment.
2
It is carried to the measuring room. Somebody scans the sticker on the bench. The item moves to Studio and its status becomes Measuring in the same action.
3
The process branches. A carbon insole goes straight to Milling; a custom one goes through Design first. Both routes are legal, so whoever has it in their hands is asked which.
4
Somebody scans it into Dispatch too early. The move is refused, the message names both statuses, and a red chip appears on the card. The item has not moved.
5
The wall shows the queue all day. Nobody logged that screen in and nobody will; it is a paired tablet on a shelf.
6
It ships. Dispatched is an End status, so it leaves the board. Two years later the retention sweep removes it, its history and its files — or never, if you switched that off.
Draw your process. Then make it true.
Trakelix™ runs in the browser, on a phone, and on whatever screen you hang on the wall. Nothing to install on the floor beyond a printed sticker.
Contact
Tell us what you make.
Describe the thing that moves through your workshop and the steps it goes through, and we will tell you plainly whether Trakelix™ fits — including when it does not.
- A walkthrough of your own process. Bring your statuses and locations; we draw them on the canvas while you watch.
- A tenant to try it in. Your own organization on the shared installation, with nothing of ours pre-filled in it.
- Straight answers on hosting. EU region, retention, single sign-on and what a self-hosted installation would involve.
Would rather just write? info@trakelix.com