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.
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.