Academic Library Software: Build Around the Platform, or Buy and Configure?
The threshold here is collections spend. Under roughly $500,000 a year, buy: Koha or OCLC WorldShare will run your operation properly and a build is an expensive way to reproduce them.
On this page
The threshold here is collections spend. Under roughly $500,000 a year, buy: Koha or OCLC WorldShare will run your operation properly and a build is an expensive way to reproduce them. Above roughly $2M a year, and especially inside a consortium, the question is not whether to buy a platform, because you should, but whether to build the reconciliation layer beside it. Most academic libraries sit below the build line on the platform and above it on the joins, which is why the honest answer for the majority is buy the platform and build three or four precise things next to it.
When is off the shelf genuinely the right call here?
For most single campus libraries it is the only sensible call. If your collections spend is under roughly $500,000 a year, Koha or OCLC WorldShare will run cataloguing, circulation and acquisitions properly, and the money you would spend on a build belongs in content and staff instead.
The stronger version of that advice applies at every size: do not build a library services platform. Ex Libris Alma with Primo represents many years of work on cataloguing, circulation, acquisitions and discovery, and for a large number of institutions it is the right centre of the stack. FOLIO is a serious open alternative when you have or can hire technical capacity. Koha remains excellent value for straightforward operations, and a SirsiDynix estate is usually still doing the job it was bought to do. Rebuilding any of them is a poor use of institutional money and a worse use of institutional attention.
Buy and stop, too, when your pain is discovery presentation rather than data. If users complain that the search box is ugly or the mobile view is awkward, that is a configuration and theming exercise inside Primo or your FOLIO discovery layer, not a development project, and treating it as one is how libraries end up with an expensive skin over the same problem.
The libraries that should buy and read no further are the ones whose electronic resources are simple: a modest number of content providers, one campus, no consortial obligation beyond a shared catalogue, and a licence archive somebody can still read. At that shape the gaps described below are annoyances rather than costs, and a custom project would be an expensive answer to a problem you do not yet have.
When does a custom build actually pay off?
The build case in this category is never the platform. It is the joins, and it turns on whether the reasoning around your collections has outgrown what a vendor configuration can express.
Two or more of the following usually settle it. Your link resolver sends users to paywalls for content you have licensed, and nobody owns the reconciliation between your entitlements and the vendor knowledge base. Your consortium has borrowing, cost share or shared print retention rules that live in a negotiated agreement and in the operations manager's memory, and nowhere else. Your licence terms sit in signed PDFs, so interlending and reserves decisions get made from recollection. Your fiscal year end reconciliation between the library ledger and the institutional finance system takes weeks of somebody's life. Or you run FOLIO and have identified specific workflows where a custom module is cheaper than the workaround you are living with.
The financial argument that tends to land is the resolver one. Licensed content that users cannot reach is money you have already spent, denominated in the same currency as your collections budget, and it becomes measurable as soon as you capture resolver outcomes for a quarter. We will not offer an industry percentage for how much licensed content is unreachable, because it varies enormously by institution and any average would mislead you. Measure your own.
The tipping point is not size on its own. It is the moment when the local logic around an order, a loan or a licence has become more complicated than the transaction itself. At that point the platform is a front door on a building whose rooms you are staffing by hand.
How do they compare on the things that matter in this industry?
A feature grid is not much use here, because the platforms all do the core work competently. The comparison worth making is about where each approach reaches its ceiling.
- Knowledge base accuracy. Alma and FOLIO both consume vendor knowledge base data well, and the vendors maintain it seriously. Neither can know about your perpetual access rights or a title transfer that happened mid year, because the source of truth is your licence and your entitlement files. Reconciling the two is not something anybody sells.
- Licence terms. Both platforms carry electronic resource management fields that can hold structured terms. The ceiling is behavioural rather than technical: entering terms is slow and the benefit only shows up when an interlibrary loan request arrives at 4pm, so the fields stay empty. A build makes terms operational, queried at request time, which is what keeps them maintained.
- Consortial rules. Alma network zones and FOLIO consortial patterns are real capabilities and they express common shapes well. They do not express one consortium's negotiated agreement, and no vendor has an economic reason to build for a single group.
- Fund encumbrance. The acquisitions modules handle encumbrance properly. The gap sits between the library ledger and the institutional finance system, plus multi year prepayments and mid year credit notes nobody can allocate.
- Reporting rigidity. Standard analytics answer standard questions. Projecting demand driven acquisition spend, which is the report collections managers ask for most, is not one of them.
- Data portability. FOLIO and Koha give you direct database access. Closed platforms give you an export and an application programming interface, which is workable and does shape what you can build on top.
What does total cost of ownership look like at your scale?
Take the platform subscription out of the comparison first, because you are keeping it either way. What a build competes with is the manual work around it.
In Digital Heroes delivery experience, a first release covering entitlement and holdings reconciliation with a weekly exception worklist, structured licence terms with extraction assisted entry, and a link failure detection loop runs $90,000 to $200,000 over 14 to 20 weeks. A full 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 FOLIO is the platform, runs $250,000 to $600,000 phased over 9 to 18 months.
Running costs are modest by the standards of most software categories, because the data volumes are small and the traffic is staff traffic rather than public traffic. Hosting typically sits at $400 to $1,200 a month for a single institution, with a consortium serving member scoped access at the upper end. Support and enhancement usually runs 12 to 18 percent of build cost a year, and most of the enhancement half goes on new consortial rules and new provider handling rather than on anything you would recognise as a feature request.
The standing line nobody quotes is provider file drift. Title lists change shape, a provider changes how it expresses coverage dates, a new package arrives with a different identifier convention. That is a few hours a month rather than a project, it never reaches zero, and it should be somebody's job rather than nobody's. If you run FOLIO modules, add the effort of keeping them aligned with each community release.
What does the hybrid look like, and when is it the honest answer?
For most libraries above the buy line the hybrid is the answer rather than a compromise. Keep Alma, FOLIO, Koha or WorldShare as the system of record, and build the thin layer that reconciles what you licensed against what the resolver believes.
There is a narrower opening move worth knowing about. Link failure detection on its own, meaning outcome capture at the resolver plus a queue of suspected failures ranked by how many users hit them, runs $30,000 to $55,000 over six to eight weeks. It fixes nothing. It proves with your own numbers that licensed content is unreachable, which is usually what a director needs before asking for a larger budget. Entitlement reconciliation as a standalone piece, ingesting your provider title lists and perpetual access records and producing a ranked weekly worklist, sits at roughly $60,000 to $90,000 over eight to twelve weeks.
Both touch nothing else in your estate, and that is the property that makes the hybrid safe. If the layer stops earning its place you switch it off and the library keeps running, which is not true of a replacement.
FOLIO deserves a specific note. It is the one case in this category where building inside the platform beats building beside it, because the module architecture is designed for extension and a library with unusual workflows can go further than any configuration of a closed product allows. The trade is operational: you take on hosting, upgrades and release alignment, which is staff time from the start rather than a one time build cost.
Which should you choose, by operator size and stage?
Under roughly $500,000 in annual collections spend, single campus: buy Koha or OCLC WorldShare, configure them properly, and put the difference into content and staff. Very little in this guide applies to you yet.
Between roughly $500,000 and $2M, single campus: buy the platform and stay there, with one exception. If you already suspect your resolver is wrong, spend six to eight weeks measuring it. The measurement is cheap, and it either settles the question or hands you a number your provost will act on.
Above roughly $2M, research or consortial: buy the platform, then build beside it. Start with entitlement reconciliation and link failure detection, in that order, and keep migration out of the first release. Data migration is its own project with its own risk profile, and bundling it in means the build inherits the migration timeline.
A consortium of any size: run the first release at one member institution. The rules you uncover there are the rules you would otherwise uncover twelve separate times, and the second institution is far cheaper than the first. The agreement work is what scales steeply, not the engineering, because every rule has to be pinned down by people who do not report to each other.
On FOLIO with technical capacity: build modules only where you have identified a specific workflow whose workaround is costing you. The libraries that get value from custom development in this category build three or four precise things and leave the platform alone. The ones that get hurt try to replace something a vendor has been refining for fifteen years.
If you would rather someone argued with your brief than agreed with it, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Standish's 2015 CHAOS research found roughly a third of software projects (about 36% by the Modern definition) fully succeed on time, on budget, and on scope, with top success drivers including executive support, user involvement, and clear requirements/business objectives. Source: Standish Group (CHAOS Report) (2015) →
- In the Flexera 2025 State of ITAM report, respondents reported roughly 33% of SaaS spend is wasted, underscoring how paying for off-the-shelf seats and tiers that go unused erodes the supposed cost advantage of generic SaaS. Source: Flexera (2025) →
- 88% of organizations are concerned about employee retention, and providing learning opportunities is respondents' #1 retention strategy; career progress is cited as people's top motivation to learn, yet only 36% of organizations qualify as 'career development champions.'. Source: LinkedIn Learning (2025) →
- Median SaaS spend reached $9,455 per employee, and organizations leave an average of 36% of their SaaS licenses unused. Source: Zylo (2026) →
Frequently asked questions
What does it cost to move off Alma or Koha later if we build a layer on top?
Less than most libraries fear, provided the layer stores its own data rather than treating the platform as its database. Entitlement records, licence terms, consortial rules and resolver outcome history should live in a store you own, with the platform integration confined to a small adapter that reads holdings and writes back where needed.
Structured that way, a platform migration means rewriting the adapter, not the layer. The expensive part of any move remains the bibliographic and holdings data itself, and that cost exists whether or not you have built anything alongside.
What happens if our platform vendor changes its pricing at renewal?
The layer does not protect you from a subscription increase, and nobody should sell it to you on that basis. What it does change is the credibility of your alternative, because the local logic that usually makes migration unthinkable, meaning consortial rules, licence terms and entitlement reconciliation, is already outside the platform in a form you can carry.
That is worth having as bargaining power at renewal, but treat it as a side effect. The case for the build has to stand on unreachable content and staff time, not on a negotiation you may never need.
How long before a custom library layer is doing anything useful?
Six to eight weeks for link failure detection, which produces a triage queue you can work immediately even though it fixes nothing on its own. Eight to twelve weeks for standalone entitlement reconciliation, which produces a weekly exception worklist your electronic resources librarian can act on from the first Monday.
The full first release lands in 14 to 20 weeks. Insist on seeing the worklist early even when it is ugly, because staff feedback on how it ranks discrepancies changes the design more than any specification will.
Is FOLIO cheaper than Alma once we count the custom work?
Not automatically, and the comparison is more about fit than price. FOLIO removes the subscription and replaces it with staff time: hosting, upgrades, community release alignment and whatever modules you build. For a library with technical capacity and genuinely unusual workflows that trade is often worth making, because module level extension is possible in a way it is not on a closed platform.
For a library without that capacity, Alma with a small custom layer beside it is usually the cheaper and calmer route, and the money saved on operations pays for the layer.
Should we build our own library services platform?
No. This is the clearest buy answer in the whole category. Cataloguing, circulation, acquisitions and discovery have absorbed many years of development at Ex Libris, in the FOLIO community, at Koha and at OCLC, and reproducing that is a poor use of money and attention.
Everything worth building in academic libraries sits around the platform: reconciliation, licence terms as operational data, consortial rules and finance reconciliation. Libraries that build three or four precise things get value, and libraries that attempt replacement do not.
Can we buy something that fixes link resolution instead of building it?
Not completely, because the fix depends on data only you hold. Vendors maintain the knowledge base seriously and it is generally good, but it cannot know about your perpetual access rights, a title transfer mid year or a package that swapped titles at renewal, since the source of truth for those is your licence and your entitlement files.
What you can buy is better knowledge base maintenance. What nobody can sell you is the comparison between your entitlements and what the resolver believes, and that comparison is where the paywall failures come from.
We are a consortium. Does that change the build or buy answer?
It strengthens the build case and changes the sequencing. Consortial borrowing privileges, cost share formulas and shared print retention commitments are exactly the rules no vendor has an economic reason to express, because they belong to one group.
The sequencing advice is firm: run the first release at a single member institution before generalising. Engineering scales gently with membership and the agreement work scales steeply, because every rule has to be settled by people who do not report to each other. Discovering that once is much cheaper than discovering it twelve times.
What is the smallest useful build, and what does it prove?
Around $30,000 to $55,000 over six to eight weeks for resolver outcome capture and a ranked queue of suspected failures. It repairs nothing, and that is the point: it converts a suspicion into a measured number attached to specific packages you are already paying for.
Be sceptical of anything cheaper that claims to solve link resolution without ingesting your own provider files. The gap between what you licensed and what the knowledge base carries can only be found by comparing the two, and there is no shortcut around that comparison.
What does it cost to maintain a custom ERP each year?
Budget 15 to 20 percent of the original build cost per year, so a $150,000 ERP needs roughly $22,000 to $30,000 annually for hosting, security patches, integration upkeep, and small improvements. Across Digital Heroes maintenance contracts, third-party APIs changing is the biggest recurring work item. That total still usually sits well under the license bill for a comparable NetSuite or Dynamics seat count.
What should I prepare before contacting an ERP development agency?
Bring a list of your current tools and spreadsheets, a rough map of how an order or job moves through the company today, your user count by role, and the three problems costing you the most hours. You do not need a formal specification; a good agency writes that with you during discovery. Companies that arrive with those four things typically cut two to three weeks off scoping in our experience.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
Who owns the source code if an agency builds my ERP?
You should, in full, and it must be written into the contract as work for hire with IP assignment on payment. At Digital Heroes every client receives the complete repository, database schemas, and deployment documentation, so they could hand the system to another team tomorrow. Walk away from any ERP proposal built on the agency's proprietary platform with ongoing license fees, because that recreates the vendor lock-in you were escaping.
How much does a custom ERP cost for a small business?
A small-business ERP covering two or three core modules typically runs $40,000 to $120,000, with inventory, ordering, and accounting sync being the usual starting set. Across 2,000+ Digital Heroes projects, integration count and user roles drive cost far more than screen count. A full mid-market ERP with six or more modules usually lands between $150,000 and $400,000.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
What happens to my ERP if the agency shuts down or we part ways?
If ownership was set up correctly, nothing breaks: you hold the source code, the system runs in cloud accounts you own, and handover documentation lets a new team take over. Insist on repository access from day one, admin ownership of all hosting and third-party accounts, and documentation as a contract deliverable rather than a favor. This is the single most important clause to check before signing an ERP contract.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
Should I pick Microsoft Dynamics 365 Business Central or build a custom ERP?
Pick Business Central if you already live in the Microsoft stack, your processes are close to standard, and around $80 per user per month for Business Central Essentials stays affordable at your headcount. Build custom when your revenue-driving workflow, such as custom manufacturing steps or unusual pricing logic, would need heavy extension work anyway. In our experience, once Dynamics customization quotes pass about $100,000 the custom option deserves a serious side-by-side.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
How do I vet an agency for an ERP project?
Ask to speak with two clients who have been running an ERP the agency built for at least two years, because ERP quality shows up in year two, not at launch. Then ask for their data migration plan, their module rollout sequence, and the named senior engineers who will be on your project. An agency that leads with screen designs instead of process mapping is a red flag for ERP work.
Who can build a custom ERP software system?
Digital Heroes builds custom ERP software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other ERP software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
