Admin Panel

Every published Proyecta app ships with an admin panel — a private, sign-in-gated back office where you manage your content and form submissions without touching code.

Your app’s public face is bespoke and brand-specific. Behind it, every app needs the same boring-but-essential back office: a place to edit the content, review the leads, and run the day-to-day. Proyecta builds that for you from schema-driven, template-owned components, so it stays consistent and correct across every app — and so you never wait on the AI to hand-roll a CRUD screen.

What you can manage

Section	What it does	Status
Content	Create, edit, publish, and archive entries in each of your collections	Available
Form submissions	Review, mark read, and archive submissions from your forms	Available
Commerce orders	Review and fulfil orders from your storefront	Available
Members / users	Manage the people who have signed in to your app, and their roles	Available

Which sections you see depends on what your app does — the panel reads your app’s live shape and renders only what applies. An app with no storefront has no Orders section.

Who can get in

The admin is RBAC-gated. A visitor must be signed in with an admin account to see it — every admin action is enforced on the server, not just hidden in the UI.

Admin is granted to the email you designate when the app is created, matched against the identity provider’s verified address. It is not handed to whoever signs in first — on a normal app, everyone else signs in as an ordinary user, including the first visitor. See Users & Auth for how sign-in works and how roles are assigned.

The building blocks

The panel is assembled from template-owned components. You don’t write these — they’re part of every app — but it helps to know the main ones:

Component	What it gives you
`CollectionManager`	A full admin screen for one collection: a searchable, sortable list plus an auto-generated create/edit form. One per collection.
`SubmissionsInbox`	The forms inbox: New / Read / Archived tabs, an unread badge, and a detail view per submission.
`AdminShell`	The chrome around it all — a collapsible sidebar and top bar that ties the sections together.

CollectionManager: auto CRUD from your schema

CollectionManager reads a collection’s schema and builds the whole editing experience with near-zero hand-written code:

Lists your entries in a table with a status badge, search, and a New button.
Auto-generates the form from each field’s type — text fields become inputs, long text becomes a textarea, numbers become number inputs, on/off values become switches, choice fields become dropdowns, dates become date pickers, references become a picker over the linked collection, and image fields get an upload button (with a media-library picker and a paste-a-URL fallback).
Saves as a draft first — publishing is an explicit, separate action, so nothing goes live by accident. You can also unpublish or archive an entry (archive is a soft delete — it disappears from the app and the panel but isn’t destroyed).
Handles one-off content too: singleton collections (like your business info) render the form directly, with no list.

Editing is genuinely no-code: you (or anyone you make an admin) change the words, prices, photos, and hours from the panel, hit publish, and the live app updates.

Note: Commerce products are managed with the commerce tools, not in a CollectionManager — even though the catalog is content. See Commerce.

How the admin gets built

You don’t ask for it, and the AI doesn’t hand-roll it. The panel is a self-configuring “standing admin”: a fixed /admin baked into every app’s template that reads your app’s live content schema and capability configuration and renders itself — with zero AI wiring. Add a new collection later and it appears automatically, no rebuild needed.

Beyond content and form submissions, sections appear for whatever your app actually does — orders and returns, bookings and scheduling, members and roles, a media library, email and push. You get the ones that apply to your app and none of the ones that don’t.

Because it’s template-owned, it stays consistent and correct across every app, and it can’t drift or break when the AI edits your public pages. If you later want the console itself changed, ask — that’s an explicit edit, not something the first build improvises.

Common patterns

You never have to ask for the admin panel itself — every app ships with it, and new collections show up there on their own. What’s worth asking the AI for:

"Add a 'featured' toggle to my services so I can choose what shows on the homepage." — new fields appear in the admin automatically.
"Make the headline and hours on my homepage editable from the admin." — moves hardcoded copy into content.
"Build me a back-office page showing this week's bookings at a glance." — a bespoke page composed from the same building blocks.

Content Management — the collections and entries the admin edits.
Forms — the source of the submissions inbox.
Users & Auth — how sign-in works and how the admin role is granted.
Commerce — managing your catalog and orders.