Managing Clients — Selling It as a Service

The multi-tenant model, field by field

Every tenant is one JSON block in /opt/portal/clients.json on the hub. The block is the entire definition of a client — there is no hidden per-client code. Read the block and you know exactly what that client gets: who they are, how often they post, where their posts go, whether a human signs off first, which template family writes their content, and where the verified facts come from.

Here is what each field does. Nothing here is optional magic — every field maps to a concrete behavior in the nightly run.

A realistic tenant block

Here is what a new client — a fictional home builder, "Acme Builders" — looks like the moment they're onboarded in dry mode, before any real account is connected:

"acme": {
  "name": "Acme Builders",
  "brand": {
    "brand_name": "Acme Builders",
    "tagline": "Custom homes, built to last"
  },
  "cadence": 7,                    # about one post per day
  "channels": ["dry"],            # rehearsal only — logs, never sends
  "require_approval": true,       # client signs off on every post
  "template_module": "portal_templates",
  "listings": "listings/acme.json"
}

Account isolation & safety

The whole service rests on one guarantee: one client can never post to another client's accounts. This isn't a policy or a promise to be careful — it's how the system is wired.

Each tenant's channels list names only that tenant's own connected accounts. The publisher reads a post, looks up the tenant that owns it, and can only reach the accounts in that tenant's block. There is no shared "post everywhere" path. Acme's posts physically cannot be sent to the owner's network accounts, and vice versa.

The access tokens for connected accounts live in the hub's database (the Integration table), keyed to the organization that connected them — not in code, and not shared between tenants. Each tenant's verified facts live in their own listings/<tenant>.json file, so one client's content pool is separate from another's. A post about Acme's homes is written only from Acme's listing.

Client onboarding — the shape of it

Onboarding a client is a short, repeatable sequence, and it's fast — the first one takes an afternoon, the tenth takes minutes. At a high level:

The approval portal — the client's experience

This is the part clients actually touch, and it's what sells the service. Each tenant gets a private web page — a queue of pending posts they can approve on their phone in the time it takes to drink a coffee.

What the client sees

You send them a single link. They tap it — no password, no app to install — and land on a clean, phone-friendly queue of the posts the system has drafted for them. For each post they get three choices:

• Approve — the post publishes on its scheduled slot.
• Edit — they tweak the wording, then approve their version.
• Skip — the post is dropped and never publishes.

That's the entire experience. No dashboards to learn, no calendar to manage. A busy owner can clear a week of posts at a red light.

Under the hood

The link is a magic link: an HMAC-signed, expiring token tied to the tenant's slug, of the shape https://postiz.wholetech.com/portal/app/?c=<slug>&t=<token>. It's minted with portal_db.make_token(slug, days), so you control how long it stays valid. The queue and the Approve/Edit/Skip actions are served by the approval API (portal.service on 127.0.0.1:8990) — GET /portal-api/queue to list, POST /portal-api/act to approve, edit, or skip.

Brand safety for client accounts

Running someone else's brand is a trust business. Four things, working together, make it safe to do at scale.

The honesty guard

Every template declares the facts it needs. If a required fact is missing from the client's listing, the post is held — shown, flagged, and never published — instead of being filled with a guess. The system will never state something about a client's business it can't verify from that client's source data. This is the single most important brand-safety feature: a client's account cannot post a hallucinated claim, because there is no path that invents facts.

Approval mode

Set require_approval: true and nothing reaches the client's account without a human tap. New clients start here by default. As trust builds, a client can move to auto-fire — but the choice is theirs, per tenant.

The kill switch

One file freezes everything. touch /opt/portal/PAUSE and the publisher sends nothing — for every tenant — until you rm it. If anything ever looks wrong, you stop the whole world in one command and sort it out calmly. See Playbook: stop everything.

Isolation

As covered above, a client's accounts, tokens, facts, and queue are separate objects. A mistake in one tenant's config can't spill into another's account.

Pricing the service

The unusual economics here are the reason the service is worth building. Content generation is free — the templates are deterministic, so writing 1,000 posts costs exactly what writing one does: nothing. There is no per-token AI billing. The only channel that costs anything per post is X, at roughly a cent and a half a post (about twenty cents with a link), and Bluesky is free and uncapped. The infrastructure is a flat ~$24/month for the hub, shared across every client you run on it.

So the marginal cost of adding a client is close to zero, and the marginal cost of an extra post is pennies at most. That means almost the entire subscription price a client pays is margin.

White-label — serving under a partner's brand

You don't have to sell this under your own name. A partner — an agency, a marketing consultant, a builder association — can resell the service to their own clients, with the portal and reports carrying their brand.

Two things make white-labeling natural. First, the approval portal a client sees is already generic and phone-first — it's the queue and the three buttons, not a branded destination the client has to trust. Second, each tenant's brand block already sets the voice of the posts to the end client's brand, so the content never reads as coming from you. A partner can present the whole thing — the drafted posts, the approval link, the digest — as their own managed offering.

