A guide to choosing a digital strategy for your catalogue raisonné
A practical guide for those deciding between building a custom solution, customizing and connecting several pieces of software, or signing up for a purpose-built platform.
Claude Monet, Winter Landscape with Evening Sky, ca. 1870.1880. Pastel chalk on woven paper, 23 x 32.6 cm. Städel Museum, Frankfurt am Main; in the public domain.
Three approaches to catalogue raisonné technology
A digital catalogue raisonné is one of the most complex publishing projects an institution can undertake. In these living scholarly projects, records accumulate, information changes, high-resolution images need to be served securely, and the whole publication has to remain accessible and credible for future generations. Getting the technology right matters, not just for the preparation and launch, but for the long-term sustainability of the scholarship.
The good news is that there are more choices than ever; however, the range of options makes the decision genuinely hard, especially for organizations with limited budgets and no dedicated software engineer on staff. To help make sense of the landscape, we surveyed the technology behind 118 live digital catalogues raisonnés, fingerprinting each through HTTP headers, source code, and network requests to identify the actual stack in use. The three categories that follow reflect what that data shows.
Off the shelf: you can use a platform built specifically for catalogues raisonnés, buying off the shelf.
Assemble: you can assemble a solution by combining existing tools — a database, a content management system, plugins, etc. — into something that fits your requirements.
Build from scratch: you can build from the ground up, writing custom software tailored to your exact needs.
Each path has real advantages and real costs, and the right choice depends less on what is technically best than on what your organization prioritizes and can feasibly sustain.
Before reading in depth, a quick orientation. Organizations without dedicated technical staff and limited budgets will almost always find a purpose-built platform the right starting point. Those with existing content management systems or database expertise, either in-house or through a trusted agency, are well-positioned for the assembled approach. Custom builds are viable when scholarship is genuinely too complex for existing platforms and the organization can commit to long-term software maintenance. The sections below cover each approach in depth.
Purpose-built catalogue raisonné platforms: the most common choice
Off-the-shelf platforms are software products built specifically for digital catalogues raisonnés. You subscribe to a single service that handles infrastructure, image delivery, and the browsing interface, all designed around catalogue scholarship from the start.
For most organizations today, this is the clearest path to a durable, well-supported publication. The data model is already designed for catalogue raisonné scholarship, so you are not contorting general-purpose tools to fit specialized needs. Staff training and onboarding are supported. And because other catalogues run on the same platform, improvements and new features benefit the whole community, not just institutions that can afford to commission them independently. That 59% of independent catalogues in our survey run on a purpose-built platform reflects a genuine match between what these products offer and what catalogue teams actually need.
-
No dedicated technical staff required
Infrastructure, security, and updates are handled by the vendor
Data model is already designed for catalogue raisonné scholarship
Staff training and onboarding are supported
Improvements and new features benefit all catalogues on the platform, not just those with large budgets
Lower upfront cost and more predictable economics than custom or assembled approaches
-
Customization is limited to what the platform supports
Some control over design and presentation is ceded
May not accommodate unusual or highly complex data structures
Subscription costs accumulate over time
Switching platforms later is possible but requires careful planning around data portability
You are dependent on the vendor's growth plan and pricing is defined by contract
Common tools in this category: Artifact (Foundation for Artist Catalogues) and Navigating.art are the most widely used independent platforms. Collection management systems that some institutions have adapted for catalogue raisonné use include eMuseum (Gallery Systems/TMS), Qi (KeepThinking), and Arteia.
Before committing to a platform, it is worth evaluating a few things carefully.
Data portability needs to be considered at the beginning. If you decide to leave, can you export your records in a clean, structured format like JSON or CSV? What about images and metadata? A vendor confident in its product will answer this without hesitation. One that deflects is a warning sign.
Pricing over time deserves as much scrutiny as the launch cost, and this is often where platforms differ from one another. Some subscription models decrease over time, others increase. Ask for a realistic ten-year projection, and model what happens if rates decrease or increase. The economics that make a platform attractive at launch should still hold true or improve a decade in.
Vendor stability matters when your publication is designed to last generations. How many active catalogues does it support? How is it funded? Is there evidence of continued development — new features, regular updates? A platform with a strong and growing user community is a better long-term bet than one that appears to have stalled.
Feature fit requires an honest assessment of your scholarship. Most purpose-built platforms handle standard catalogue raisonné requirements well, including work records, attribution states, provenance, exhibition history, and literature. If your scholarship involves unusual data structures, such as highly complex edition hierarchies or deeply interlocking archival relationships, test those specific cases before committing.
Customization limits might make a difference if the feature fit is not aligned. You can configure a platform but not fundamentally redesign it. If the visual presentation of the artist's work matters to your institution, ask what latitude you have over design or if you can interact with the database via API for a custom addition, and look at other catalogues running on the platform to see whether the range of presentation feels acceptable.
Support and transition are worth probing practically. Talk to other catalogue teams running on the platform. How responsive is support when something goes wrong? How much institutional knowledge do you need to maintain, and how much does the vendor handle?
As with any vendor relationship, a good platform provider will answer these questions directly and thoroughly. If they do not, that is useful information too.
Assembling a catalogue raisonné tech stack from existing tools
Assembling a solution means combining existing tools rather than using an all-in-one solution or building almost everything from scratch. In practice, this almost always starts with a database, which is the system that stores and organizes records. On top of that comes a content management system, a frontend theme, and various plugins to make everything work together.
The appeal is that you are not reinventing the wheel; however, initial and ongoing costs must still be considered. Each component has already been built, tested, and maintained by someone else. The job of your engineer is to configure and connect the pieces. It is substantially cheaper than a full custom build, but it carries its own maintenance burden: plugins go out of date, major content management systems version upgrades can break custom code, and you still need someone who can troubleshoot when things go wrong. Budget carefully for ongoing maintenance, not just the development.
-
Less expensive than a full custom build
Core components are already built and tested
Benefits from large support communities, especially for widely-used platforms
Flexible enough to accommodate a wide range of scholarship without starting from zero
-
Requires significant budget and dedicated technical staff or an ongoing agency relationship
Plugins and integrations go out of date; major CMS version upgrades can break custom code
General-purpose tools were not designed for catalogue raisonné scholarship — workarounds accumulate
Maintenance burden is ongoing and easy to underestimate at the outset
The more components involved, the more points of failure
Common tools in this category: Database layer: FileMaker Pro (dominant in estate offices), Airtable and Notion (smaller collections), Collective Access (open-source, museums and archives). CMS layer: WordPress (most common), Drupal (stronger native support for complex content types), TYPO3 (prevalent in European institutions), Craft CMS, and Joomla. These are often combined. FileMaker as an internal research database feeding a WordPress public-facing publication is a typical configuration.
One operational practice that assembled projects require is a structured communications plan between the technology team and the editorial and research teams. In an assembled solution, technical decisions — which plugin, which version, which configuration — directly shape what editors can and cannot do day to day. Regular check-ins, shared documentation, and a clear path for raising problems when something breaks are the mechanisms by which the project stays coherent as the technical components are updated and personnel changes. Establishing this structure at the start of the project is worth the time.
Choosing a database for your catalogue raisonné
The database layer is one of the most consequential choices you will make. FileMaker has a long history in arts administration because its visual interface makes it accessible to non-developers. It remains the dominant internal database for artist estate offices. Newer options like Airtable and Notion offer approachable interfaces for smaller collections, but they are not designed for the scale or complexity of a serious catalogue raisonné.
Before committing to any database, there are several factors worth thinking through carefully.
Usability is easy to underestimate when you are evaluating tools under deadline pressure. The people who will use the database day to day are often not the same people who selected it. Consider how data entry actually works for someone adding fifty records in an afternoon. A technically impressive system with a confusing interface will slow your scholarship and create errors.
Cost is rarely just the licensing fee. Factor in setup and configuration, staff training, and ongoing maintenance and troubleshooting. A free or inexpensive database that requires significant technical labor to run may cost more over five years than a subscription service that handles that burden for you.
Workarounds are worth scrutinizing. Every database forces some compromises, such as a field repurposed for something it was not designed for or a relationship approximated rather than modeled correctly. A few workarounds are normal and manageable. Many workarounds compound: they make data entry slower, introduce inconsistencies, and make future migrations harder. Before committing, map your most complex record types against the system's native capabilities. If the fit requires substantial contortion, that is a signal worth heeding.
Longevity matters in a field where projects span decades. Look for systems with a clear path of continued development, an active user community, and a business model that is likely to survive.
Data portability is important from the start. Before signing a contract or investing significant time in a proprietary system, ask what it will take to get your data out, in what formats, with what structure, and at what cost if needed. Many organizations discover this is harder than expected only when they need to migrate. Standard export formats like CSV, JSON, or XML are a baseline; a database that cannot produce clean, structured exports is a long-term liability regardless of how well it works today.
Content management systems: what are they and what to consider
Above the database, the content management system (CMS) is what most people actually interact with day to day. A CMS is software that lets non-developers create, edit, and organize content in a database or on a website without writing code. Think of it as the editorial layer that sits between your database and your public-facing catalogue. The CMS handles the presentation logic, the navigation structure, and the day-to-day publishing workflow. Most of the websites you use regularly run on a CMS of some kind.
WordPress is the most common choice in the catalogues we surveyed. One prominent catalogue runs on Drupal 10, which has stronger native support for complex content types. Others use TYPO3, a popular choice in European institutions, Craft CMS, and Joomla.
The assembled approach works well when your organization has existing CMS expertise, either in-house or through a trusted agency, and when your scholarship fits reasonably well within the data structures those platforms support.
Collective Access occupies an interesting middle ground within this category. It is open-source collections management software designed specifically for museums and archives, not a general-purpose content management system. It handles complex object records, hierarchical relationships, and controlled vocabularies natively. It is the platform of choice for some estates building deep archival infrastructure and for some beloved digital catalogues raisonnés. Collective Access is free to download, but it requires technical expertise to deploy and configure, and its user interface is functional rather than polished. Because of this, it can cost tens of thousands to set up. It is a strong option for institutions with existing collections management needs and the technical staff and the budget to support it.
Building a custom catalogue raisonné from scratch
Building from scratch means commissioning custom software: a development team designs a data model around your scholarship, writes code specifically for your catalogue, and builds the interface and infrastructure from the ground up. There might be some customization of an existing database or other augmented pieces of software, but the majority of the software stack was designed specifically for you. This is a powerful option and the most expensive.
The advantage is control. A custom build can handle whatever data model your scholarship requires, such as multiple edition states, uncertain attributions, complex provenance chains, and linked exhibition histories. The interface can be designed around how your research team works and the quirks of the larger institution. The online presentation can also be designed to best represent the artist. But these benefits come at a cost.
Custom development is expensive upfront — often more than a hundred thousand dollars for a well-executed project — and the costs do not end at launch. Software requires maintenance. Frameworks become outdated. Security vulnerabilities appear. If the engineers who built the catalogue move on, institutional knowledge walks out the door with them. Several of the custom-built catalogues we examined are showing their age: running on PHP versions that have reached end-of-life, or on JavaScript frameworks from the early 2010s that are no longer actively supported.
Building from scratch makes sense if your organization has a substantial budget, a long-term commitment to software maintenance, and scholarship complex enough that no existing platform can accommodate it. If those conditions do not all hold, the other options deserve a close look.
-
Complete control over the data model. Any complexity of scholarship can be accommodated
Interface and presentation can be designed specifically around your research team and the artist
No dependency on a vendor
Can be built to integrate with existing institutional systems and workflows
-
Highest upfront cost, typically in the range of hundreds of thousands of dollars
Ongoing maintenance is the organization's responsibility: frameworks age, security vulnerabilities appear, and rebuilds become necessary
Institutional knowledge is fragile — if the engineers who built it leave, that expertise goes with them
The pool of developers familiar with aging frameworks shrinks over time, making maintenance progressively more expensive
Common tools in this category: Three catalogues in our survey run on contemporary frameworks (Next.js or Nuxt.js with GraphQL and AWS), but the majority of existing custom catalogues run on PHP backends and jQuery frontends built in the early-to-mid 2010s — stacks that are functional but will require complete rebuilds as they age out of support.
The most direct practical response to the institutional knowledge problem is keeping a running record of every significant technical and editorial decision made throughout the project: why a particular framework or data model was chosen, what was considered and rejected and on what grounds, what workarounds were introduced and why. When engineers move on — and in a project that spans decades, they will — what remains is the scholarship, the data, and whatever documentation the project produced. A catalogue built with thorough decision records is maintainable by developers who were not present for the original choices; one without them is not. This practice matters in assembled projects too, but it is most critical here, where the entire stack was built specifically for you and no vendor documentation exists to fill the gaps.
Why technology choices have long-term consequences
One pattern in our survey deserves direct attention. The majority of custom and assembled digital catalogues raisonnés — including many built in the last decade — run on technology from the early-to-mid 2010s. This is not a criticism of the organizations that built them; it reflects the reality that catalogue projects operate on an extended timescale foreign to digital technology. Older frameworks receive fewer security updates and eventually reach end-of-life. Search engines favor sites built on current web standards. Mobile users — now the majority of web traffic — get worse experiences on sites built before responsive design was standard practice. And the pool of developers familiar with aging frameworks shrinks over time, making maintenance progressively more expensive.
This does not mean you need to use the newest possible technology. Stability and maintainability matter more than novelty. But when you are making a technology decision today, think not just about what will work for the launch, but about what the maintenance landscape will look like in five or ten years. A platform with an active user community and a track record of updates is a better long-term bet than a technically impressive custom build that one person maintains in their spare time.
The maintenance question looks different for a custom build than for a platform, but it is relevant whichever path you choose.
Which approach is right for your catalogue raisonné?
There is no universally correct answer to the technology question. The right choice depends on the complexity of your scholarship, the size of your budget, and your organization's realistic capacity to sustain the system over time.
If your budget is limited and you do not have dedicated technical staff, a purpose-built platform is almost certainly the right starting point. The upfront economics are more favorable, and you are not taking on the ongoing burden of infrastructure maintenance. Evaluate the available platforms carefully, ask hard questions about long-term pricing, and choose the one whose data model best fits your scholarship.
If you have existing content management system or database expertise then the assembled path can work well. WordPress or Drupal with appropriate customization can handle most catalogue raisonné requirements, and you benefit from large, active support communities. Budget carefully for ongoing maintenance, not just the initial build.
If your scholarship is genuinely complex enough to require a custom solution, and your organization has the budget and long-term commitment to maintain custom software, then building from scratch remains a viable option. Go in with eyes open about the total cost of ownership, and invest in documentation and knowledge transfer from day one.
Whatever path you choose, the most durable investments you can make are in your data. Model it carefully, keep it clean.
The software will change; the scholarship is what lasts.
