The question that started it

Someone on the livestream had built a restaurant operations hub for a client. The client now wanted to check the numbers from their phone while away from the restaurant. And the builder did not want to host anything.

That is a good question, and it is a question a lot of people building for clients run into. The answer turned into four separate answers, because the same session covered plugin updates, keeping client work separate, and how to stop burning your best model on jobs that do not need it.

Here they are.

1. A dashboard your client can open on a phone, with no hosting

Your campus already has a dashboard built in. It is a snapshot of what is going on across your install — runs, deliverables, what is active, what is not — and it is just an HTML page pulling from your own files. Nothing clever.

The same trick works for a client. Ask Dean to build a dashboard for that client’s work, and you get a web page. The question is only where the page lives.

Two services worth looking at are Netlify and Vercel. Both let you publish a page without running a server, both can sit behind a private URL or a login, and both can use your own domain so it looks like your business rather than someone else’s subdomain. Netlify has a connector that lets Claude publish an artifact to it directly.

Be straight with yourself about the state of this: I have only done this partially, not successfully end to end. The dashboard part is easy and reliable. The publishing part is the bit still worth an afternoon of your own testing before you promise a client a URL.

The proof of concept took about a minute to build with dummy data — bookings up and down, meals served, hours saved, cost of sales, stock control, social bookings, admin. One object at the top holds the data so you can see exactly where the real numbers plug in. If you want it to work on a phone, say so; it is a web page, so it will.

2. Two ways to keep client work separate

If you are doing this for clients, the real question underneath is isolation. Two options, and they are genuinely different:

• The client gets their own folder in your campus. Their own slug, their own space. Their dashboard can only contain their work, because the folder only contains their work. This is isolation by construction — you cannot leak what is not there.
• Tag the record of work as it happens, and filter at read time. One shared campus, everything tagged, the dashboard shows only the rows belonging to that client.

I would take the first one. The moment a page becomes client-facing, confidentiality stops being a convenience and starts being a surface. A filter you have to get right every time is weaker than a folder that never held the other client’s work in the first place.

Worth knowing: when you first set up a campus you are asked whether you want a projects folder, a clients folder, or both. If you are heading toward agency work, that is the moment to say clients.

3. Updating a plugin without losing your work

This came up more than once, so here is the whole thing.

1. In Claude Cowork, click Customize in the left-hand menu.
2. At the bottom left you will see Skills, Connectors, Plugins and Memory. Choose Plugins.
3. Click Add, then Upload plugin, and pick the file.
4. You will get a warning that something is already installed there and asking whether to overwrite. Say yes.
5. Close the customize panel, start a session in your campus folder, and tell Dean plainly: “I just installed a new version — please update my workspace.”

A note on the file itself, because it confuses people: the .zip and the .plugin file are the same thing. The insides are identical and only the extension differs. I distribute mine as .zip because Windows and macOS both look at a .plugin file and have no idea what to do with it. Only Claude knows what that extension means.

The update itself is additive. It brings in the new material and leaves your memory, your wiki, your departments and every file you have written alone. That said — take a zip of your campus folder first anyway. Not because the update is risky, but because a backup you did not need costs you thirty seconds and a backup you needed and did not take costs you a weekend.

And the reason this is safe at all: the campus does nothing outside its own folder. Everything in there is yours.

4. Stop paying top-model prices for routine work

There is a router in the campus, and it is the least glamorous thing in here that saves the most money.

Think about it the way you would think about staff. If you have a line worker on an hourly wage, you do not hand them orchestration, architecture and strategy decisions. You hand them “search this, use that tool, do it every time.” Cheaper worker, routine task. More senior worker, the calls that matter.

Model routing is exactly that. Even when I start a session on the strongest model, the router looks at each job and sends the routine ones somewhere cheaper. My own rule is simple: anything customer-facing or strategic — outbound email, content, anything a client or the public will read — runs on the strongest model in the session. Everything else drops down.

Below even that, I have an old 8GB M1 Mac Mini running a small local model. Any plain search gets handed to it and costs nothing at all.

You set the rules. The router follows them.

The habit underneath all four answers

Every one of these came from the same two questions, asked out loud.

The first is: did we miss something, and is there an easier way to do this? If the first answer you get involves Node, Docker, a hosting platform and three services you have never used, that is your cue to ask it again. Often there is a far simpler shape and it just did not lead with it.

The second is for the bigger calls: bring in the council. Have the skeptic in the room. Have the one who counts the money. Have the contrarian, and your customer, and your brand. Get challenged on whether you should be doing this at all before you spend a week doing it well.

The common mistake this prevents

Accepting the first technical answer because it sounds like it came from someone who knows more than you.

It probably is more technical than you. That is not the same as it being right for you. A model with no context will assume, and it will assume in the direction of the most standard answer rather than the one that fits a one-person business. Asking “is there a simpler way” is not you being difficult. It is you supplying the context it did not have.

Do this now

Pick the one piece of work you currently do for someone else — a client, a member, a student — where they keep asking you for a status update.

Ask Dean to build a dashboard for it. Then, before you deploy it anywhere, ask the follow-up: is there a simpler way to get this in front of them?

If it works once, you have not just solved it for that person. You have a productized service, which is the thing you can charge for on a regular basis instead of rebuilding from scratch every time.

Recap

• Client dashboards are just web pages — build with Dean, publish through a service so you host nothing.
• A separate folder per client beats a filter, because it cannot leak what it never held.
• Plugin updates are additive and stay inside your campus folder. Back it up first anyway.
• .zip and .plugin are the same file. Only Claude reads the second one.
• Route routine work to cheap models, keep anything customer-facing on your best one.
• Always ask “did we miss something, is there an easier way” — then bring in the council for the calls that matter.

The Campus AI OS is free, and it installs as folders and files on your own hard drive. It ships with departments for community, teaching, sales, marketing, admin and lead generation, and an onboarding pass that asks about your customers, your brand, your voice, your offers and your tools so the whole campus is working from the same shared memory.