Why I’m Building a Library System From Scratch

L/30 asks what a library could control if it could inspect and change the software beneath its daily work.

Revised build account

Method and correctionsAsk about the source or send a correction

I’m building a library management system called L/30. I want to find out what changes when a library can inspect the code, understand its data, and choose who maintains the system.

Why

I’ve worked on the vendor side and inside public libraries. A product can work well and still leave the library dependent on someone else’s roadmap, export tools, or willingness to answer a question.

Building lets me test a different arrangement. It also makes the maintenance burden harder to ignore. If I ask a library to trust an alternative, I need to show how it works and where it fails.

What this account describes

This is a development account, not a certification that the system is ready for a library. Earlier versions described it as a synthetic-data sandbox. That description does not verify the data or operations of any current deployment.

The source check for this revision used local repository commit 4d16cfe4d416e220537bcb4c89a08cceb8b6a0fa. The README describes a FastAPI backend using SQLAlchemy, PostgreSQL and Redis, a React/Vite/Tailwind frontend, and Docker-based operations files. This identifies the documented architecture. It does not show a successful checkout, secure deployment, or recoverable backup.

Inspect a workflow, not the size of the repository

The earlier account listed modules and counted endpoints and pages. Those numbers made the scope visible, but they did not tell a librarian whether a task worked.

A circulation module needs more than a route and a screen. Someone has to follow a checkout through its permissions, resulting records, error cases, and recovery. Cataloging needs checks on the records it creates and exchanges. The account should show those observations before calling a workflow reliable.

Decisions I want readers to question

Make the source available for inspection

The checked repository’s LICENSE file contains GNU Affero General Public License version 3. My reason for choosing an open-source license is to let others inspect and change the work. The license text sets the conditions; the earlier paragraph compressed them too far into a promise about preventing proprietary reuse.

Compare search results on actual questions

I want keyword and semantic approaches tested on the same catalog and the same questions. A query about grief after losing a parent is a useful example to try, not proof that keyword search fails or that a vector approach understands the reader. Record the results, missed items, irrelevant matches, and response time.

Keep deployment understandable

Docker Compose is a design choice. It does not remove the need to patch software, manage access, monitor failures, and restore data. A small library needs to know who will do that work.

Prove that records can move

MARC and BIBFRAME support should be demonstrated through actual import, validation, export, and round-trip tests. A data-model choice alone cannot promise that a future migration will disappear.

What surprised me

The scope of a library system is enormous. Circulation and cataloging connect to policies, notices, payments, rooms, equipment, accessibility, and the work staff do when an exception appears.

Every additional module creates something to maintain. Features described as fair, equitable, or resilient need their own observable criteria. An offline mode needs a disconnection test and a reconciliation test. A scheduling rule needs to show what happens when needs conflict.

The next useful test

Choose one workflow another person can repeat. Use a defined test dataset. Complete the task, record the failures, inspect the resulting records, then export and restore them. Publish the inputs and observations so someone else can disagree with the conclusion.

That is a smaller claim than a complete alternative. It is also a claim another library could evaluate.

Source and verification limits

Local repository README and LICENSE checked October 25, 2026 at the commit above. No application workflow, security, performance, or current deployment-data audit was performed for this article revision.

The public URL checked for that exact revision returned 404. Readers therefore do not yet have a verified public link for independent inspection of this source revision. Ask me for source access before relying on it for an independent evaluation.

Disclosure: This is my own project. The build account should make its limits as visible as those of any vendor product I examine.

Read the company trail, then ask what an alternative would have to prove.