whatifmachine.ai/museums

Make It Yours

A guide to customizing and expanding the free museum templates.

Every part of these applications was built by describing a problem in plain language. Nothing in this guide requires you to write code. If you can explain how your museum works, you can change how this software works.

What is in here

The first half is the method. It applies to any of these templates, and to anything you decide to build from nothing. The second half is one section per template, with examples you can adapt.

If you are only changing one template, read Part One once and then skip to your own section.

Part One — The method

How this works
Keep a record outside the conversation
Planning your first change
Closing your copy
Look and feel
What costs money

Part Two — The templates

The Exhibition Checklist
The Program Recipe Box
The Attendance Analyzer
Where to start

Part One

The method

Everything in this half applies to any template here, and to any application you build from scratch. None of it is specific to one piece of software.

How this works

Two tools, two different jobs.

Building software this way uses two things that are easy to confuse. The first is a conversational AI assistant, the kind you type questions into. The second is an app-building platform, which turns instructions into a working application.

You talk to the assistant. The assistant writes instructions for the platform. You paste those instructions in. That indirection is the whole method, and it matters more than which particular products you use.

Why not talk to the builder directly?

You can, and for small changes you should. But the builder does what you say, literally, and every change it makes costs money or usage credits. It will not tell you that your idea has a flaw. It will build the flaw.

The assistant is the opposite. It is cheap to argue with, it will push back, and it will ask what you mean before anything gets built. A conversation that saves one unnecessary build has paid for itself.

The shape of a working session

You describe a problem in your own words, the spreadsheet column that never gets filled in, the thing you keep forgetting.
The assistant asks questions. Answer them honestly, including when the answer is “I don’t know yet.”
The assistant writes a precise instruction. Read it before you use it. If it describes something you did not ask for, say so.
Paste it into the builder. Wait.
Check the result yourself. Open the screen. Click the thing.

Trust the screen, not the summary. Builders report success when the code compiles, which is not the same as the feature working. More than once while building these applications, a build reported success having quietly done nothing at all. Another reported a page was fixed when it had been showing every program’s sessions on every program’s page for weeks. Always look.

Ask before you build

Most platforms offer a cheap conversational mode alongside the expensive one that changes code. Use the cheap one constantly. Ask what a screen currently does, what a field is called, whether something already exists. Every question answered before a build is a build you do not have to undo.

Each template section in Part Two opens with a list of things that are already there. Read it before you ask for anything. A surprising amount of what looks like it needs building is either already built or adjustable in seconds.

Keep a record outside the conversation

The single habit that makes this work at all.

A long conversation with an AI assistant is not a reliable record. It will lose track of decisions made hours earlier. It will forget constraints you set at the start. Late in a session it may confidently describe something that never happened, or ask you to re-supply information you already gave it. This is normal, and it is not a reason to avoid the method. It is a reason to keep your own list somewhere else.

Use whatever task tool you already have. A shared checklist, a project board, even a plain document. The tool matters far less than the habit.

Track four things

Changes requested. What you asked for, and when. Keep “reported done” separate from “I have seen it working with my own eyes.” Those are two different columns, and the gap between them is where problems hide.
Bugs found. Write them down the moment you notice, even in the middle of something else. You will not remember later. Note where it happened and on what device, because “the images look wrong” is not enough to act on next week.
Decisions and their reasons. Why you chose one approach over another. Without this you will relitigate the same argument in three weeks, and the assistant will happily argue both sides again.
Things parked deliberately. Ideas you considered and set aside, and why. Otherwise they resurface as fresh suggestions forever.

Write your rules down once

Keep a short list of the constraints that apply to every request. No login. No email. Must work on a free account. Do not add features I did not ask for. Paste it in at the start of a new conversation rather than hoping an old one remembers. Five lines at the top of a session can save an entire build that has to be undone.

When the assistant starts asking for things it should already know, a decision you made an hour ago or a list you already gave it, the conversation has drifted. Do not let it guess. Paste the facts back from your own record, or start fresh with your notes as the first message. Guessing is where fabricated answers come from.

Starting over is not losing progress

Long sessions degrade. When one becomes unwieldy, write a short handoff covering what the thing is, what is already built, what the constraints are and what is still open, then begin again with that as the opening message. It feels like throwing work away. It is the opposite.

