Not Everything Is a Collection

Ask a library what software it runs and you will hear about the ILS, the discovery layer, and the digital collections platform. Fair enough — those are the big systems and they cost the most.

Then spend a week watching how the work actually gets done, and you find the other layer. The room booking sheet that lives in a shared calendar with a naming convention only two people understand. The digitization tracker in Excel, on version 14, where column M means something different after row 300. The summer reading sign-up that is a paper form somebody types up in the evening. The interlibrary loan workaround. The equipment lending log.

None of these are collections. None of them fit in Omeka, and none of them are what the ILS is for. They are just the institution's actual work, running on whatever was at hand when someone needed a solution.

Why the spreadsheet stops working

The spreadsheet is not stupid. It was the right call at the time — free, immediate, no procurement. Most of them work fine for years.

They fail in predictable ways. Two people edit at once and one edit vanishes. A formula breaks and nobody notices for a month. The one person who understood the layout retires. Someone needs it from home. Someone needs a report out of it and there is no way to get one that does not involve manual counting. Data that should be private is visible to everyone with the link, because permissions in a spreadsheet are all-or-nothing.

The tell is when people start working around their own tool: a second sheet that fixes the first one, a naming convention doing the job a field should do, a step in the process that exists only because the software cannot do it.

What we build

We build these as proper web applications, on Laravel. The work generally takes one of four shapes.

New applications. Something does not exist and needs to. We start with the workflow and the people doing it, scope the build, then design, build, and launch it. Staff-facing tools and patron-facing ones both.

Features for existing applications. You already have an app — someone built it, maybe years ago, maybe a student worker who has since graduated. It works, mostly, and now it needs to do one more thing. We join a codebase already in flight, add what is missing, shore up what is brittle, and try to leave it better documented than we found it.

Rescue and upgrade. You inherited an application nobody has touched in years. It runs on a PHP version that stopped getting security patches, and everyone is quietly afraid of it. This work is version upgrades, dependency cleanup, and getting the thing maintainable again. It is less glamorous than a new build and often more valuable.

APIs and integrations. Connecting an application to the systems you already run — the ILS, the LMS, a payment processor, a vendor's API. The goal is nearly always the same: eliminate a step where a human moves data between two systems by hand.

Why Laravel

Partly it is what we know well, and there is no point pretending otherwise. But the reason we chose it in the first place holds up.

Laravel is a mature, heavily documented PHP framework with a large working community. That matters for institutional software in a specific way: when you need someone else to work on this in five years, you need a technology they can hire for. Choosing something fashionable and obscure is how an application becomes unmaintainable long before it becomes obsolete.

It also runs comfortably on the kind of infrastructure institutions already have, which is not nothing when the answer to "where will this live" is a server your IT department already manages.

We build and run our own Laravel applications, not only client projects. The practices we bring to your build are the ones we live with every day, including the ones we learned the hard way.

How we work

Discovery first. We start with the workflow and the people doing it. What is the actual task? Who does it, how often, and what makes it slow? What happens when it goes wrong? A good discovery conversation frequently makes a project smaller — someone describes a fifteen-screen system and what they need is three screens and a nightly email. We do not write code until we agree on what it needs to do.

You own the code. The finished application is yours: repository, documentation, no lock-in. If you want to host it yourself, host it yourself. If you want someone else to maintain it later, they can.

Built to be handed over. Related to the above, and the part people forget to ask about. Software you cannot hand to another developer is software with an expiry date. We document as we go and write the boring kind of code that someone else can read.

Is this you?

If there is a process in your building that everyone knows is held together with a spreadsheet and goodwill, it might be. Tell us about it. The first conversation is about the workflow, not the software, and you will come out of it with a clearer description of the problem whoever ends up solving it.