Customize the admin
Your back office is a front end you control
The screens your team works in are code in your repository — not a product we rent you a seat in. Build the reports we never thought of, and keep every upgrade.
In most business software the admin is the part you cannot touch. You get the screens the vendor built, the reports the vendor imagined, and a feature request form for everything else. The answer to “it does not do the thing I need” is to wait, or to leave.
Here it is the same kind of front end as your public website: pages in your own repository, reading the same API. Which means the answer to that question is usually build it — and you do not need us to agree.
One rule, and a machine that enforces it
Add beside ours → safe forever
A screen you create is yours. Upgrades never touch it, never conflict with it, and never need to know it exists.
Edit ours → you drift, and you are told
Allowed — it is your code. But it is a file we keep improving, so our next change collides with yours. The checker names it the same day rather than at upgrade time.
167 framework files are under that contract on this site. 0 of them have been edited, next to 50 files of our own custom work — which is the whole point: the limit is not how much you change, it is where.
What people actually build
Reports we never thought of
The margin breakdown your industry lives by, the weekly sheet your operations manager rebuilds by hand every Monday. A new screen in your repository, using the same components and the same data.
Extra CRM screens and views
Your pipeline the way your team actually sells, not the way a generic CRM assumed. Add the view beside ours rather than fighting ours into shape.
Internal tools only you need
The compliance checklist, the depot handover, the thing that exists because of one contract. It does not have to be a feature anyone else wants.
Your own look
Typography, radius, palette and dashboard themes are configuration. The admin can look like your company rather than like our demo.
What costs you, stated plainly
Nothing here is forbidden. It is your repository and you can change any of it. These are the choices that have a price, and you should know the price before you pay it.
Editing a screen we maintain
You can. It is your code. But that file is one we keep improving, and once you have changed it our next improvement collides with yours. Copy the pattern into your own screen instead and you keep both.
Changing shared machinery
The component kit, the API client, the auth middleware. These are the parts every screen leans on, and they are content-hash locked precisely so a change here is loud rather than silent.
How you find out
Not months later. One command reports how many framework files have been edited and names them, and it runs in your own checks. Drift is a fact you are told, not a surprise you discover at upgrade time.
A real one, on this site
We built a custom operator screen to prove this rather than assert it: an upgrade-health report, added the way any customer would add one, using the shipped components. After it existed, the checker still reported zero framework files edited.
It is behind a login, because it is an operator screen. The public measurements it shows — and the commands that reproduce them — are on the research page.
Common questions
Can I change the admin screens my team uses?
Yes. The operator app is code in your own repository — the same kind of front end as your public site, calling the same API. You can restyle it, add screens to it, and build reports and internal tools we never imagined, without asking anyone.
Will customizing the admin stop me getting updates?
Not if you add your own screens beside ours, which is the supported path — those are never overwritten and every upstream release still merges cleanly. Editing a screen we maintain is the case that costs you: our next improvement to that file then collides with your change. A checker reports how many framework files have been edited and names them, so you always know where you stand rather than finding out at upgrade time.
Can I build my own reports?
Yes, and this is the most common reason to touch the admin at all. A report is a page in your repository using the shipped components and the same data your other screens read. You own it, you support it, and it survives every upgrade because it is yours rather than a modified copy of ours.
Can I suggest improvements to the platform itself?
Yes — email us and describe it, or share the files. Improvements that belong in the foundation get built into it, and every site on the platform picks them up on its next upgrade. It is an evaluation, not a merge: there is no repository access to grant and no obligation on either side.
Built something the base should do?
Tell us about it. If you have built a report, a screen or an improvement you think every business on this platform would want, email us and describe it — or share the files and we will look at them. Things that genuinely belong in the foundation get built into it, and every site picks them up on its next upgrade.
To be straightforward about what this is: an evaluation, not a merge. There is no repository to be given access to and no queue to wait in. We may build something similar, differently, or decide it belongs in your site rather than the base — and we will tell you which. Please do not send anything you are not free to share.