Planning your first change

Describe what you do, not the software you want.

The most common mistake is asking for a feature. “Add a reporting module” produces something generic that fits nobody. Describe the actual work instead, and let the software be shaped around it.

A good description covers four things.

1. What you already do. The current process, including the parts that are embarrassing. Where it lives now. Who touches it. What breaks. If the real answer is “a spreadsheet with merged cells that only Karen understands,” say that.
2. The nouns. Software is built around things. Objects, exhibitions, spaces, programs, volunteers. Name yours and say how they relate. Getting this right at the start saves more time than anything else.
3. What should not be there. Builders are generous. Left alone they add dashboards, charts, settings screens and features nobody asked for. Say plainly what you do not want.
4. Sample data. Always ask for realistic sample content. An application that opens empty is impossible to judge and feels broken. Ask for a dozen plausible records, with some work finished and some not.

Ask for the awkward cases too. Sample data that is too tidy hides problems. If every record looks the same, you will not find out what happens when two things collide, or when somebody leaves a field blank.

Putting it together

Sample prompt

I run a small history museum. Right now I track incoming object donation offers in a spreadsheet and in my email, and things get lost between the two. A donor offers us an object. I log who offered it, what it is, photographs, the date offered, and any conditions they attached. Then it goes to a committee, who accept, decline, or defer it. I need to know what is still waiting on a decision, and I need to find last year's decisions when someone asks. The things are: Offers, Donors, and Decisions. One donor may make several offers. One offer has one decision. Do not build a login, email sending, or notifications. It has to work for one person on a free account. Seed it with twelve realistic sample offers at different stages, including two that have been waiting more than a year and one where the donor attached an awkward condition.

That is a complete instruction. It describes real work, names the nouns, sets limits, and asks for something you can look at. What comes back will not be perfect, but it will be recognizably about your museum.

Closing your copy

This applies to every template here.

The public copy of each template has no sign-in, because it is a demonstration holding invented data. Your copy needs closing before real records go into it. These are the changes to ask for, roughly in the order you will want them.

Where a prompt names something specific to one template, swap in your own nouns. The shape of the request does not change.

Require people to sign in

Goal. Close the application. Right now anyone with the address can open it.

Sample prompt

Turn off demo mode and require sign-in. Remove the read-only demo banner and the message that blocks changes. Every screen should require a signed-in account. Someone who is not signed in sees a sign-in page and nothing else: no records, no lists, no data of any kind. Also set the application's visibility to private, and tell me where that setting lives so I can confirm it myself.

Confirm this yourself by opening the address in a private browser window. If you can see anything without signing in, it is not closed.

Limit who can create an account

Goal. Requiring sign-in is not enough if anyone can sign themselves up.

Sample prompt

Restrict account creation. Only people with an email address at [yourmuseum.org] can register, and only an administrator can invite anyone else. Someone who tries to sign up with any other address is refused with a plain message, not an error.

Add editors and viewers

Goal. Volunteers, interns, docents and board members usually need to look without changing anything.

Sample prompt

Add two levels of access. Editors can do everything they can do now. Viewers can see the records, the calendar and search, but cannot create, edit or delete anything, and cannot open the settings screen. Controls that a viewer cannot use should be hidden rather than shown and disabled. Show which level a person has when they are signed in.

Important: enforce this on the server, not only by hiding buttons in the interface. A viewer must not be able to change data even if they find a way around the screen. Tell me how you enforced it.

Add an administrator level

Goal. Someone has to manage accounts, and it should not be only one person.

Sample prompt

Add an administrator level above editor. Administrators can invite people, remove people, and change anyone's access level. Add a screen listing everyone with access, their level, and when they last signed in. The application must always have at least two administrators. Refuse to remove or downgrade the last one.

Make uploaded files private

Goal. On many platforms an uploaded file gets its own web address that works for anyone who has it, even when the application is private.

Sample prompt

Tell me first: are uploaded files currently stored publicly? Can someone who is not signed in open a file if they have its address? If they can, change every upload in the application to private storage that requires a signed-in account to open. Do not break the existing files. Migrate them.

