Custom library app development
A library app gives members access to their borrower account, the collection and the programme of their own branch, connected to the library system where all of that already lives. A national app already exists for the standard transactions. A custom app is therefore most worthwhile when you want to offer something that doesn't fit there: your local programming, a partnership with schools or the municipality, or a special collection that deserves its own entrance.
What does a library app do?
The basics are the same for every library: searching the collection, seeing what you have borrowed, renewing, reserving and using your card at the self-service desk. These features sit in the library system, and the app is a shell around them. For many Dutch libraries that system is OCLC Wise, which according to the supplier is used by roughly three quarters of public libraries in the Netherlands.
An honest observation comes with that. A national app that connects to Wise already exists for those standard transactions. Building your own app that does the same gives you a second entry point to the same data, with duplicate management and a user who has to choose. That is rarely worth the investment.
A custom app is justified once you want to offer something beyond that national framework. Think of the programming at your own branches, a reading promotion programme with schools in the municipality, a makerspace with bookable equipment, or a special local collection that deserves its own presentation. The app then isn't a copy but an addition, and it can simply carry over the borrower account from the library system.
One source, no second membership administration
The app reads the borrower account from your library system. No separate user administration arises that you must maintain alongside the existing one and that drifts apart after a year.
Room for what is local
Programming, courses, reading groups and partnerships with schools or the municipality. This is exactly the part a national app has no place for, and where your branch stands out.
Self-service in line with the agreements
Lending and returns via RFID in the Netherlands follow the Generiek Programma van Eisen (Generic Programme of Requirements), so that equipment and systems from different suppliers work together.
How we build your library app
We start with the question of whether you really need the app, and if so, for which part. That conversation more often yields a sharper brief than a list of desired features, because half of those are usually already available elsewhere.
We map out what your library system and the national provisions already offer. What is well covered there, we do not rebuild. What is missing becomes the core of the app.
We design the integration with your library system for the borrower account and collection data, plus the screens for the part that is your own. Accessibility is built in from the start here, not added afterwards.
We build in short iterations and test with real members, including people who are less digitally confident. A library audience is broader than the average app target group, and you only discover that through testing.
Publication to the app stores and rollout across the branches, followed by ongoing maintenance. Library systems and national services change over time, and your integrations need to keep pace.
What we build for libraries
The focus differs per organisation. A library with a strong educational arm needs something different from one that mainly works on visitor experience and programming.
Searching the collection
Searching your own collection with availability per branch, including reserving and joining the waiting list. The data comes from the library system, so the status is accurate.
Library card and self-service
Only just available for use at the self-service desk. For lending and returns via RFID, we work within the agreements that apply to libraries in the Netherlands.
Programmes and activities
Activities, courses and reading groups per branch, with registration and reminders. This is the part for which a dedicated app is usually built.
Special and local collections
A dedicated entry point for a regional collection, a heritage archive or a makers' space with bookable equipment, presented in the way such a collection deserves.
Education and cooperation with schools
Support for reading promotion, with separate entry points for teachers and pupils. See also our read-aloud app.
Messages and reminders
Messages about reserved titles, return dates and activities someone has signed up for, with adjustable preferences per member.
Which organisations we build for
Not every organisation that holds a collection is a public library, and the requirements vary.
Public libraries
Libraries with multiple branches that want to make their local programmes and partnerships visible alongside what national services already offer.
Education libraries
Libraries at schools and institutions, where the collection is tied to the curriculum and member administration often comes from a different system.
Corporate and institutional collections
Organisations with an internal collection or the lending of materials and equipment. See also our work on a lending system.
Heritage and cultural institutions
Institutions that combine collection and visitors. See also our museum collection management software.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology, integrations and accessibility
The integration with your library system is decisive. We build on that system's API rather than duplicating data, so the app doesn't become a second source of truth. For RFID in the Netherlands, the Generiek Programma van Eisen voor RFID in Openbare Bibliotheken (generic requirements programme for RFID in public libraries) sets out the data model so that equipment from different suppliers works together and media remain interchangeable between libraries. That programme aligns with the international standard ISO 28560. Where needed, we build a scanner app to recognise items.
Why choose Appfront for your library app?
We build custom software with smart technology and thoughtful design, and we start with the question of what really needs building. For libraries, this often means a smaller project than expected, because some of the wishes are already covered by existing services. That is a more useful conversation than delivering an app that turns out to sit alongside a national app.
We factor accessibility in from the design stage. A library audience is broad: children, people who are less confident with digital tools, people with a visual impairment. An app not tested for these users excludes exactly the groups a library is there to serve. We therefore measure against WCAG 2.1 level AA and test with real users.
We work in design and development sprints, and the process runs from a no-obligation introductory conversation through planning and development to maintenance. Maintenance counts for a great deal here, because library systems and national services keep evolving and your integrations need to move with them.
See also our broader app development work, our work for cultural institutions, and what we do in custom software.
- Custom app development for iOS, Android and web, tailored to your organisation
- Starting by mapping out what existing facilities already do
- Integration with the library system, not a second membership administration
- Working within the Dutch RFID agreements for libraries
- Accessibility to WCAG 2.1 AA standards from the design stage onwards
- Testing with members, including users with lower digital skills
- Room for local programming and partnerships
- Clear documentation of integrations and data flows
- Ongoing management as systems or facilities change
Privacy in a library app
Loan records are more sensitive than they might first appear. What someone reads can reveal something about their health, faith, sexual orientation or political views. Libraries have a long-standing tradition of protecting that information, and that tradition should carry through into the app rather than being sacrificed for a convenient recommendation feature.
In practice, this means: only keeping a loan history if the member chooses to, not basing recommendations on data you really shouldn't be holding, and not building in analytics packages that pass reading behaviour to third parties. These are design choices, not settings added afterwards. We process personal data in line with the GDPR, with data minimisation as the starting point.
For children's accounts, consent and parental oversight must also be explicitly arranged. Our broader approach is set out in our information security policy and vulnerability disclosure policy. Want to discuss your situation? Get in touch.
- Loan history only at the member's explicit choice
- Data minimisation as the starting point for every integration
- No sharing of reading behaviour with third parties
- Separate arrangements for children's accounts and parental oversight
- Role-based authorisation for staff
- Encryption in transit (TLS 1.2 or higher) and at rest
- GDPR-compliant processing of borrower and activity data
- Documented data flows for your record of processing activities
Frequently asked questions about building a library app
What libraries usually ask us first.
For standard tasks such as searching, renewing and reserving, a national app already exists that connects to the library system. Building your own app to do the same would mean duplicate management and users having to choose between them. It becomes worthwhile once you want to offer something beyond that: your own programming, a partnership with schools or a special collection.
Yes, that is the starting point. We build on your system's API, so the borrower account and collection data come from the source. This avoids a second administration that drifts out of sync over time. Which integration options are available depends on your system and the agreements with your supplier.
It is the Dutch data model for RFID in public libraries. It ensures RFID works within libraries' logistics systems without depending on a single supplier, and that media remain interchangeable between libraries. It aligns with the international standard ISO 28560. A certification model exists for suppliers of RFID systems.
Loan records reveal more about a person than most of the data you handle. We therefore only keep a loan history if the member chooses to, do not base recommendations on data you really shouldn't be keeping, and do not build in analytics packages that pass reading behaviour to third parties. These are design choices, not settings added afterwards.
For a library, this is a more demanding requirement than for most clients, because your audience is broad. We test against WCAG 2.1 level AA, ensure the app works with a screen reader, and test with users who have lower digital skills. An app that hasn't been tested for this excludes precisely the people the library is there for.
Yes, and for many libraries that is the main reason to build a custom app. Activities per branch, registration, a reminder in advance, and an overview of what someone has signed up for. This can be connected to the system where you already manage your programming.
We make the parts that change often, such as activities, news items and featured collections, manageable without a developer. Structural changes and new integrations are development work. We agree upfront which part falls into which category.
Yes. The emphasis differs there: the collection is more often tied to a curriculum or subject area, and user administration usually comes from a different system than a library management system. Lending of materials and equipment rather than books is also common.
Ready to build a library app?
Tell us what you want the app to achieve and which library system you use. We are happy to first look together at what existing facilities already cover, so that you build what is genuinely missing. This often results in a sharper and smaller project than expected.