Bronsgieterij Custers

Two pieces of paper

Bronsgieterij Custers has been casting bronze for generations, and the work ran on two physical objects.

The first was the order form: one A4 per commission, carrying the artist, the piece, the edition size, and for each of nine process steps who does it, how much material goes in, how many hours it takes and what it should earn. That sheet travelled through the workshop, got dirty, and was unfindable from the office for as long as it lay on a bench. Prices were worked out on it by hand from a price list that was also on paper and changed occasionally — after which nobody could say which price had belonged to an older commission.

The second was the planning board: a wall of T-cards, one row per casting week. Colour meant something, full weeks were marked, holiday weeks were taped over. It worked perfectly — for whoever was standing in front of it. Anyone at another location, or at home, knew nothing.

The brief was not "digitise this"

It was: make it digital without the workshop having to unlearn anything. A card still has to be a card, in the same colour, in the same week.

That constraint shaped every decision that follows.

What was built

One Dutch-language webapp, running on the tablets already in the workshop:

• Commissions — the paper form field for field, but live: nine process steps that switch themselves on and off, material and hours per step, and a price that calculates from the price list as you type. Photos of the piece, a signature on screen, and a printable version for anyone who still wants paper.
• Work in progress — everything underway, with the full route per piece and "X of Y done" per step. Someone in the workshop taps their progress there, and that is the only thing an employee has to do.
• Casting planner — the T-card board, digital. Weeks side by side, cards you drag, and the same colour language as the wall.
• Calendar — real appointments, for customers who want to be present at the casting or the patination.
• Price list — 59 lines in three categories, kept in versions.
• Administration — staff and PIN codes, customers, locations in the building, casting weeks, and a log of who did what.

Over a thousand customer records were carried across from their accounting export in a single import.

The tablet in the workshop is not a new iPad

The first version looked perfect on the workshop tablet, and not one button did anything.

Next.js builds for modern browsers by default, and the Safari on that iPad simply could not read the JavaScript. The page still renders, because HTML and CSS get through fine. So it fails silently — which is exactly why it took time to find.

The page looked right and not one button did anything. That is the worst kind of bug: it doesn't look like a bug.

The fix is one line pinning the build target to older iOS, with a note above it explaining why it must never be removed. The lasting change is what came after: "does this work on an old Safari?" became a real design question. No <dialog>, no color-mix(), no hidden file inputs. That didn't make the app poorer. It made it simpler.

One colour-blind employee, and a whole colour layer

Halfway through came the news that one of the eight staff is colour-blind. The planning board leans on green and red — precisely the pair that disappears.

The easy way out is a toggle that swaps a few colours. That is not what was built. Every colour that means something became a token, and one block of CSS replaces those tokens as soon as the signed-in employee is set to colour-blind. The board turns blue and dark instead of green and red, and the cards gain a letter mark — because the safest solution is one that doesn't lean on colour alone.

The replacement colours weren't chosen by eye. They were run through a colour-blindness simulation and their contrast checked against the darkest surface they land on, with those numbers left as comments beside each token.

This is accessibility that came from one real colleague rather than a checklist, and the answer was system design rather than a patch.

A price list that remembers its own past

"The price list changes, but we want to remember the history."

One sentence with a great many implications. A commission from March has to keep its March prices even when the hourly rate goes up in September. The answer is copy-on-write: the first change on a new day closes the current list under that date and makes a copy to carry on in. Every commission records which version it points at.

The catch was the identity of a price line. Copy a list and every line gets a new id — and then you no longer know that a given line in version 3 is the same line as in version 2. So each line carries a stable family number alongside its id, one that survives the copies.

Rights that actually stop you

An employee may do exactly two things: record how many of a step are finished, and record where a piece is. They do not see amounts.

Hiding buttons is tidy, but it isn't security. Every server action starts with its own check, and prices are omitted server-side rather than hidden client-side — so they never reach the bundle that goes to the tablet. The rules also fail safe: once a single employee with a PIN exists, a session with nobody selected sees no amounts at all.

The board that broke

Not everything went cleanly. Making the cards roomier meant changing the row height in the JavaScript — but not in the CSS. The client's response was short: "Looks broken. Put it back how it was."

Roll back, start again from one shared grid, and this time check with a screenshot of the whole board instead of measuring individual cards. Both places now carry a warning that those two numbers are one measurement.

Where it stands

Delivered and online, built solo in five weeks — research, design, build and hosting. The workshop's switchover is still to come, so there are no figures on time saved, and there won't be any here until there are.

The interesting part of this project was not the features but the constraints: an old browser that fails silently, a colleague who cannot read colour as information, and a team whose way of working is good and does not need changing. Good software for a craft is software that bends towards the craft, not the other way round.