The Tsbiga Fight: Why Garages Need Immutable Ledgers

The opening claim

A car comes into an auto paint shop with a scratch on the rear door. Four days later the owner collects it and points at a mark on the front wing. He says it was not there before. The shop owner is certain it was. Neither of them has a single piece of evidence.

The shop owner pays. He always pays. Not because he is wrong, but because he cannot prove he is right, and arguing with a customer in a neighbourhood where reputation travels faster than any invoice is a losing trade even when you win.

That loss is not a rare event. It is a line item, absorbed silently, month after month, by thousands of workshops that have never once described it as a software problem.

The mechanism 🧠

Now watch what happens when a developer tries to fix this.

He builds a job management system. It has a form. The form has fields for the vehicle, the customer, the parts, the labour, the intake condition, the photos. It is complete, it is normalised, and it is correct. He deploys it and comes back a month later to find the shop still running on chalk.

The failure is not technical. It is that he priced the worker's time at zero.

The man doing tsbiga has paint on his hands, is wearing gloves, is standing next to a car under lights, and is measured on cars finished per day. A form with fourteen fields is a tax on the only thing he is paid for. So he does what any rational person does: he fills it in at the end of the day from memory, badly, or he does not fill it in at all. Either way the data is fiction, and fiction in a dispute is worse than nothing because it looks authoritative.

Meanwhile the chalk works. A number on a windscreen, a note on a wall, a memory held by the man who did the job. It is instant, it costs zero seconds, and it never rejects your input for being incorrectly formatted. Any replacement has to beat that on speed, not on completeness.

So the design constraint is brutal and simple: capture must cost less than five seconds, and it must be possible with one thumb, dirty hands, and no typing.

The second half is what you capture. Not state, events. The naive schema stores a job with a status column that gets overwritten as the work progresses. Received, then in progress, then painting, then done. Each write destroys the previous one. At the end you know where the car is now and nothing about how it got there, which is precisely the information a dispute requires.

An append only timeline stores the transitions instead. Car received at 08:12 with four photos. Bumper removed at 09:40. Filler applied at 11:05. Paint at 14:20 by this worker. Ready at 16:50. Nothing is ever updated. When the customer points at the front wing, the owner opens the intake photos from 08:12 and the conversation ends in about ten seconds.

Comparative Breakdown

The middle column is where most software for traditional trades dies. It is not that the app was bad. It is that it asked a man holding a spray gun to become a data entry clerk.

The Algerian reality

Take this into an actual workshop in Algiers or Blida and the constraints get sharper.

The transaction is cash and it is partial. A customer leaves 10,000 DZD as an advance on a 35,000 DZD job, pays another 15,000 DZD when he sees the primer, and settles the rest on collection, sometimes. There is no card, no invoice trail, no bank record. The only ledger is the owner's notebook, and the notebook has the same weakness as a mutable database row: when two people remember different numbers, whoever wrote last wins, and often nobody wrote at all.

The parts are the second exposure, and it is bigger than the labour. A bumper, a headlight assembly, a set of clips, all bought from a supplier in cash, all fitted to a specific car. If the link between a part and a job lives only in a worker's memory, then shrinkage is invisible by construction. The owner cannot tell the difference between a part fitted, a part broken, and a part that walked out of the door, and he will not find out from a monthly total.

The third factor is the workforce itself. Turnover is real, many workers have limited literacy in French and prefer Arabic or Darija, and none of them were hired for their comfort with software. A system that requires reading a dense screen excludes the exact people who hold the information you need. Icons, photos and one tap actions are not a design nicety here, they are the difference between data and no data.

And the disputes have teeth. There is no realistic small claims process for a 35,000 DZD repair. The customer's leverage is his voice in the neighbourhood, the owner's leverage is evidence, and today the owner has none. In a market where trust is scarce and reputational damage is cheap to inflict, the workshop that can open a phone and show a timestamped photo of the car on arrival has an advantage that has nothing to do with paint quality.

The cash on delivery instinct shows up here too. Customers pay at the end, on collection, after inspecting the work. That means your system has to hold an unpaid balance across days and partial payments without ever overwriting what came before. Same rule as any money system: write events, never edit them.

What to actually do 🛠️

Make intake a photo, not a form. The first screen is the camera. Four to six photos of the car on arrival, automatically stamped with time and job. No typing. This single feature pays for the whole system the first time a customer claims a pre existing scratch.

Design the worker screen as buttons, not fields. One job, a short vertical list of milestones, each a single large tap: Received, Stripped, Filled, Primed, Painted, Assembled, Ready. Tapping writes a row. Nothing is editable. If a worker taps the wrong one, he taps the correct one after it, and the timeline shows both, which is exactly what you want to know.

Bind parts to the job at the moment they are fitted. A search field is too slow. Show the parts the shop actually uses as a grid of tiles with photos, tap to attach. If the shop scans anything, a barcode is even better. The goal is that attributing a headlight to a car costs less effort than not attributing it.

Store transitions, never a status column. A job row holds identity. A separate append only table holds everything that happened to it.

create table job_events (
  id         uuid primary key default gen_random_uuid(),
  job_id     uuid not null references jobs(id),
  kind       text not null,          -- received | stripped | primed | painted | ready | part_fitted | payment
  worker_id  uuid references workers(id),
  part_id    uuid references parts(id),
  amount_cents bigint,               -- set on payment events only
  photo_path text,
  note       text,
  created_at timestamptz not null default now()
);

create index on job_events (job_id, created_at);

The current state of a car is the latest event, computed. The history is the whole table. Payments are events in the same timeline, so the outstanding balance is a sum and not a number somebody maintains.

Let the owner see one screen: cars in the shop, and money outstanding. He does not want analytics. He wants to know which cars are here, what stage each is at, and who owes him what. Everything else is decoration.

Make it work in Arabic, right to left, on a cheap Android, offline tolerant. The workshop's connection will drop. Queue writes locally and sync. A logging tool that fails when the signal does is a logging tool that trains people to stop using it.

Never build the Edit button. When the owner asks to correct a payment, insert a correcting event. His notebook already worked this way, with a line crossed out and a new number beside it. You are digitising a habit he already trusts.

TL;DR 🧾

Software for traditional trades fails at the point of capture, not the point of storage. If logging an event costs more than the chalk it replaces, you will get no data. Make it one tap, make it a photo, make it append only, and the dispute that used to cost a repaint costs ten seconds.

LINKEDIN VERSION

A car arrives at an Algerian paint shop with a scratch on the rear door. Four days later the customer points at a mark on the front wing and says it was not there before.

The shop owner pays. He always pays. Not because he is wrong, but because he cannot prove he is right, and arguing with a customer in a neighbourhood where reputation travels fast is a losing trade even when you win.

Developers try to fix this with a job management form. Fourteen fields, properly normalised, deployed, and ignored. A month later the shop is still running on chalk.

That failure is not technical. The man doing tsbiga has paint on his hands and is measured on cars finished per day. A long form is a tax on the only thing he is paid for, so he fills it in at the end of the day from memory, or not at all. Fiction in a dispute is worse than nothing, because it looks authoritative.

Chalk wins because it costs two seconds and never rejects your input.

So the constraint is: capture must be faster than chalk. One thumb, dirty hands, no typing. The camera is the intake form. Milestones are large buttons. Parts are tiles you tap when you fit them.

And store events, never a status column you overwrite. Received 08:12 with photos. Primed 11:05. Painted 14:20. Nothing is editable.

Then the dispute that used to cost a full repaint costs about ten seconds.