An application that knows which copy is out, and since when

Overdue is written nowhere

Most small libraries keep their loans in a notebook or a folder: one line per loan, a date, a name. It is perfectly accurate the moment it is written. The trouble comes afterwards: a loan is not a fact that stays true, it is a state that changes on its own. Nobody goes back to the line on the day the return was due — the item is overdue, and that is written nowhere.

In practice, the list of overdue books only exists if somebody rebuilds it by hand, reading weeks of lines one at a time with a calendar beside them. Nobody has time for that, so it happens once or twice a year, when a title turns out to be missing.

An application re-reads nothing: it compares a due date to today's date, and the overdue screen fills itself. It is not a spectacular feature, it is simply the calculation the notebook cannot do.

A title and a copy are not the same thing

This is the distinction that decides the shape of the application, and the one library spreadsheets almost always miss: a title is a reference — a name, an author, an ISBN, a category — while a copy is a physical object, with its shelf mark, its condition and its own history. A library often owns three copies of the same novel; two are out, one is on the shelf.

As long as both live on the same line, you cannot lend two copies at once, cannot record that one of them is damaged, and cannot say whether the title is actually available. Separate them and every question becomes simple again: a loan is on a copy, a reservation is on a title, and availability follows from the two.

You describe this in your own words, and the plan shown to you before anything is built reveals how it was understood. If it merges the two, you correct it then — not afterwards.

• Titles: name, author, ISBN, category, year
• Copies: shelf mark, condition, date added, parent title
• Loans: copy, member, date out, due date, date returned
• Members: contact details, join date, subscription
• Opening shifts: slots, volunteers on duty

How the application is produced

You describe what your library does, in your own words. A plan is shown to you before anything is built: the entities kept, their fields, the screens, the indicators. You correct it until it matches how you actually work; nothing is built before you approve it.

The result is a standard Next.js and Prisma project. You can download it as a ZIP archive or push it to GitHub: the code is yours, and any developer can pick it up. Three generation levels exist (Sketch, Craft, Masterpiece), depending on whether you are testing an idea or want a finished application.

What the application is NOT

This page describes an internal tracking tool. Several reasonable expectations of a library fall outside what the product does, and it is better to know before you start than after:

None of these limits is permanent as far as the code goes — the project is exportable and a developer can extend it — but none is provided out of the box.

• The catalogue does not fill itself from an ISBN: no external bibliographic database is queried, titles and authors are typed in. The ISBN field is an identifier and a search key, not an import key.
• No barcode scanners or RFID tags: loans and returns are recorded on screen.
• No automatic reminders by email or text message: overdue loans appear in the application, contacting the member stays a human action.
• No public catalogue and no reader account: a member given read-only access sees the whole application, not only their own loans.
• No offline mode: an opening shift without a network connection will not allow live data entry.
• Permissions are global (administrator, user, read-only) — no per-section or per-branch rights.

What you get back, whenever you want it

The data you enter stays yours and can be retrieved from the Settings screen, as JSON or CSV, one dataset at a time. A catalogue exported as CSV opens in a spreadsheet, can be sorted, printed for a stocktake, and attached to an annual report or a grant application.

Lists can be filtered and sorted, and a trash bin lets you restore a row deleted by mistake — useful when data entry rotates between volunteers who only take a shift once a month.