The admin your client actually operates
The prototype worked in the demo. Three weeks later the client emails: "how do I add a status?", "can Dana see only her region?", "who changed this order?". The frontend was never the product. The admin is, and it is the part AI-built apps most often ship without. This guide is about what an operable admin needs and how to hand one over without becoming the client's IT department.
Why generated admin panels fail at hand-over
An admin generated from a schema is a CRUD table per model. It is complete on day one and wrong by day ten, because the business changes: a new status, a field nobody anticipated, a rule that sales cannot see costs. Every change is a ticket to you. The client either stops asking and works around the app in spreadsheets, or keeps asking and you stop being profitable.
What "operable" means
| Need | What it looks like | Who does it after hand-over |
|---|---|---|
| Change the shape | Add a field, a status, a dropdown option | The client, in minutes, no deploy |
| See it their way | Kanban for the floor, calendar for scheduling, table for the accountant | Each user picks a view |
| Let outsiders in | A form for customers, a portal for suppliers, no accounts | The client shares a link |
| Control who sees what | Roles, per-board permissions, row visibility | The client, per person |
| Automate the routine | Reminders, status-driven notifications, escalations | The client, from a builder |
| Answer "who changed this?" | Audit log per row | Built in |
| Approve things | Multi-step approvals with thresholds and substitutes | The client configures |
This is a product, not a feature list to generate. It is why TaskLite exists as the backend for AI-built apps: the admin is the platform, the frontend you build is optional.
The hand-over checklist
- Name things in the client's language. Rename boards and columns to the words they use ("Jobs", not "work_orders"). Your API keeps working through aliases.
- One view per role. Set a default view for each kind of user and save it. Nobody should start from a raw table.
- Three automations, not thirty. The ones that remove a daily chore. More come later, from them.
- Permissions before the first login. Roles for owner, staff, external. Test as each.
- One form and one portal. Even if the frontend covers it, the client will want to send a link to someone tomorrow.
- Show the audit log once. It ends most "who did this" conversations forever.
- Write the two-line rule. "To change the app, change the board. To change the website, call us." Put it in the welcome email.
Keeping your frontend stable
Your code reads endpoints by alias and columns by id, so the client renaming "Notes" to "Comments" does not break anything. A new column the client adds is invisible to your app until you expose it. A deleted column the endpoint exposes is the one change that hurts; mark those read-only in the endpoint and tell the client which fields the website depends on.
The economics
The client pays $3 per admin user per month to TaskLite. You charge for the build and, if you want, a support retainer that is now mostly quiet. The alternative, a custom admin at agency rates plus a maintenance contract, costs more than the app did. The REST API guide covers the endpoint side of this arrangement.
Frequently asked questions
- What if the client wants a feature the admin does not have?
- Then it is a frontend feature, built by you on the endpoints, exactly like before. The admin covers operations; your app covers what is unique.
- Can the client lock me out?
- They own the organization and can remove your access, which is how it should be. Keep your app key in their organization's app, not in yours.
- Can I white-label the admin?
- Logo, colours and the organization name are theirs; the product name stays TaskLite. The portals and forms carry their branding.