The builder is inside the product
Studio is not a separate tool you export from. It is a mode in the system your staff already use. Toggle from the table to the structure behind it, change the shape, toggle back. The people who understand the workflow are the people who change it.
No sandbox to request. No consultant to schedule. It is the same screen your admin opens.
Data on one side, structure on the other
Most systems separate these by a vendor. Here they are separated by a toggle — and only builder roles see the toggle at all.
Data mode
Where the work happens
The everyday view. Records in a table your team can search, filter, page through and edit. This is what staff see, all day, and it is generated entirely from the model definition.
- Auto-rendered tables and forms
- Paginated by default
- Every write validated and audited
Structure mode
Where the shape changes
The builder view. The same model, seen as its definition: fields, types, rules and order. Change it here and Data mode re-renders around it. One toggle apart, not one system apart.
- Add, edit, reorder, remove fields
- Set types, options and relations
- Builder roles only
That toggle is the entire distance between using your system and rebuilding it.
Here is Structure mode, running now
Add a field, drag the order around, delete something. The form on the right is generated from the list on the left — exactly as it is in the real thing.
Model structure
4 fields- Full nametextreq
- Phonephonereq
- Date of birthdate
- Blood groupselect
Add a field
In the real Studio this saves to your ModelDefinition and every user sees it on their next render. No deploy, no migration.
A model, from nothing, in five moves
There is no wizard, no template gallery to fight, and no step where you wait for someone else. This is the whole process.
Name the model
A label your team will read and a key the engine will use. The label is yours to change forever; the key is set once, because your records are addressed by it.
Add the fields you keep
Pick from eighteen types. Give each one a label, mark the ones that are required, set select options, and point relation fields at the models they belong with.
Put them in the order you work in
Reorder until the form reads like the conversation your front desk actually has. The order in the definition is the order on the screen — there is no separate layout to maintain.
Save
That is the deploy. The definition updates, the form and table re-render, and the REST endpoint for your new model is already answering.
Change it next week
Because you will. A protocol shifts, a regulator asks for something new, a consultant joins with a different way of charting. Open Studio, adjust, save. The cost of a change stays flat.
Edit in place, not in a config file
Every field is a row you can act on. Add one at the bottom, drag one up, retype one, retire one. The four verbs cover everything a schema ever needs from you.
- Add — pick a type, name it, set its rules
- Edit — change the label, type, options or required flag
- Reorder — the definition order is the screen order
- Remove — stops collection, keeps the history
- The field key is immutable, like the model key
- Every edit is audit-logged with who and when
- key
Full name
full_name · text
- key
Phone
phone · phone
- 4 options
Blood group
blood_group · select
- new
Allergies
allergies · textarea
For the thing that only happened once
Some records carry a value no model should have a field for. A note from a visiting specialist. A number the insurer asked for this quarter and will forget next quarter.
Turn on allowExtraFields and records of that model can carry ad-hoc key/value pairs beside the defined ones. The defined fields keep their validation. The extras are yours to use without asking the model’s permission.
- Per-model switch, off unless you turn it on
- Extras live on the record, next to the defined values
- Defined fields keep validating exactly as before
- Promote an extra to a real field once it stops being a one-off
Record · patient / 4KX92
Two of these are not in the model. They are on the record anyway, because the record is where reality happens.
The undo button for a bad afternoon
Some ERPs ship with default models. If you delete one you needed, restore defaults re-seeds them — and it is safe to press twice, because pressing it twice does nothing extra.
Re-seeds what the portal shipped with
The default model set for that portal comes back, exactly as it was provisioned. Not a backup of your edits — the defaults, restored.
Idempotent, on purpose
Run it once or run it five times; the result is the same. It will not duplicate a model that is already there, and it will not silently reset one you have since customised.
Your own models are not touched
Anything you built yourself is outside the default set, so it is outside the restore. This is a floor, not a rollback.
Where defaults come from
Seeded on connect
Start blank, by design
A blank portal has no defaults to restore. That is not an omission — those specialities vary too much for a default to be right for anyone.
Not everyone gets a hammer
Studio is powerful because it changes the shape of your data. So it is gated to builder roles, and every other role never sees the door.
Account owner
Owns the tenant
Portal admin
Builder role
Clinical & desk staff
Per-model grants
Doctor
Practitioner surface
Patient
Platform-level account
“Use records” is itself narrowed per person — specific portals, specific models, specific create/read/update/delete rights. Grants are read from the database on every request, so taking one away takes effect on the next one.
A Ward means nothing to a lab
Studio is scoped to the portal you are in. Each ERP carries its own models, its own builders and its own defaults — under one account, one login and one audit trail.
Hospital
Patient · Doctor · Appointment
Clinic
You define them
Dental
You define them
Lab
Test · Order · Sample
Diagnostics
You define them
Pharmacy
Medicine · Batch · Prescription
Ambulance
Vehicle · Dispatch · Trip
Blood Bank
Unit · Donor · Donation
Doctor
Consultation · Prescription · Schedule
Patient
Record · Appointment · Report
The models no vendor shipped you
These are not roadmap items or add-on modules. They are afternoons in Studio. Every one is just fields with types, which is all any of them ever were.
Antenatal visit
Obstetrics
- Gestational age · number
- Fundal height · number
- Foetal heart rate · number
- Risk flags · multiselect
Refraction
Ophthalmology
- Eye · select
- Sphere · number
- Cylinder · number
- Prescribed by · relation
Implant log
Orthopaedics
- Implant type · select
- Serial number · text (unique)
- Surgeon · relation
- X-ray · file
Session
Dialysis
- Machine · relation
- Dry weight · number
- Duration · time
- Complications · textarea
Dose
Immunisation
- Vaccine · select
- Batch · relation
- Given at · datetime
- Next due · date
Equipment service
Operations
- Asset · relation
- Serviced on · date
- Vendor · text
- Certificate · file
None of these required us to know your speciality.
That is the test of the design. If the engine had to be taught about dialysis, it would still be waiting to be taught about the next thing.
You cannot break this in a way that loses data
Studio hands real power to non-developers. That is only reasonable because the engine underneath refuses to destroy anything.
Removing a field keeps the values
The field leaves the form and the table. The data stays on the records. Put the field back and it reappears with its history intact — because the removal was a change to the definition, not to the records.
Medical records are soft-deleted
Delete on a clinical model marks the record, it does not erase it. Recovery is a matter of policy rather than a matter of backups and hope.
Model edits are audited too
Who added the field, who reordered it, who turned on allowExtraFields — recorded in the same append-only log as every record change, and editable by nobody.
Keys are immutable for a reason
The model key and field keys cannot be renamed once records exist. Labels change freely. The one thing you cannot do is quietly move the address your data lives at.
The model you just built has an API
You did not ask for it and nobody wrote it. Save a model in Studio and it is live at /api/v1/data/:modelKey with the same auth, validation and audit as the screen you built it on.
What people ask before they touch it
Mostly about what happens when they get it wrong. Fair question — here are the honest answers.
Builder roles only. Account owners and portal admins can reshape models; the staff who use those models every day cannot change them. It is a separate capability from create/read/update/delete on the records themselves, which is how it should be.
Build your first model on the call
Bring the register you keep in a spreadsheet. We will have it modelled before the demo ends.
Multi-country by design · tenant-isolated · every change audit-logged