Case 03 — Records Archive Dashboard

Records Archive Dashboard — Replacing Scattered Files with One System

The Problem

During my military service I was assigned as an archivist. The unit's records lived in Word documents, Excel sheets, and an Access database, scattered across the machine with no relationships between them. A record in one file had no link to the related record in another. Finding an answer meant knowing, from experience, which files to open and in what order.

That knowledge lived in people, not in the system. Every newcomer had to be taught by an experienced archivist how to search, where to look, and how to be confident that what they found was complete and correct. That teaching was real work, repeated with every rotation, and it fell on the people who already had the most to do. The archive worked, but only because a few individuals held the map in their heads.

Nobody had asked me to fix this. I was not satisfied with it, so I proposed a single system to replace the scattered files, and I got the go-ahead.

My Approach

Since my duties left me no time to build it myself, my job was to define the system clearly, make the decisions that shaped it, and make sure the result worked for the people who would use it.

We started with a meeting. I sat down with a fellow conscript who was also a software developer, laid out the mess as I saw it from the archivist's seat, and we discussed how to build something better. I was the decision maker: I took that discussion and turned it into the scope of the first version, cutting anything that did not solve the core problem of scattered, unrelated data.

He did the build. I directed the direction, not the daily work: the core technical decisions were mine, and the implementation was his. He used Laravel with Livewire, which kept it to one framework with server-rendered screens and no separate frontend, and a codebase that a future conscript could maintain. Meilisearch handled search, because lookup was the whole point of the system: it is typo-tolerant, which matters when record names were entered inconsistently over years; it is fast; and it handles Arabic full-text search properly, which the database alone would not. The rejected option was keeping Access as the backend and putting a new interface on it, which would have preserved the disconnected data instead of replacing it.

My review method was deliberately not technical. When the developer finished a module, I had a non-technical colleague sit with the dashboard and use it without guidance. I noted everything he said: where he hesitated, what he misread, what he expected to find and could not. Those notes went back to the developer as the change list. The people who would live with this system were archivists, not engineers, so an archivist's confusion was the only test that mattered.

Challenges

The first challenge was the environment. We had no internet access on site, so nothing about the build was the way I would normally do it: no quick lookup of documentation, no package installs on demand, no cloud services. Dependencies had to be planned in advance. We kept a list of every package we needed, and whenever one of us was on leave with internet access, we downloaded them, carried them in on a flash drive, scanned the drive for malware, and copied them onto the development machine. A missing dependency did not cost minutes; it cost a wait until the next leave.

The second was time. This was a personal initiative on top of my actual duties, not an assignment with hours carved out for it. Every review session and every decision had to fit around the work I was there to do.

The third was migration, and it was the hardest. The old data had no relationships, so moving it into a structured system meant establishing those relationships by hand, record by record. We did what we could. When my service ended, the migration was still in progress.

What Was Shipped

I need to be precise about what I can claim. I initiated the project, defined its scope, made the technical decisions that set its direction, and ran the testing on each module as it was delivered. I did not see the final product in daily use; my service ended while the data was still being migrated.

What I did see was the testing phase, and it was already a different way of working. A colleague with no training on the old files could sit down, search, and find related records together instead of opening three files and reconciling them. The knowledge that used to live in experienced people's heads was starting to live in the system. Compared with the previous way of working, the results were much better, and that was visible before the migration was complete.

What I'd Do Differently

I would not change the approach. The scope was right for the problem, and testing with a non-technical user caught more than a technical review would have. I was happy with the progress we made.

What I cannot do is give a full post-mortem, because I left before the system was finished. I know how the first version tested; I do not know how it held up after a year of real use, whether the migration was completed, or what the next archivist wished had been different. That is the honest limit of this case study.