What to look for in makerspace management software

Every tool in this category will show you a feature grid, and every grid will have the same rows: equipment, bookings, members, training, billing. The grids are not useful. They are written by the vendors, and any system can claim a row by shipping something nominally in that shape.

What actually predicts whether a system works is narrower and more awkward to ask about. Below are the questions worth asking on a demo call, and why each one matters more than it looks.

1. Does the pricing model punish you for growing?

Ask exactly how the bill changes when your membership doubles.

A lot of tools in this space price per member or per user seat. That is fine for a small community shop with a stable roster. It is actively harmful for an academic makerspace, where the entire user base turns over annually and the whole point is to get more students through the door. Under per-member pricing, every new student is a line item, and the predictable result is that programs quietly stop creating accounts for casual users — which means the records that were supposed to be the source of truth are now incomplete by design.

Watch for the same problem in a second place: per-device or per-equipment fees. A tool that charges monthly per tracked machine gets expensive precisely as your tracking gets good.

The question to ask: “What does this cost me at 500 members and 40 machines, all in?” Make them do the arithmetic on the call.

2. Is access control real, or is it a checkbox?

“Access control” means two very different things.

The weak version is a database flag: the system knows Priya is certified on the laser. Whether she can physically turn it on is a separate, human problem — a staff member checks a screen, or does not.

The strong version is a physical interlock: the machine is wired to a controller, and the controller will not energise it without a valid credential. The record is the enforcement.

Both are legitimate products. But only one of them actually prevents an untrained person from running a machine at 11pm, and if that is the problem you are buying to solve, a flag in a database does not solve it. Ask which one you are being shown.

Follow-up questions that separate the two quickly:

• What happens when the network goes down? (A machine that fails open during an outage is not an access control system. A machine that fails closed and strands members is not one either — ask what the actual behaviour is.)
• Can an instructor open a bank of machines for a class period without issuing permanent access to everyone?
• How does a member start a session at the machine itself?

3. Where does training actually live?

Nearly every system will tell you it tracks certifications. Tracking a certification is the easy half.

The harder questions:

• Can you author the training in the system, or only record that it happened elsewhere? If it is only a record, you still need somewhere to build and deliver the content, and you have two systems to keep in sync forever.
• Can it import what you already have? Institutions often have existing safety content in SCORM packages. Rebuilding that from scratch is a real project cost that will not appear on any quote.
• Do prerequisites chain? Real training pipelines are not flat lists. Shop orientation gates the wood shop, which gates the CNC. And they are not always all-of — sometimes any one of three prior credentials qualifies you. If the system only supports a flat list, you will end up managing the graph by hand.
• Do credentials expire, and what happens when they do? An expiry that emails someone is a reminder. An expiry that pauses machine access is a control.

4. What happens to a machine’s history over five years?

This is the question that separates asset management from a maintenance to-do list.

When a printer fails for the third time, the useful question is what was done the previous two times, by whom, and whether the same part was replaced. That is only answerable if service actions attach to the machine record rather than to a completed task that scrolls out of view.

Ask to see:

• The full service history of a single machine, oldest to newest
• Whether completed maintenance is still attributable a year later (who did it, when, against which schedule)
• Whether the system can tell you that a particular machine fails more often than its siblings, without you noticing manually

And ask about fleets specifically. If you run eight identical printers, a system that makes you create and complete the same maintenance task eight separate times is going to lose to a spreadsheet within a semester, because the spreadsheet is less work.

5. Can you get your data back out?

Ask for this concretely, not as a policy question:

• Can an administrator export every core record to CSV or Excel, today, without filing a support ticket?
• Is there a documented API that reads the same data the interface reads?
• If you left in three years, what exactly would you take with you?

A vendor that answers this comfortably is telling you something about how they expect to keep your business. A vendor who gets vague is telling you something too.

6. How does it handle the systems you already run?

Nobody replaces everything at once, and a makerspace is never the only system on campus. The integration questions that come up in practice:

• Identity. Can members sign in with existing institutional credentials (SAML/SSO)? Does deprovisioning propagate, or does a departed student keep an account forever?
• The card office. Badge numbers usually live in a system that has no API and never will. Can the tool deliver a scheduled file to an SFTP endpoint, with columns you choose?
• Hardware in the building. Tool control systems, lockers, and label printers frequently cannot accept an inbound connection at all. Is there an outbound-only path, or does integrating mean opening a firewall?
• Events. When a credential is issued, can another system find out immediately — or does it have to poll on a timer and hope?

If every answer is “we have an API,” probe further. An API is one integration pattern out of several, and it is the wrong one for at least two of the cases above.

7. Does it work where the work happens?

Most of the actual work in a makerspace happens standing in front of a machine, not sitting at a desk. A system that requires a return trip to a computer to log what just happened will be updated retroactively and inaccurately, or not at all.

Ask whether staff can complete maintenance, approve a purchase, and check a member’s credentials from a phone — and whether members get the same app or are expected to use a separate portal. Then ask whether the mobile app costs extra.

8. Who is the buyer this was built for?

This one is soft, but it is the most predictive question on the list.

Software carries the fingerprints of whoever it was built with. A tool designed around print studios will have excellent print-job accounting and a vague notion of a semester. A tool built with a university will have credential prerequisites, student-worker shift rotas, and purchase-order billing — because those were non-negotiable for the people it was built alongside.

Neither is better in the abstract. But one of them will match your calendar, your procurement process, and your liability posture, and the other will require you to work around it indefinitely.

Ask directly: “Who did you build this with, and what did they make you change?” The answer tells you more than the feature grid.

---

A short version

If you only ask five things:

1. What does this cost at 500 members and 40 machines?
2. Does a credential physically gate the machine, or just record permission?
3. Can I author training here, or only record it?
4. Show me one machine’s full service history over five years.
5. Who was this built with?

---

MakerOps is makerspace management software built alongside a university makerspace — equipment and fleet maintenance, a native training LMS with SCORM import, credentials that physically gate machines, inventory, purchasing, and scheduling in one system, with unlimited student accounts on every plan. See the features or book a walkthrough.