Academic Library Services Platform Development: Why Does the Article Your Catalogue Promised Land on a Paywall?

Why the library system fails at the moment a researcher needs it

A doctoral student finds a 2019 article in a discovery search at 11pm. The catalogue shows full text available. She clicks, passes through the proxy, and lands on a publisher page asking for $42. The library does hold that journal, but only from 2021 forward, because the package changed at renewal and the knowledge base still carries the old coverage dates. She does not report it. She uses a different route to the article and quietly concludes the library website does not work.

That failure is invisible by design. The only people who see it are users, and users do not file tickets, they route around. Meanwhile the library is paying for content that is genuinely licensed and genuinely unreachable, which is the most expensive possible failure mode for a collections budget.

The stack is Ex Libris Alma with Primo, or FOLIO with a discovery layer, or Koha, or OCLC WorldShare, or a SirsiDynix estate, plus EZproxy or OpenAthens for authentication, a link resolver reading a vendor maintained knowledge base, ILLiad or Tipasa for interlibrary loan, a repository like DSpace or Hyrax, reserves in Ares or Leganto, and a spreadsheet of licence terms that a licensing librarian maintains because the terms live in signed PDFs. Every one of those systems is competent. The failure is at the joins, and the joins are where a library's actual local practice lives.

In the library projects we have delivered, the recurring pattern is a small number of expensive gaps rather than one broken system: holdings that do not match entitlements, licence terms nobody can query, consortial rules that no vendor configuration expresses, and fiscal year end reconciliation done by hand. Our honest position on this category, before anything else: you should almost never build a replacement library services platform. You should build the pieces around one.

Problem 1: your knowledge base is a vendor's approximation of what you bought

Coverage in a knowledge base comes from packages maintained centrally by a vendor, and it is generally good and never exact for your institution. Title transfers between publishers mid year. A package swaps titles at renewal. You hold perpetual access to a backfile that the current package does not include, and nothing in the knowledge base knows about your post cancellation rights.

Alma and FOLIO both consume knowledge base data competently, and the vendors maintain it seriously. The gap is not their diligence, it is that the source of truth for what you own is your licence and your entitlement files, not their package definition. Nobody reconciles the two because it is a data job across formats nobody has time for.

What a custom build does: ingest what you actually receive, meaning KBART title lists from each provider, your perpetual access records, and your own local holdings, then reconcile them against the knowledge base and produce an exception list. The output is a weekly worklist for your electronic resources librarian showing where the resolver believes something different from your entitlement. That is not a glamorous product and it is the highest return work in this category. Pair it with a link failure loop: capture resolver outcomes, detect the pattern where users click through and immediately return, and turn silent failures into a queue. You cannot fix what nobody reports, and users will not report.

Problem 2: licence terms are in signed PDFs and every decision needs them

Can this journal be used for interlibrary lending. Can this ebook go on course reserve. Does walk in access cover the public. Do you have post cancellation rights on this backfile and for which years. Is text and data mining permitted. Every one of those questions has an answer in a signed agreement, and staff answer them from memory or by opening a PDF and reading.

Electronic resource management modules exist in both Alma and FOLIO and they can hold structured terms. The reason so many libraries do not use them well is that entering terms is slow and the benefit is not visible until an ILL request arrives at 4pm. So the fields sit empty and the knowledge stays with the licensing librarian.

What a custom build does: two things. First, make the terms operational rather than reference, so the ILL system asks the licence at request time and returns a decision with the clause attached, and the reserves workflow does the same. When a decision is a byproduct of a system rather than a lookup, the data gets maintained. Second, this is where a language model earns its place in a library: run extraction over your signed agreement PDFs to draft the structured terms, with the extracted clause quoted beside each field and a human librarian confirming. Extraction is a first pass, not an authority, and the design should make that explicit. But turning a filing cabinet of agreements into a reviewable queue is the difference between having the data in three years and never having it.

Problem 3: consortial rules exist in agreements and no vendor configuration covers them

Reciprocal borrowing with a partner group where their patrons get local privileges but different loan periods. A shared print agreement where your institution has committed to retain specific titles for a defined period and cannot deselect them. A consortial purchase where cost share is calculated by full time equivalent and access is granted at a group level while entitlement is recorded individually. Patron driven acquisition where a trigger at one member institution creates a purchase obligation across the group.

Alma supports network zones and FOLIO supports consortial patterns, and both are real capabilities. The wall is that your consortium's agreement was negotiated by people, contains rules that were never designed for expression in software, and changes when the agreement is renegotiated. Every consortium we have worked with has at least one rule that exists nowhere but in the memory of the group's operations manager.

What a custom build does: express the agreement as rules in one place, alongside the shared print retention commitments, so a deselection proposal is checked against retention obligations automatically before anyone withdraws a volume that your group promised to keep. Interlending decisions consult reciprocity rules and licence terms in the same call. Cost share allocation is computed from stored formula and membership data, which turns the annual invoice argument into a report. This is the work that is genuinely uneconomic for a vendor to build, because it is one consortium's agreement, and that is exactly why it is a good custom build.

Problem 4: acquisitions and the fiscal year end are a reconciliation you do by hand

