Some of the objects in that database were thousands of years old. The code I wrote to catalogue them was, on a good day, a few months old. That gap, between the permanence of the things and the impermanence of the software that held their records, never stopped feeling strange to me, and it quietly changed the way I build.
At a company in Lahore that built collections-management software for museums, I worked on the systems that run the catalogue and the care of objects at institutions like the Metropolitan Museum of Art in New York. A museum, underneath the galleries, is an enormous and meticulous data problem. Every object has a history, a location, a condition, an environment it has to be kept in, and a small library of scholarship attached to it. Our software was where all of that lived.
Caring for Things That Cannot Be Replaced
Preservation in a museum is a physical discipline before it is ever a digital one. Light fades pigment. Humidity warps wood and lifts paint. A few degrees the wrong way can crack something that has survived for millennia. Conservators hold temperature, light, and handling to tolerances most data centres would respect, because the objects are, by definition, irreplaceable. There is no backup of a five-thousand-year-old artefact.
The software sits inside that discipline. It tracks where an object is, the conditions it needs, when it was last examined, what was done to it, and who is responsible for it. A bug in most software is an inconvenience. A bug that loses or corrupts the record of how an irreplaceable object must be stored and handled is a different category of mistake, and you feel that difference in your stomach the first time it occurs to you.
Digitising the Permanent
A large part of the work was digitisation: turning shelves of paper records and decades of institutional memory into something searchable, durable, and shareable. Photographing, cataloguing, attaching metadata, and connecting it all so a curator could find an object and trust what the screen told them about it. It is unglamorous work with a quietly enormous stake, because once the paper is gone or the person who remembered it has retired, the digital record is not a copy of the truth. It is the truth.
I came to think of it less as building features and more as taking custody. We were not adding a catalogue to a museum. We were becoming part of how the museum remembered itself, and that is not a responsibility you can hold casually.
Every Change Left a Shadow
A catalogue is not a photograph. It changes. An object is moved to a new gallery, loaned out, revalued, reattributed after fresh scholarship. And, just as critically, the conditions it lives in change: someone adjusts the temperature of a case, the light level in a room, the humidity in a store. For an object that has survived three thousand years, a careless change to its environment is not a clerical edit. It is a threat. The system had to remember every one of those changes, and who made them.
That is where the audit trail lived, and it was the part of the build I enjoyed most. Instead of scattering logging through the code, we kept history at the data layer: SQL Server change tracking feeding shadow tables, an event-sourced record of who changed which field, when, and from what to what. It was configurable by design – you chose exactly which fields were worth shadowing and how much history to keep – because not everything deserves that weight, but anything that can touch a priceless object does. For all of those, you could always answer the three questions that matter most after something goes wrong: who, when, and what it was before.
Software Curators Could Trust
The system spanned three worlds at once. A Spring backend held the core. An Angular web application opened the catalogue to people working across an institution. And a Visual Basic desktop application still served the deep, specialised workflows that long-time registrars and conservators relied on, the kind of users who know exactly what they need and have no patience for software that gets in their way. Keeping those three in agreement, each evolving at its own pace, was its own steady discipline.
Our users were not engineers. They were curators, registrars, and conservators who thought in decades and treated the catalogue as part of the institution's memory. Earning their trust meant the software had to be correct, legible, and humble. It had to fit the way they already worked rather than demand they reshape themselves around it. That is a harder and more interesting constraint than raw scale, and it taught me to design from the user's world inward, instead of from my architecture outward.
Building for Permanence
The objects taught me a humility I had not quite had before. It is one thing to know, in the abstract, that data should be durable. It is another to be responsible for the digital record of something older than your own country, and to realise that the software you are writing will be replaced several times over while the object, and its record, must persist through every one of those replacements.
I did not have grand words for it then, but that is the instinct I carried out of museums and into everything since: build as though someone will need this long after you and your code are gone. In most software that is a nice aspiration. Among objects that have already outlasted empires, it is simply the job, stated plainly, and it is hard to go back to thinking any smaller once you have done it.