Picture your IT director sitting in front of an audio guide proposal for the first time. They have bought plenty of software — the CRM, the ticketing system, the finance platform. They know the rhythm: license, implementation, integrations, training, support SLA. Halfway through this proposal they realise the shape is wrong. There is no seat-based license. The vendor wants to host the content. Pricing is per visitor interaction. The "CMS" is a knowledge graph. There is a native app and a web app and something about offline caching on the visitor's device.
They put the document down. They have questions.
This article is for that person. What museum audio guide software actually is, what the category looks like, what to check before signing, and why the build-vs-buy maths is not what it used to be.
The category is weirder than it looks
A museum audio guide isn't one piece of software. It is at least four, stitched together and usually sold as a bundle.
- A content authoring tool for curators — somewhere to write, record or generate narrations, attach media, and structure tours. More complex than it sounds once you have multilingual content, reviewer workflows, and seasonal variants.
- A visitor-facing runtime — the web app or native app that actually plays audio, handles positioning, and manages state on the visitor's phone.
- An analytics and reporting layer — what curators and marketing look at to see which stops worked.
- An integration surface — webhooks, SSO, CMS export, ticketing cross-refs, donor CRM sync. Usually the weakest part of any vendor.
Most procurement teams evaluate audio guide software as if it were a single app. It is not. The quality of each layer varies independently, and the one that most often lets museums down is the authoring tool, because it is the one IT doesn't see during a demo.
Build vs buy, and why the maths moved
For a long time, the honest answer to "should we build this ourselves" was "it depends." Large institutions could look at vendor pricing, multiply by five years of expected visitor volume, and convince themselves an in-house product would pay for itself. That analysis is broken now.
The old calculation compared vendor capex-ish contracts (upfront licensing, per-device fees, annual support) against an in-house build amortised over the useful life of the software. If vendor spend looked like capex, an in-house build just had to beat that number.
Modern audio guide vendors aren't selling capex anymore. Pricing has moved to revenue share or per-interaction — you pay as visitors use the guide, or you don't pay at all. There is no upfront number to beat, because the commercial option is pure opex that scales with usage. Building in-house, by contrast, still front-loads a year of engineering time, hiring a product designer who understands museum content, and the opportunity cost of whatever your team isn't doing instead.
Build in-house if you are a national institution with an existing product team, a multi-year commitment to the platform, and a genuine reason the vendor market can't serve you. Otherwise, buy. I have watched museum-built audio guide projects stall at the authoring-tool stage more times than I can count — not because engineering couldn't ship a player, but because nobody scoped the curator-facing software seriously enough.
Web, native, or both
The delivery choice drives the rest of the stack. There is a longer piece on web vs native if you want the full treatment, but the short version for an IT reviewer is this.
Web-first means no app store review, universal device support, instant content updates, and a single codebase to audit. It means harder offline support, some iOS audio quirks, and no push notifications without a PWA install. Native-first flips all of those. Most vendors worth evaluating now ship web as the default, with native available when the site demands it (deep offline, beacon integration, destination-museum brand app).
The practical question during procurement isn't "which is better in the abstract." It is whether the vendor's web runtime works on the range of phones your actual visitors carry. Ask for real-device test reports. A surprising number of museum web apps are tested mostly on iPhones owned by the vendor's engineering team.
Open source vs proprietary
There are a handful of open-source museum guide projects. A few come out of university labs, one or two out of large institutions that open-sourced internal work. They are usually missing at least one of: a serious authoring tool, multilingual pipelines, analytics, or any kind of support commitment.
For a museum, "open source" is only meaningful if the code plus someone to maintain it equals less than the cost of a commercial platform. In practice it almost never does. The maintenance burden of a forked open-source audio guide — patching dependencies, supporting browser changes, debugging why the audio stops playing on iOS 19 — eats whichever team you assign to it.
Proprietary SaaS is the default for a reason. The one caveat: make sure the vendor gives you a clean export of your content in open formats. If you ever need to leave, you want your scripts, recordings, and tour structure as files, not trapped in a proprietary schema.
What to actually check in a security review
The things that matter, roughly in order:
- Data residency. Where is visitor data stored, and in which region? If you are in the EU, you want EU-hosted, full stop. Ask which cloud, which region, and whether any sub-processors sit outside it.
- DPA and sub-processor list. Get a signed Data Processing Agreement. Get the sub-processor list in writing. Check that analytics, transcription, LLM inference, and CDN are all accounted for.
- Authentication on the curator side. SSO via SAML or OIDC should be available, at least on higher tiers. If the authoring tool only has username-password auth, you have a problem if any curator reuses credentials.
- Visitor data minimisation. What does the platform collect about visitors? Ideally: anonymous session IDs, interaction events, no PII. If a vendor wants visitors to create accounts to use the guide, understand why.
- Retention. How long do analytics events live? Ninety days is usually enough for operational reporting. Seven years is not.
- Content rights. Who owns the audio, the transcripts, the generated content if AI is involved? The contract should be unambiguous that the museum retains ownership.
- Breach notification. The contract should commit to a specific window — typically 72 hours — consistent with your own obligations under GDPR.
This is a shorter list than most enterprise software reviews because the surface area is smaller. An audio guide doesn't touch your finance system. It shouldn't touch visitor PII beyond what is strictly necessary. The threat model is less about data exfiltration and more about availability and content integrity.
Hosting and data residency, honestly
For European museums, GDPR compliance is not optional and it is not hard to get right. Pick an EU-hosted vendor, sign the DPA, confirm sub-processors. If the vendor's analytics run through a US-based tool with no Standard Contractual Clauses, that is a flag. If they pipe audio through a transcription service in an unspecified region, that is a flag. None of this is exotic — it is the same diligence you would do for any SaaS touching visitor data. There is more detail in our GDPR-focused piece.
Self-hosting comes up in conversations with government-run museums and a few national institutions. It is technically possible with some vendors, rare with most. The trade is real: you take on hosting costs, patching, monitoring, and the vendor's analytics infrastructure, in exchange for physical control of the data. For a museum that genuinely cannot send visitor data off-premise, this is the right answer. For most, it is a lot of work to solve a problem you don't actually have.
The integration layer
This is where most audio guide software disappoints, and it is also where IT spends the most time after signing. The integrations that come up repeatedly:
- Ticketing. Link the guide to a ticket QR code so you can attribute usage, upsell, and reconcile visitor counts. Most major ticketing systems (Tessitura, Galaxy, ACME, vivenu) have APIs; not every audio guide vendor has built against them.
- CMS. Your museum website probably runs on WordPress, Drupal, Contentful, or similar. The guide's content should link back to collection pages, and ideally sync in one direction (CMS as source of truth for object metadata).
- Collections management. TMS, MuseumPlus, Mimsy, Axiell. Pulling object data directly from collections management avoids curators retyping everything into the guide. Few vendors do this well; the ones that do tend to win the institutional accounts.
- CRM and donor systems. Less critical for the guide itself, but if you want to know which members use the guide and which don't, a link to Salesforce or a fundraising CRM matters.
- SSO. For the curator-facing side, at minimum. Okta, Azure AD, Google Workspace.
Ask any vendor for a specific list of what they have integrated with, in production, at another museum. Not "we have an API" — "we integrated with Tessitura at Museum X, here is the case study." The difference matters. A dedicated page on system integrations covers this in more depth.
Maintenance, upgrades, and the content-authoring problem
The part IT consistently underestimates is not the software. It is the content.
A typical institutional audio guide has 80 to 200 stops. Each stop needs a script, translated into however many languages you support, recorded or generated, reviewed, corrected, and versioned as exhibitions change. That work is ongoing. Budget for it as a permanent part of the operation, not a launch-time task. The software decision matters partly because a good content management setup can cut curator time per stop from hours to minutes, especially with AI-assisted drafting and translation.
On the software-maintenance side, SaaS takes most of the burden. You don't patch servers, you don't upgrade frameworks, you don't handle browser compatibility. What you do handle: periodic security reviews, annual contract renewals, sub-processor changes, and occasionally a vendor decision you disagree with. The upgrade cadence is whatever the vendor ships — weekly, usually, invisible to you, sometimes visible to curators when the authoring UI changes.
If the vendor is still shipping meaningful product improvements each quarter, that is a good sign. If their changelog is mostly bug fixes and the product hasn't visibly changed in two years, they are either very mature or quietly winding down. Ask.
The economics, flipped
Come back to the build-vs-buy question with the pricing model in mind. A vendor offering revenue-share or per-interaction pricing — Musa is one example — means your software cost scales with visitor engagement and drops to near-zero in off-seasons. There is no capex line to defend to the board, no five-year amortisation, no "we are paying for devices we don't use." An in-house build, by contrast, is all capex and all fixed opex afterwards. Whatever engineering team maintains it costs the same whether 10,000 or 100,000 visitors use the guide.
That inversion is the thing most IT directors miss on the first read. The commercial option isn't just cheaper on average — it has a completely different risk profile. And once you account for that, the in-house case has to clear a bar that it almost never actually clears.
What to do next
Shortlist two or three vendors. Get demos of the authoring tool, not just the visitor app. Ask for production integration references. Run the security review early — before you have emotionally committed to a choice. Pilot with one exhibition before rolling out museum-wide.
If you are partway through this process and want a sanity check — whether on vendor diligence, hosting, or where the hidden costs really are — we are happy to talk it through. Fewer slides than a sales call, more answers than you would get from most procurement portals. If that is useful, get in touch. And if you are still trying to decide between dedicated devices and any kind of software at all, start with the hardware-vs-software comparison.