Ask the question before the change. If the answer is that files are already private, you have saved yourself a build.

Hide sensitive fields from viewers

Goal. Some combinations of field are worth protecting. Object locations next to insurance values is the obvious one.

Sample prompt

Hide [insurance value and storage location] from viewers. Editors and administrators see them normally. Leave them out of anything a viewer exports or prints, not just the screen.

Record who changed what

Goal. With several people in one system, “who moved this to Gallery B” becomes a real question.

Sample prompt

Record the person and the time whenever anything is created, edited or deleted. Show the last change and who made it on each record's page. Give administrators a screen listing recent changes across the whole application, filterable by person and by date. This record cannot be edited or deleted by anyone.

Let people leave

Goal. Staff turnover is the normal case, not the exception.

Sample prompt

When an administrator removes someone, their account loses access immediately, but everything they created stays, and their name remains on the change history. Never delete a person's records along with their account.

Look and feel

Each template carries one visual identity. Replace it with yours.

Use your own colors and type

Goal. Match the application to your institutional identity.

Sample prompt

Change the application's colors and fonts to match our institutional identity. Primary color [#1B3A5C]. Background [#FAF8F5]. Text [#22201E]. Headings in [Libre Baskerville], body text in [Source Sans Pro], both from Google Fonts. Keep the status colors as they are: they carry meaning, not decoration.

Ask for one token system and no hardcoded colors in components. Otherwise your next change will only take effect on half the screens, and you will spend a build finding the other half.

Rename things to match your vocabulary

Goal. If your museum says Zones rather than Spaces, or Visits rather than Sessions, the software should too.

Sample prompt

Rename [Spaces] to [Zones] everywhere it appears: labels, filters, column headers, page titles, empty states, and the navigation menu. Existing data must be preserved.

Renaming a word that is also a verb somewhere in the interface is harder than it sounds. Ask the assistant to list every place the word appears before you commit to a build.

What costs money

These templates are deliberately built to run on a free account.

Knowing where that ends saves an awkward conversation later. Plan terms are set by the platform, not by these templates, and they can change.

What runs on a free account

Everything in every template here. All the record keeping, the workflows, the calendars, search, documents, dashboards, exports and printing. There are no AI features inside the running applications, which is deliberate. AI calls consume usage credits, and an application that burns credits every time someone opens it is not free in any meaningful sense.

AI built this software. AI is not in this software. Those are different things and worth keeping separate in your head.

Needs a paid plan

Anything that happens when nobody is looking at the screen. Emailing the person whose task is overdue. A Monday morning digest of the week ahead. Syncing into a shared calendar so changes flow both ways. Pulling data in from another system on a schedule. These all require server-side work, which platforms charge for.

Also: AI assistance inside the app, such as drafting label copy, summarizing a condition report, or reading back through your own notes and proposing changes. And importing data automatically from your collections system rather than through an exported file.

Needs outside help

Connecting directly to a collections management system’s database, anything touching payment processing, and anything your IT department requires a security review for. Not impossible, but not a weekend project either.

Before you commit real data. Ask your IT department where the data will live and who can reach it. Ask what happens to this tool when you leave. Keep your prompts and your change log somewhere that is not your own laptop. Software one person built is software that breaks when that person goes, unless the method is written down too.

Part Two

The templates

One section per template. Each opens with what the thing is for and what is already there, then gives examples you can adapt. Change the words in brackets to suit your museum.

Everything in these sections needs an actual build, unless it appears under “before you ask for anything.”

The Exhibition Checklist

For tracking objects through an exhibition, from the first checklist to the moment the last crate goes back.

The nouns. Exhibitions hold Sections. Sections hold Objects. Objects sit in Spaces. Each object carries a set of to-dos, each with its own state. Milestones sit on the exhibition’s calendar. Documents attach to objects, exhibitions and spaces.

Before you ask for anything

These are already adjustable in the settings screen. Changing them takes seconds and costs nothing.

The to-do types and the stages each one moves through.
Object statuses, ownership types and tags.
Departments.
Document types.

And these are already built, so ask about them before asking for them: printing an object sheet, exporting the checklist, the related-documents trail that surfaces a space’s paperwork on an object’s page, and the search that matches accession numbers however they are punctuated.

