I built software that keeps track of the medical equipment in a hospital with two short prompts to Ninox AI: one to create the foundation and one to add an equipment overview. Below you'll find both prompts, ready to copy, along with what Ninox AI created each time. This is the fourth episode of Built in Ninox, the column where I pick an industry, describe what it needs in plain language, and show you how to build it yourself. This time, we're on the hospital ward.
One note before you start: our team keeps improving Ninox AI, so your result may look a little different from mine. The structure will be close, and you can always ask Ninox AI to adjust anything that doesn't fit.
Step 1: build the foundation
My first attempt was a single sentence: "I need something to manage the medical equipment in my hospital." Ninox AI replied with two quick questions about what to track and whether to add demo data. The prompt below already includes my answers, so you can skip the questions and get the same result in one go. On an AI-native low-code platform, plain language is all you need.
Here's the prompt to use:
I need something to manage the medical equipment in my hospital, with suppliers and warranties, maintenance and calibration, and repair requests reported by staff. Please add some sample data so I can see how it works.
Before changing anything, Ninox AI showed me the data model and waited for my approval. It proposed four linked tables: Suppliers, Equipment, Maintenance, and Repair requests. Every device connects to its supplier, and every maintenance entry and repair request connects to a device. So when a monitor fails in the ICU, I see its full history, its warranty, and who to call in one place. After a second approval, Ninox AI filled the tables with 4 suppliers, 12 devices, 12 maintenance entries, and 8 repair requests.
Every table came with search, sorting, filters, and grouping ready to use. When I opened a supplier, the record showed every device I'd bought from them with its serial number, category, and department, right inside the form. I could link more devices without leaving it.
Step 2: add an equipment overview
Tables work well for handling individual devices, but a hospital's technical team needs the big picture. So I asked for a dashboard.
Here's the prompt to use:
Add an equipment overview that shows total devices, devices out of order, and open repair requests, with charts of devices by status and by department, plus a calendar of the maintenance schedule.
Ninox AI listed every component it planned and built the page after my approval. The metrics show how many devices the hospital has, how many are out of order, and how many repair requests are open. Devices by status shows what's in service, under maintenance, out of order, or retired, and the department chart shows where the equipment sits, from the emergency room to the ward. Below that, a calendar lays out the maintenance schedule for the month.
Ninox AI also told me it had tested the dashboard queries but hadn't checked how the page looks on screen. I took a quick look myself, which I'd recommend you do too. When you move to real equipment data, delete the demo records first.
One setting worth knowing
Hospitals handle data with care, so it matters that building and data access are two separate decisions in Ninox. In the workspace settings, one switch controls whether Ninox AI can read, add, change, and delete records.
With the switch off, Ninox AI can still build software and add sample data, but it doesn't access your records. With the switch on, every change still needs your confirmation, and each user's own access rights still apply.
Prompts to take your equipment build further
My two prompts give you a working foundation for equipment management. From here, you can keep expanding the same build in plain language. These are the prompts I'd try next:
Show the maintenance title on each calendar entry.
Add a form so ward staff can report a faulty device in seconds.
Add a Kanban board of repair requests by status.
Only let each department see its own devices.
Add a files field to equipment so I can store manuals and service reports with each device.
Add a signature field so technicians sign off on completed maintenance.
And because Ninox is a low-code platform, you never need to write a line of script to build what you've seen here, though anyone on your team who knows scripting can add custom logic when a process calls for it.
The best part of starting on a low-code platform is that nothing here is fixed. Every table, field, and view can change as your hospital adds devices, departments, or new service routines.
This is how much time it took me to build all of this: 2 minutes, 16 seconds.
Take the next step.
