How to Build an Admin Panel Your Team Can Use Without Seeing Your Money

An admin panel is the private part of your site where the day-to-day work happens. It has three roles, and the middle one, Staff, handles requests, scheduling, and orders without seeing money, members, or settings.

Arturo runs a butcher shop in Zamora with two people at the counter. Ever since he added pickup orders to his site, things clicked into place: an order comes in, someone fills it, the customer picks it up. The problem was access. Since the only key that existed was his, he lent it out.

One Thursday, a kilo of skirt steak showed up at 34 pesos. Someone tried to fix a price, dropped a zero, and it stayed that way all afternoon. Arturo had two problems that day, not one: the wrong price, and no way to know who had changed it. And on top of that, with that same key, either of them could see the deposits.

What is an admin panel, and who should have access?

An admin panel is the private part of your site — the part your customers never see — where the day-to-day work happens: incoming orders, the schedule, requests, and the content you publish.

The question of who gets in doesn’t have one answer, it has three. And the split isn’t the one you’d expect: it isn’t decided screen by screen, it’s decided between serving customers and running the business. Arturo’s mistake wasn’t giving out access — it was that only one kind of access existed.

What are the three roles, and which one does your team need?

There are three, and here’s how the panel describes them. Member: “Just uses the app as a customer; doesn’t access the admin panel.” Staff: “Handles day-to-day work: requests, scheduling, and orders. Can’t see money, members, or settings.” Admin: “Full access: money, members, and app settings.”

Read that again and you’ll notice that almost your whole team is the one in the middle. The people at the counter don’t need to change prices or see how much came in; they need to see today’s orders and move them along. That role doesn’t exist as a courtesy — it exists because the alternative was handing over the same account that also issues refunds.

It’s not about asking people not to touch things. On the Orders screen, someone logged in as Staff can advance an order’s status and mark it as filled, but the button to log a payment and the receipt the customer uploaded simply aren’t there. Not greyed out — not there at all, and the server enforces it the same way even if someone tries to get in another way.

How do you give someone on your team access?

With a step that catches people off guard: first, ask them to log in to your own site with their email, once. The Members list doesn’t fill up by inviting people — it fills up when they log in. The panel says as much when it’s empty: “Once someone logs into your app, they’ll show up here.”

Once they show up, you open their entry, set them to Staff, and you’re done. Each row has three columns — Member, Role, and Last activity — so you also get a read on who’s actually using it and who logged in once and never came back.

There’s exactly one thing the panel won’t let you do, on purpose: remove yourself if you’re the only Admin. A warning pops up — “You can’t remove the last admin: the app would be left with no one to manage it” — and that’s where the attempt stops. It’s the door that keeps you from getting locked out of your own business.

And rule out the easy way out starting today, which is sharing a password. With one shared key, the history stops telling you anything (everything was done by “the owner”), and the day someone leaves, revoking their access means changing it for everyone.

What happens if someone changes something they shouldn’t have?

You see it, with a name attached. Every record — a cut in the catalog, a booking, an entry — keeps its own History: which version it is, which field changed and from what to what, and who made the change. When the change came from the system rather than a person, it says so plainly, “Automatic change,” instead of pinning it on someone.

There it is: the skirt steak price. Who, at what time, from 340 to 34.

The history has a limit worth spelling out: there’s no undo button. It tells you what it used to say; putting it back is a matter of going in and editing it again, copying the old value that’s right there in front of you. It’s a minute of work, but it’s manual.

That’s why hiding and deleting aren’t the same thing, even though in the moment they can feel like it. Flipping the “Visible on site” switch off removes something from the page without deleting it. “Delete” is stronger than it sounds: the entry “will stop showing up in the app and in this panel.”

Can you grant permissions screen by screen?

Partly, and not with a checkbox in the panel. The things your team handles as a queue — today’s orders, the schedule, requests someone has to approve — are the ones opened up to the Staff role, and that gets set when you describe your business, not later with a toggle.

Everything else starts out belonging to the owner and stays there unless you said your team handles it. And three things stay with the Admin no matter what: money, settings, and members. Traffic and sales charts too — that’s the owner’s business, not something for a shift worker.

If you later want to move the line — say, having the counter staff also update stock — you change it by describing it again, the same way you asked for the rest of the site.

What won’t the panel do for you?

It won’t notify you. The last-activity column and the history are there, but you’re the one who has to open them; nobody sends you a message when someone edits something.

There are also no access schedules and no per-location permissions. The role applies to the whole app, all the time — at three in the afternoon and at eleven at night alike.

And it won’t decide for you who becomes an Admin. A second Admin sees everything you see, including what comes in. Sometimes that person should exist — a partner, whoever handles your books — and that’s fine; just make sure it’s a decision, not the side effect of sharing a password.

What does your panel look like this week?

Describe it along with your site, in a single sentence, no jargon:

“A site for my butcher shop in Zamora with a catalog of cuts and prices, pickup orders, and a panel where the counter staff can handle today’s orders and requests, without being able to change prices or see the money.”

It comes out published, panel included. You log in as Admin; the counter staff log in once with their email and you set them to Staff. The day someone leaves, you switch their role to Member and that’s it — no need to change anyone else’s password.

Write down the names and give each one a word

Before you hand out a single access, jot down on your phone everyone who touches your business and give each one a word — customer, serves, or runs.

It almost always plays out the same way. The “serves” list is the long one, the “runs” list has one name, and you already knew who that was. That list is, as-is, the set of roles you’ll assign the day your panel exists.

If you want to start there, describe your business to Proyecta and publish it at proyecta.dev. The panel comes with the site — it isn’t an extra you buy separately.