Public Library Management Software: Custom vs Off-the-Shelf

What Koha, Evergreen, Symphony and Polaris actually do well

The vendor landscape here is mature and genuinely capable, which is the first thing worth saying to a director who has been told otherwise.

Koha and Evergreen are open source and both are real systems, not hobby projects. Evergreen was designed from the start around consortial borrowing across many libraries, which matters if that is your shape. SirsiDynix Symphony and Innovative Polaris are established proprietary systems with long institutional histories and support organisations that answer the phone. Ex Libris Alma is a serious platform whose centre of gravity is academic libraries and their acquisitions and electronic resource workflows, which is a different problem from a public library's programming, community services and digital lending mix.

What every one of them carries is accumulated correctness in areas nobody thinks about until they break: MARC 21 record handling and cataloguing rules, authority control, serials prediction patterns, fines and fee policy engines with grace periods and variation by patron type, holds queues, and Z39.50 for record retrieval. Rebuilding that is a multi-year project ending with a worse cataloguing module than the one you already run.

So this is the clearest buy recommendation we publish, and it is advice against our own commercial interest. Nobody should commission a new integrated library system in 2026. The build worth funding is everything the system treats as an afterthought, sitting on top of a core with an open data model and real interfaces, which is exactly what Koha and Evergreen provide.

Where they stop: hold routing, consortium fairness and privacy

A patron at a rural branch places a hold on a popular novel. The consortium owns 41 copies, four are on the shelf, one of them twelve minutes away at the next town. The system routes the request across the state because that copy had been sitting slightly longer in the queue logic, and the patron waits nine days for a book that was down the road. Multiply by a few thousand holds a week and you are paying courier capacity, staff handling and patron patience to solve a problem your software created.

Most systems fill a hold on a simple rule: longest idle copy, or first available in a configured branch order. Neither weighs the things that matter, which are today's courier schedule, queue depth at the owning branch, and where the item will be needed next. Floating collections make it sharper, because items that stay where they are returned will accumulate at one busy branch and empty a small one unless balancing rules exist.

The second gap is the consortium agreement itself, which the software almost never encodes. Who pays when a member's item is lost by another member's patron. How reciprocal borrowing is balanced when one large member lends far more than it borrows. How courier cost is apportioned. How eleven members avoid each buying fifteen copies of the same title while nobody buys the local history. These get settled in committee using spreadsheets assembled by whoever has the skills, which is why the numbers are contested and the meetings are long.

The third is privacy against analytics. Borrowing records carry confidentiality protection under state statute across most of the United States, and professional ethics go further. Your director still needs to know what is being used and by which communities to defend a budget. Most reporting modules were built before anyone thought hard about that tension, and default retention settings in several products keep more than your policy probably intends. Check yours this week.

There is a fourth, and it is the one directors admit to last. Room booking, programme registration, card signup and outreach delivery have usually been solved by four separate services bought at four different times, each holding a partial copy of your patron. Nobody planned that. It accumulated, and it means a resident who registers for a storytime is a different person to your systems than the one who holds a card, which makes any honest picture of who your library serves impossible to assemble.

The arithmetic: cost per hold against the cost to build

Use holds and courier volume as the denominator, since that is where the money physically moves.

A routing and floating layer on top of Koha or Evergreen lands around $100,000. Support and enhancement at 18 percent a year brings five years to roughly $190,000, or $38,000 annually. At 4,000 holds a week, about 208,000 a year, that is close to 18 cents per hold. Set it against what you spend on courier capacity, the staff handling of every item that moves, and the transit days patrons wait.

The crossover sits near 2,500 holds a week, or at any consortium past about eight member libraries. Below that, a single library with two branches and a working ILS should spend the money on materials and staffing, and we say so. Above it, the arithmetic improves every year because holds volume grows and the build does not reprice.

One caution on the savings. Routing improvements come from arithmetic rather than from magic, and the honest measure is items in transit and days to fill, not a percentage somebody quotes you. Establish both figures before the project starts, because you will not be able to reconstruct them afterwards.

What a custom library layer actually costs

Across the projects Digital Heroes has delivered, a first release runs $60,000 to $140,000 in 12 to 16 weeks, covering hold routing, floating rules and privacy safe analytics on top of Koha or Evergreen. Extending to delivery logistics, a discovery front end, room and event booking and consortium settlement brings the programme to $160,000 to $380,000 across 6 to 12 months.

A migration from a proprietary system to an open source one is a separate project with its own budget, dominated by bibliographic cleanup, authority reconciliation and patron record migration rather than by software. Scope it separately and do not let anyone bundle it into an optimistic number. Where it belongs in your plan, data migration runs 10 to 25 percent of the associated build cost. Year two onward runs 15 to 20 percent of build cost annually, mostly integration upkeep, since self check vendors and digital lending platforms change interfaces on their own schedule.

What raises the number: the count of members in a consortium, because each has policies and each has an opinion. Self check and radio frequency identification hardware variety across branches. Municipal finance integration, which is usually a longer conversation than a build. And any requirement to preserve historical circulation statistics through a migration, which conflicts with retention policy and needs a board decision before an engineer touches it.

Four situations where building above the ILS wins

Regulatory fit. Your state confidentiality statute and your retention policy prevent you from answering questions your board keeps asking. The engineering answer is to separate the operational record from the analytical one, writing de-identified aggregates at transaction time and discarding the linkage on return, so you can report which neighbourhoods are underserved for early literacy materials without holding a record of who borrowed what.

Scale economics. Above roughly 2,500 holds a week, or across eight or more member libraries, the fixed cost divides down below what routing inefficiency already costs you in courier tonnage and staff handling.

A workflow that is your advantage. Consortium settlement is the one nobody sells. Computing net lending balance, loss and damage liability and courier apportionment from circulation data, published where every member can see it, changes the character of those committee meetings. It is unglamorous software and it is what keeps a consortium together.

Integration sprawl. Count them: self check units and radio frequency identification pads speaking SIP2, inter-system circulation over NCIP, digital lending through OverDrive and Libby plus Hoopla with its own patron authentication and usage data your circulation reports never see, public computer and print management, the courier manifest, and room booking. Once four systems each hold a partial copy of your patron, unifying identity is the product.

How to decide in a week

Sample fifty filled holds from last month and answer one question for each: was it filled by the nearest available copy that could have caught the next courier run. Record the transit days and the distance. Fifty is enough. If more than a fifth were filled badly, you have a routing problem with a measurable cost and the case writes itself.

Second, ask your systems librarian to produce one report your director actually wants, such as usage by format and neighbourhood for the last quarter, and watch what happens. If the answer requires either a privacy compromise or a manual assembly from four exports, that gap is a build rather than a training issue.

Third, check your retention settings today. Find out how long borrowing linkage is kept after an item is returned and compare it to your written policy. Directors are regularly surprised, and it is a ten minute check.

Then commission a paid discovery phase of two to four weeks that ends with a signed product requirements document covering the routing model, floating and balancing rules, the analytics boundary, the integration inventory and a fixed price. Digital Heroes writes it before any code and the library keeps it whoever builds. Settle code ownership in the same document, including what gets contributed back upstream if the work extends an open source system, because in a sector built on shared infrastructure that is usually the right instinct as well as the generous one. We are the wrong firm if you want somebody in your building weekly, since we have no local office anywhere.

Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.