2025

Zero Update: routing around the IT department through architecture and compliance-as-code

Escaping technical debt and slow B2B deployment by designing hybrid software that builds the legal standards directly into the code.

In an industrial B2B setting, the constraint that decides a piece of software's fate is not functional, it is administrative: every update goes through the customer's IT department, and every pass through costs weeks. The old version required an installer for each fix, which put our delivery pace at the mercy of a department for which it was not a priority. The rebuild was designed around that constraint rather than against it.

Préventimark

Director of Operations - Creative Manager

Product development (physical and digital), Product & User Experience

An architecture cut in two

The solution we settled on separates responsibilities strictly. A thick client, written in React and Node wrapped in Electron, handles everything that requires access to the machine: the print drivers and the local resources. It is designed never to move again. Everything else, meaning the features, is served from a remote front end. That product split is what we call "Zero Update": the software's intelligence evolves online, with no installer and no ticket raised with the IT department.

The proof is in the pace

An architecture of this kind is not judged on its diagram but on what it allows afterwards. Since going live, eighteen features have been delivered to users online with no friction and no IT involvement on the customer side. The product is currently at version 4.2.3, and 4.3.0, now in preparation, adds two new printers. A local version remains available for environments where outbound connections are refused, a frequent case that it would have been careless to treat as marginal.

From file to component

The old version rested on 4,500 label templates maintained one by one, which ruled out any change made across the board: correcting a regulatory statement meant reopening every file concerned. We broke those templates down into reusable components, assembled on demand. The code base dedicated to template creation shrank by roughly 60 % in volume, measured on source size.

The standard written into the code

The business constraints, applicable standards, mandatory pictograms and legal statements were translated into logic classes that validate and calibrate the label before it is sent to the print engine. Modeling the rule in the code rather than restating it in documentation moves the compliance burden from the operator to the software. The label is built on the fly by combining what the user needs with the consumable actually loaded, which makes the notion of a fixed catalog obsolete.

A double expertise nobody should have to combine

Producing a safety signage label calls for two unrelated skills: composing a legible document, and knowing the applicable standards. Expecting both from an operator amounts to asking them to be a graphic designer and a regulatory specialist at once. So the software carries those two areas of expertise and guides the editing, instead of leaving it to the user's own judgment.

Internally we talk about "three clicks". It is an image, not a measurement, and a complex label will take more. It does describe the direction accurately: take out of the flow the choices that do not belong to the operator, and automate the settings they have no reason to know about.

A display that follows actual use

The old interface was frozen at a desktop resolution. The rebuild introduced a responsive display because the software gets opened on a tablet during maintenance as readily as on a 13-inch laptop or a control station. The point seems secondary until you observe where the tool is actually used.

Improving without disorienting

The old interface was austere and hard to approach, which produced friction from the very first launch. The graphic treatment was chosen to reduce that friction, and for nothing else. The constraint came from the users themselves: an installed base used to the earlier versions, whose bearings would have collapsed had we rethought the interface from top to bottom.

So I ruled out the full visual redesign, which would have been more satisfying to design and more expensive to absorb for the people who use the tool every day. Simplification was done in stages, keeping the landmarks that structure the screen. A gain in usability is only worth having if it is not paid for in disorientation.