Under this arrangement you're the operator running the engine; the partner owns the client relationship and sets their own price on top. Your cost per partner-client is the same near-zero marginal cost as any other tenant, so a healthy wholesale price to the partner still leaves them room to mark it up.

Reporting to clients

A managed service that never shows results doesn't renew. The system writes a digest every night — report.py runs at 05:20 UTC — so there's always a current picture of what went out and what's queued.

The digest is the raw material for what you send a client: which posts published, on which channels, what's approved and waiting, and anything held by the honesty guard because a fact was missing. That last one is quietly valuable — a held post is a prompt to go fill in a gap in the client's listing, which makes the next batch of posts richer.

Because the whole pipeline closes the loop — it publishes and records — the report is grounded in what actually happened, not in what was merely drafted. That's the honest version of a "results" email: here is what we posted for you this week, here is what's coming, and here is nothing we made up.

Scaling to many clients

The honest question a prospective operator asks is: "what actually changes when I go from two clients to twenty?" Less than you'd think.

What scales for free: content generation (deterministic templates cost nothing to run more of), the hub (one box, one flat plan, shared by all tenants), and the honesty guard, isolation, and approval machinery (already per-tenant — they don't need re-engineering for each new client).

What grows linearly, but cheaply: the per-post cost on X, capped per day by X_DAILY_CAP so a runaway bill isn't possible; and the operator's triage time — someone still glances at held posts and helps clients who lean on you for approvals. That's the real human load, and it's small: reviewing held posts and topping up listings, not writing content.

What you add per client: a tenant block, a listing file, a set of connected accounts, and a magic link. No new code, no new server, no new subscription.

Your first client, in an afternoon

Here's how it all ties together, told as a single sitting.

You've met a home builder — call them Acme — who's tired of their neglected social accounts. You open clients.json and add an acme block: their brand name and tagline, a cadence of 7 (about a post a day), the builder-demo template module, approval on, and — crucially — the "dry" channel. You drop their verified facts (their communities, their finishes, their warranty, whatever is true and worth saying) into listings/acme.json.

You run the generator. Within a minute the queue fills with a week of finished posts written in Acme's voice, drawing only on Acme's facts. Nothing has been sent — dry mode logged them for you to read. A couple look thin; you notice the honesty guard held one because a fact was missing, so you add that fact to the listing and regenerate. Now the batch reads well.

You show Acme the drafts. They love that it's their voice and their real projects, not generic filler. You connect their X and Bluesky accounts in the hub, switch their channels from "dry" to ["x","bluesky"], and mint them a magic link to their approval queue. You text them the link.

That evening Acme taps through the week's posts on their phone — Approve, Approve, Edit, Approve — and the first ones start publishing on schedule. You've onboarded a paying client, in their own brand, safely gated, for a marginal cost of pennies. The tenth client will take you ten minutes.

Client onboarding — step by step

Add a new client, start to finish

Do it — step by step

1. Discovery. Agree what they want posted, how often, on which networks, and whether they want to approve each post or run hands-off.
2. Connect their accounts. Have them authorize their networks through the hub — follow Playbook 1 once per network. Their tokens are stored under their own account.
3. Create their facts file on the hub — the verified things their posts can draw from (products, listings, services, wins). Model it on an existing one:

   ssh root@64.227.29.192 nano /opt/portal/listings/acme-builders.json

4. Add their tenant block to the config:

   ssh root@64.227.29.192 nano /opt/portal/clients.json

   Add an entry like:

   "acme-builders": {
     "name": "Acme Builders",
     "brand": { "brand_name": "Acme", "tagline": "Built for life." },
     "cadence": 5,
     "channels": ["dry"],            # dry first — see step 5
     "require_approval": true,
     "template_module": "portal_templates_wt",
     "listings": "/opt/portal/listings/acme-builders.json"
   }

5. Dry run. With channels set to ["dry"], generate and review the drafts — nothing is sent anywhere:

   ssh root@64.227.29.192 python3 /opt/portal/generate.py

   Then read them with Playbook 9.
6. Go live. When the drafts look right, change "channels" to their real networks (e.g. ["bluesky","linkedin"]) and regenerate. With require_approval: true, posts now wait in their queue.
7. Give them their approval link (next section) — or approve on their behalf.

The approval portal & the client’s link

Clients who want a say get their own private, phone-friendly approval queue behind a secure, expiring link — no login. They tap Approve, Edit, or Skip on each drafted post; only approved posts publish. Held posts (missing a verified fact) show clearly and cannot be approved until resolved.

Create a client’s approval link

Do it — step by step

1. Generate a 30-day link for the client (use their tenant name):

   ssh root@64.227.29.192 "python3 -c \"import sys;sys.path.insert(0,'/opt/portal');import portal_db as db;print('https://postiz.wholetech.com/portal/app/?c=acme-builders&t='+db.make_token('acme-builders',30))\""

2. It prints the full link. Send it to the client (or open it yourself to approve for them).
3. When it expires, run the command again for a fresh one.