Add fields your collection actually needs

Goal. The object record covers the basics. Yours probably needs more: accession source, insurance value, a conservation flag, a location within a case.

Sample prompt

On the object record, add fields for [insurance value, conservation priority, and current storage location]. Insurance value should be a number. Conservation priority should be a short list I can edit in settings. Storage location is free text. Show all three on the object page, and let me filter the checklist by conservation priority.

Adding a field is cheap. Adding one to every screen is not, so say where you want it to appear.

Make the card show what you scan for

Goal. The object card shows a fixed set of details. If you scan for lender rather than medium, change it.

Sample prompt

On the object cards in the checklist view, replace [medium] with [lender name] so I can see at a glance which objects are loans and from where. Keep the compact and full card layouts otherwise unchanged.

Track something that is not an object

Goal. Exhibitions contain things that are not in the collection: reproduction mounts, AV equipment, interactives, borrowed furniture.

Sample prompt

I need to track non-collection items in an exhibition: [AV equipment, reproduction mounts, and borrowed furniture]. They need a name, a source, a cost, and a status, but not accession numbers or credit lines. They should appear in the checklist alongside objects but be visually distinct, and I should be able to filter them out.

Change several objects at once

Goal. Reassigning forty objects to a different space one at a time is how people stop using software.

Sample prompt

Let me select multiple objects in the checklist using checkboxes, then change their [space, section, or object status] all at once. Show how many are selected, confirm before applying, and let me clear the selection easily.

Add a person responsible to each to-do

Goal. Knowing something is unfinished is less useful than knowing whose desk it is on.

Sample prompt

Add an "assigned to" field to each to-do on an object. It should be a short editable list of staff names rather than free text, so it stays consistent. Show it on the object page, let me filter the checklist by it, and add a section to the dashboard showing my own outstanding to-dos.

Require a note before something can be marked blocked

Goal. “Blocked” with no explanation is a dead end for whoever picks it up next.

Sample prompt

When someone sets a to-do to a blocked state, require them to enter a note explaining why before it saves. Show that note prominently wherever the blocked to-do appears, including on the dashboard.

Record the constraints that ruin installs

Goal. Spaces already hold dimensions, environmental specs and elevator measurements. Add whatever else has bitten you.

Sample prompt

On spaces, add fields for [door width, floor load limit, and available power outlets]. These are for reference only. Do not compare them against anything or show warnings. I want the numbers next to each other so a person can decide.

Work backwards from opening night

Goal. Every exhibition runs the same countdown. Stop re-entering it.

Sample prompt

When I create a new exhibition and set its opening date, automatically create a standard set of milestones working backwards from that date: [label copy due 8 weeks before, condition reports complete 6 weeks before, crates delivered 3 weeks before, install begins 2 weeks before, press preview 2 days before]. I should be able to edit or delete any of them afterwards, and edit the standard set in settings.

This is the single change most likely to save real time. Worth doing early.

Start a new show from an old one

Goal. Rotations and annual exhibitions repeat. So does the setup work.

Sample prompt

Let me duplicate an existing exhibition as the starting point for a new one. Copy the sections, the milestone structure, and optionally the object list, but give it new dates and a new title. Ask me which parts to copy before it does anything.

Keep a decision trail

Goal. The record of who decided what, and why, is the part no vendor builds and the part you will be asked for years later.

Sample prompt

Add a decision log to each exhibition. Each entry records the date, what was decided, who was in the room, and the reasoning. Entries cannot be edited after 24 hours, only added to. Show the log on the exhibition page and include it in the printed exhibition summary.

The Program Recipe Box

For museum education. Write a program down once as a recipe, schedule it, and record what actually happened afterwards.

The nouns. A Program is a recipe: what it needs, what happens in it, and what tends to go wrong. A Session is one occasion when you run it. Resources are the rooms, kits, vehicles and equipment a program needs. Staff have roles and are qualified for particular programs. A Debrief is what you record afterwards. Documents attach to any of them.

Two things make it different from a room-booking tool. The requirements travel with the program rather than the booking, so scheduling a gallery tour already knows it needs Gallery 2 and one educator. And the debrief loop turns what you learned running it into part of the recipe, so the next person does not rediscover it.