Funds are encumbered when you order, expended when you pay, and the difference matters intensely in the last six weeks of a fiscal year when a library is trying to spend precisely to its allocation. Vendor invoices arrive by EDIFACT from suppliers like GOBI or EBSCO, in currencies that moved since the order, with service charges that do not map to your fund structure, and your institution's finance system has its own view of the same money.

The acquisitions modules do encumbrance properly. The gap is between the library ledger and the institutional ledger, plus the multi year prepayments and the mid year package amendments that arrive as a credit note nobody can allocate.

What a custom build does: reconcile the library ledger against the institutional finance system continuously rather than at year end, with a difference report that names the cause. Model multi year agreements with the payment schedule and the amortisation your controller expects. Handle currency at both order and payment with the variance recorded rather than absorbed. For patron driven and evidence based acquisition, project committed spend from trigger rates so your collections budget manager knows in March what the demand driven programme will cost by June, rather than finding out. That projection is the feature collection managers ask for most and the one no standard module provides.

Problem 5: migration is the project, and local practice is what makes it hard

Any move, whether Voyager or Millennium to Alma, Alma to FOLIO, or a consortial migration where twelve libraries move together, is dominated by data. Your MARC records carry local practice going back decades: a 590 note that means something specific to your institution, item types that encode circulation policy, location codes that reference a building demolished in 2008, and serials holdings statements written in a style one cataloguer used.

What a custom build does in this context is not replace the platform, it is de risk the move. Profile the existing data and report on it honestly, so the library learns before cutover which records will not map. Write the transformation rules as tested code rather than as a vendor spreadsheet, so a rule change re-runs in minutes. Reconcile after load, comparing counts and samples by material type and location, because the failure mode in migrations is not a crash, it is a quiet loss of a category of records nobody checked. And keep a queryable copy of the legacy data for two years, because someone will ask a question the new system cannot answer. FOLIO deserves a specific note here: as an open platform it is the one case where building modules rather than around them is genuinely sensible, and a library with unusual workflows and some development capacity can get further with FOLIO plus custom modules than with any configuration of a closed product.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release, meaning entitlement and holdings reconciliation with an exception worklist, structured licence terms with extraction assisted entry, and a link failure detection loop, runs $90,000 to $200,000 and ships in 14 to 20 weeks. A larger programme adding consortial borrowing and shared print retention logic, fund encumbrance reconciliation against institutional finance, demand driven acquisition spend projection, reserves and repository integration, and custom FOLIO modules where that is the platform, runs $250,000 to $600,000 phased over 9 to 18 months. Migration support is scoped separately and depends almost entirely on the state of your legacy data.

What drives price up specifically in libraries: consortium size, because each member institution brings its own policies and its own opinions. The number of content providers whose files you must ingest, since KBART, COUNTER 5 and SUSHI are standards that providers implement with real variation. Authentication estate, because EZproxy configuration and an OpenAthens or SAML migration is its own workstream. The age and idiosyncrasy of your bibliographic data. And whether you need repository and research information integration, which pulls in ORCID, DOI registration and sometimes a research data management workflow.

What keeps price down: starting with entitlement reconciliation and link failure detection alone. Those two touch nothing else, deliver visible value in the first month, and give you evidence for the larger business case.

Build versus buy, and when buying is the right call

Buy, and we will be direct: do not build a library services platform. A single campus library under roughly $500,000 in collections spend should run Koha or OCLC WorldShare and put the difference into content and staff. Alma is a strong product and for many institutions the right centre of the stack. FOLIO is a genuine alternative when you have or can hire technical capacity, and Koha remains excellent value for straightforward operations.

Build, meaning build around the platform, when two or more of these hold. Your link resolution failures are known to be significant and nobody owns the reconciliation. Your consortium has rules that no vendor configuration expresses and your operations manager is the only person who knows them. Your licence terms are unqueryable and staff are making interlending and reserves decisions from memory. Your fiscal year end reconciliation with institutional finance takes weeks. Or you are on FOLIO and have identified specific workflows where a custom module is cheaper than the workaround you are living with.

Our position: this category rewards precision and punishes ambition. The libraries that get value from custom development build three or four specific things and leave the platform alone. The ones that get hurt try to replace something a vendor spent fifteen years on.

How to choose a developer for academic library software

Ask them what KBART, COUNTER 5 and SUSHI are before you explain them. A developer who has worked in this domain will start talking about how inconsistently providers implement all three, which is precisely the problem you are hiring them to absorb. One who has not will treat file ingestion as trivial and be surprised for four months.

Ask how they would prove a link resolution failure exists. If the answer is that users will report it, they do not understand that silent failure is the defining characteristic of this problem and the whole point is detection.

Ask what they have done with MARC and with your ILS specifically. Alma APIs, FOLIO modules built in its own framework, Koha plugins and SirsiDynix integrations are four different bodies of knowledge, and the one that matters is the one you run. Ask for the platform and the interface, not a claim about experience with libraries.

Ask who owns the code, in writing, before kickoff. You should own the repository, the cloud accounts and the right to hire another firm, and for FOLIO work you should also agree upfront what goes back to the community. At Digital Heroes the client owns the code from the first commit. Libraries have long institutional memories and short vendor relationships, and your local logic should outlive both.