What you can absolutely do yourself
Choosing the stops and writing the scripts are the core of the guide and the parts only you can do. Nobody outside the organisation knows which object visitors ask about every single day, and no supplier can invent the detail that makes a story land. If you do nothing else in-house, do this.
Recording in your main language is also well within reach. A quiet room, a microphone that costs less than a day of consultancy, and free editing software will produce audio that visitors are happy to listen to on a phone speaker in a noisy gallery. Studio polish matters far less than pacing and a narrator who sounds like they care.
Selecting the stops, which is a curatorial judgment
Writing and revising the scripts
Recording and editing the main language
Designing and printing the signage
Testing the route with real visitors
What is harder than it looks
Translation is the first thing that breaks. Producing a translation is easy; knowing whether it is any good is not, and a guide with an embarrassing error in a language nobody on staff reads is worse than no guide in that language. You need a reviewer for every language you publish, and finding one is the real constraint rather than the translation itself.
Narration in other languages has the same problem one layer down. A synthetic voice makes additional languages affordable, but it will mispronounce place names and Indigenous names confidently, and only someone who speaks the language will catch it.
Then there is the part nobody plans for: serving the audio to visitors. Files have to live somewhere that loads quickly on a phone with two bars of signal, keep working when the person who set it up leaves, and stay reachable from a code printed two years ago. A folder on a shared drive with a public link is where many in-house guides start and where they quietly fail.
The part that becomes a job
A guide is not finished at launch. Content needs correcting, a display changes, a language gets added, a link breaks, a code stops resolving. If every one of those requires the one person who understands the setup, the guide degrades the moment that person is on leave or moves on.
This is the honest argument for putting the delivery on a platform even when everything else is done in-house: not because the technology is hard, but because someone else keeps it running and any staff member can change the content without knowing how it works underneath.
A realistic split
The split most small venues land on is to keep everything that touches the collection and hand off everything that has to keep running. You write, you record your main language, you choose the languages and find the reviewers. The platform hosts the audio, serves it from the QR codes, handles the language switching, and keeps working when the volunteer who set it up is on holiday.
That keeps the cost close to a do-it-yourself project while removing the failure mode that ends most of them.
Frequently asked questions
Can a small museum make its own audio guide?
Yes. The bulk of the work is choosing stops and writing scripts, which curatorial and front-of-house staff are already equipped for. Ten to twelve stops in one language is a realistic first project for a small team.
What is the hardest part of doing it yourself?
Not the recording. It is reviewing translations in languages nobody on staff reads, and keeping the audio reliably reachable from a printed code for years after the person who set it up has moved on.
Can we record it on a phone?
You can, and it is better than not doing it. A modest USB microphone in a carpeted room is a noticeable step up for very little money, and matters more than any editing you do afterwards.
Do we need to make an app?
No, and building one is the fastest way to turn a manageable project into an unmanageable one. A browser-based guide reached from a QR code needs no download from visitors and no app store maintenance from you.
Where do we host the audio files?
Somewhere that loads fast on a phone and will still resolve in three years. A shared drive link is the usual first attempt and the usual first failure, because links change, permissions lapse, and the printed codes cannot be changed to match.