Before you ask for anything

These are already built. Ask about them before asking for them.

Duplicating a program. Open any program, use the menu beside Edit. It copies the whole recipe, including the things that go wrong, and leaves the original’s sessions alone.
A debrief question for one program only. Edit the program and add a custom question at the bottom. It appears on debriefs for that program and nowhere else.
Clash detection. Five checks run on every session: a double-booked room, a double-booked person, a room that cannot be reserved, nobody qualified to run it, and a group size outside what the program takes. Nothing is ever blocked; you are told and you decide.
Setup and teardown time. Counted as part of those clashes. A session needing 45 minutes of load-in will collide with one that starts 30 minutes after it ends.
Printing. A run sheet for one session, a recipe sheet for a program, and the calendar in list, week or month form.
Exports. The calendar as a .ics file that imports into Google Calendar or Outlook, and any list as a spreadsheet.
Attachments. Facilitator scripts, handouts, floorplans and equipment manuals, on programs, sessions, resources or debriefs.

Add fields your programs need

Goal. The recipe covers timing, materials, steps and what goes wrong. Yours may need more.

Sample prompt

On the program record, add fields for [curriculum standards met, accessibility accommodations, and the grade bands it suits]. Show them on the program page and in the printed recipe sheet. Let me filter the program catalog by grade band. Accessibility accommodations should be a list I can edit, not free text, so the same words get used every time.

Sessions that repeat

Goal. The homeschool group comes the first Tuesday of every month. Entering nine sessions by hand is how people stop using software.

Sample prompt

Let me schedule a repeating session: pick a pattern (weekly, or monthly on the same weekday), an end date, and create them all at once. Each one must be independently editable and deletable afterwards. Changing one must not change the rest. Check for conflicts across the whole series before creating anything, and show me what it found.

Who is actually available

Goal. The app knows who is qualified to run a program. It does not know who works Tuesdays.

Sample prompt

Add a weekly availability pattern to each staff member — which days and rough hours they normally work. When I assign someone to a session outside their availability, warn me the same way a double-booking is flagged. Do not block it. People swap shifts. When I am picking staff for a session, show who is available first.

Change the debrief questions

Goal. The five questions in the template are ours, not yours.

Sample prompt

Change the debrief questions to: [list yours here, with the four answers for each]. Keep them to four answers with no middle option, so an answer always points one way or the other.

If debriefs already exist, do not reorder or reword the answers on a question that has been used. A debrief stores which answer was chosen by its position, so moving them silently changes what past answers mean, with no error and no visible sign. Adding a new answer at the end is safe. Adding a new question is safer.

The same school, four times a year

Goal. The group name on a session is free text. Lincoln Middle School gets typed four different ways and you can never pull their history.

Sample prompt

Add a list of Groups: name, contact person, email, phone, and notes. When I schedule a session, let me pick a group from the list instead of typing a name. On a group's page, show every session they have booked, past and upcoming. Keep the names already typed on existing sessions. Where one clearly matches a group I create, link it. Leave the rest as they are.

This is the most-requested change to this template, and the one that changes the most about how it feels to use.

What this template deliberately leaves out

Booking by the public. There is no registration form and no ticketing. That is a different kind of software, and several vendors sell it.
Email. Nothing is sent to anybody, ever. Confirming a booking with a teacher needs a paid plan.
Two-way calendar sync. You can download the calendar and import it. Changes made here will not flow into Google Calendar afterwards, and changes made there will not flow back.

The Attendance Analyzer

For understanding the shape of your own attendance. Feed it your history; it reports when visitors come, what admission actually yields, and what a price change would have to survive to be worth it.

The nouns. An AttendanceDay is one open day with counts by visitor type. A Segment is a visitor type with its own price and label — Adult, Senior, School Group, and so on. A Price is what you charged during a particular date range. A CalendarEvent is a school holiday, a city event, or anything else that affects your pattern. A MembershipSale is one membership sold or renewed. A DayContext is a written note on a specific day — what made it unusual, what you noticed.

Every number in this app is arithmetic you can check by hand. There is no AI inside the running application. That is deliberate: the value is in numbers that are auditable, not ones that are plausible.

Before you ask for anything

These are already built. Ask about them before asking for them.

Importing from a spreadsheet. Data → Import. Accepts CSV or tab-separated files from your ticketing system or a spreadsheet you keep by hand. Set up your visitor types first — if you import before the types are configured, the import will report success but store nothing.
Pasting a school or city calendar. Data → Calendar. Paste any plain-text calendar — an email from the district, a copied webpage, a list of dates. The app reads it and pulls out the date ranges automatically.
Filtering by visitor type. The Overview, Patterns, Projection, and Revenue screens all have a visitor-type filter. Every figure recalculates.
The price tester. Projection screen, bottom. Enter any proposed price for any or all of your paid visitor types. It shows the break-even threshold for each one, and a combined threshold when you change more than one type at once.
Marking a day as unusual. Daily Log, on any day row. The eye icon marks that day as excluded from pattern analysis. It still counts in your totals. Use it for the day the pipe burst, not the day it rained.
Exporting your data. Download button on Overview, Daily Log, and Revenue. Nothing is uploaded; the file is built in your browser and saved directly.
The trailing-trend overlay. Overview, Trend button (visible on Year, 2 yr, and All views). A flat line means zero net growth regardless of seasonal swings.

Set up visitor types first

Goal. The app needs to know your categories before it can map an import to them.

Go to Data → Visitor types & prices. Add each type — Adult, Senior, Youth, Member, School Group, whatever your ticketing system uses. Mark which ones are paid and which are free. Set the price for each era: if you raised prices in 2023, add two rows, one ending the day before the increase and one starting the day of.

If you skip this step and import first, the importer will report success and store nothing. The import log will say every row was written. The data will not be there. This is the most common first mistake.

Importing a file

Goal. Bring in your attendance history from a spreadsheet or a ticketing export.

Sample prompt

I have a CSV from [our ticketing system]. The columns are [Date, Adult, Senior, Youth, School, Member, Comp]. The date format is [MM/DD/YYYY]. Map each column to the right visitor type and import it. Tell me how many rows were written and how many were skipped, and why any were skipped.

What the projection does not know

Say this plainly when you share the numbers. The projection cannot see your exhibition schedule. A blockbuster last year against an empty gallery this year is the biggest swing most museums have, and nothing here accounts for it. Nor does it know about new hours, a closure for building work, a programme ending, or anything else you already know is changing. If you know it, factor it in yourself. The app does not.

What this app deliberately leaves out

How many visitors you would lose to a price increase. The price tester gives you the threshold; it does not model demand. Two price changes in a decade is not a demand curve.
Your exhibition schedule. Seasonal shape picks up weather and school calendars automatically. A blockbuster last year against an empty gallery this year is the biggest swing most museums have, and nothing here can see it coming.
Anything you already know is changing. New hours, a closure, a programme ending. If you know it, this does not.
Connection to your ticketing system. Data comes in through a file export, not a live link. A live connection needs a paid plan and some configuration.

A note on what breaks

Fifteen bugs were found and fixed during the six audit rounds that preceded this release. None were arithmetic errors. Every one was a problem in the wiring around the arithmetic: a missing way to delete something, a screen reading stale data mid-save, an unvalidated field writing a nonsense date to the database.

The arithmetic is the part you can check by hand, and it was right every time. What broke was the seams. Keep that in mind when you extend the app: test the paths that create and delete things, not just the ones that display them.

Where to start

Not with a template. Start with the thing that annoys you most, the spreadsheet you dread opening or the process you re-explain every year. Describe it to an assistant the way you would describe it to a new colleague. See what comes back.

The first thing you build will not be very good. Build it anyway. The skill being learned is describing your own work precisely, and that is worth having regardless of what you make with it.

The three templates here each solve a different problem:

The Exhibition Checklist — tracking objects and tasks through a show, from first list to last crate.
The Program Recipe Box — writing education programs down once and learning from them over time.
The Attendance Analyzer — understanding the shape of your own attendance and what your numbers actually mean.

Start with the one that matches the thing you currently track in a spreadsheet you do not love.

whatifmachine.ai/museums — free templates for small museums.

Financial intelligence for nonprofits

Product

Company