Seats / multi-user: research and plan

Status: plan only. Nothing implemented. Date: August 2026 Question: Should each plan be able to add seats, at a cost, so multiple users can sign in to one account and share brands? Depends on: the reverse-trial pricing model (PR #754) and docs/pricing-model-research.md

1. Headline recommendation

Build multi-user. Do not price it per seat on Free or Pro. Make seats the Agency tier's meter.

Tier	Seats	What you actually pay for
Free	1	—
Pro	3, included at no cost	brands (£19 each, to 5)
Agency	priced per seat	seats × brands

And a sequencing point that matters more than the pricing question:

Seats are not a pricing change. They are a schema migration. Everything in the product currently hangs off customer_customer.user_id = auth.uid(). The billing decision below is perhaps 5% of the work; re-rooting ownership and RLS is the other 95%. Section 5 sizes it.

Do not start this before Stripe self-serve billing exists. Seats without billing is a large migration that gives a feature away for free.

2. What the market is doing

Direct competitors split cleanly, and the split is informative:

Product	Seat model	Price signal
Buffer	Unlimited users, no charge	Meters channels ($6–12/ch)
Sprout Social	Per seat, every tier	$99–499 per seat/mo
Hootsuite	Per user	From $99/user/mo
Later	Seats bundled into tiers	From ~$25/mo

Two coherent strategies, not a spectrum: Buffer meters the work and gives away the people; Sprout meters the people. Nobody successful does both hard.

The broader market is moving Buffer's way:

Pure seat-based pricing fell from 21% to 15% of SaaS companies in a single year; hybrid (base fee + usage/outcome) went to 41–43%, projected 61% by end of 2026.
IDC forecasts 70% of vendors move away from pure per-seat by 2028, driven specifically by AI agents reducing the number of humans who need a login.
Gartner: ≥40% of enterprise SaaS spend shifts to usage/agent/outcome models by 2030.

The stated cause of the shift is the exact thing Ai-mee sells: "when one AI agent can do the work of ten human users, the per-user model loses its relationship to value."

3. Why per-seat is the wrong meter for Ai-mee specifically

3.1 It charges for the thing the product removes

The pitch in BUSINESS_OVERVIEW.md §5.4 is "The Busy Owner — runs a restaurant; does marketing themselves; no time for dashboards," and the landing page sells against "hiring a marketing agency or freelance copywriter is £500–2000/month."

A per-seat price says the more humans you put on marketing, the more you pay us. That is a direct contradiction of "you don't need more humans on marketing." It is also self-limiting: every successful Ai-mee deployment should reduce the number of people touching content, which under per-seat pricing means our revenue falls as the product works better.

3.2 Seats have no marginal cost here; brands do

Cost per additional brand: its own site crawl, brand voice, daily campaign planner run, content stream, briefings. Real, recurring, LLM-denominated.

Cost per additional seat: a messaging_users row and some chat turns. A second human mostly reads and approves work that was going to be generated anyway. Near zero.

We just spent PR #754 arguing that the free tier must be metered because inference is a genuine variable cost. The same logic run honestly says seats are not a cost centre and pricing them is pure margin extraction dressed as metering. Brand count already correlates with both willingness to pay and COGS — it is a strictly better meter, and we already have it.

3.3 Seat friction costs more than seat revenue at this price point

At £29–49/mo, a seat is worth maybe £9–15. Against that:

The owner who wants to add their VA, bookkeeper, or agency contact hits a paywall at the exact moment they were about to embed the product deeper in their business. Every blocked invite is a retention risk traded for ~£10.
Multi-user is the only viral loop this product could plausibly have. A Telegram bot generates no public artifacts, no shared docs, no SEO surface — this was §3.1 of the pricing research and it is still the weakest part of the growth model. An invite is the one mechanism that puts Ai-mee in front of a new person who did not sign up for it. Charging for the invite taxes our only loop.

3.4 Agency is genuinely different

Everything above inverts at the Agency tier:

The buyer already thinks in seats — account managers are the unit of capacity.
Competitors set the anchor there ($99–499/seat), so per-seat pricing reads as normal rather than grasping.
Headcount genuinely tracks value: 15 account managers means 15 people getting paid to use this.
BUSINESS_OVERVIEW.md §6.1 already assumes per-seat for Agency.

So the answer is not "seats or brands" — it is brands below, seats above, with the boundary at brand 6 that PR #754 already established.

4. Product questions that are harder than the billing

These need answers before any schema work. They are not pricing questions and they are where the real design risk sits.

4.1 Who receives the proactive messages?

The single hardest one. Today messaging_users is per user_id, and briefings, weekly summaries and approval nudges go to that person. With three seats:

Does the 9am briefing go to all three, or one?
If two people are in Telegram with Aimee, do they see each other's conversation? (Today the liaison agent's context is per user.)
Who gets the "post has been waiting 24h" nudge — everyone, or the assigned reviewer?

Recommended default: per-seat notification preferences, defaulting to briefings for the owner only and approval nudges to everyone with approve rights. Three people getting the same 9am message is how a product gets muted.

4.2 Who can approve a post?

Approval publishes to the customer's real audience. That is the one action with outside-world consequence, and "any seat can publish to your Instagram" is not a safe default. Minimum viable roles:

Role	Can
Owner	everything, including billing and seat management
Admin	everything except billing
Member	generate, edit, comment — request approval, not grant it

Anything more granular is speculative until there is a customer asking.

4.3 Per-brand seat scoping

An agency with 15 clients does not want every account manager seeing every client. Brand-scoped membership is the natural model, but it multiplies the permission surface. Recommendation: account-wide seats in v1, brand-scoped access as an Agency-only follow-up. Do not build it speculatively.

4.4 What happens on downgrade?

If a Pro account with 3 seats drops to the holding pen (1 seat), the other two must not silently lose access to work they created. Mirror the trial-downgrade behaviour from PR #754: deactivate, don't delete, tell each affected person what happened and why, and restore instantly on upgrade.

5. What it costs to build

5.1 The core problem

Ownership is currently a single column. customer_customer.user_id is the root, and 20260518140000_fix_rls_policies_audit.sql establishes the pattern:

CREATE POLICY "customers_select_own" ON "public"."customer_customer"
  FOR SELECT TO authenticated USING (user_id = auth.uid());

Every other customer_* table's RLS routes back through that join. Roughly 14 tables carry policies and 20 migrations reference customer_customer; nine tables carry a direct user_id.

Seats mean inserting an account layer between auth.users and customer_customer, then rewriting every one of those policies from "is this row mine?" to "am I a member of the account that owns this row?".

5.2 Phases

Phase 1 — Account layer (largest, no user-visible change)

account table; account_member (account_id, user_id, role, status)
customer_customer.account_id, backfilled one account per existing user_id
A SECURITY DEFINER helper — auth_account_ids() — returning the caller's account ids, so policies stay readable and are indexable
Rewrite RLS across the ~14 policy-bearing tables to route through it
Keep user_id populated as a shadow column through the transition, so a bad policy fails closed rather than exposing another account's data
Move plan limits from per-user to per-account: getUserPlan, getUserUsage, checkLimit, enforce_active_client_limit, and the front-end plan store all currently key off user_id

Phase 2 — Membership & invitations

Invite by email, accept flow, role assignment, seat-count enforcement
plan.max_seats + user_subscription.extra_seats, mirroring the brand add-on shape already in PR #754
Downgrade behaviour from §4.4

Phase 3 — Messaging model

Per-seat notification preferences; resolve §4.1
Decide whether the liaison agent's conversation context is per-seat or shared
Approval rights enforced in the bot, not only in the dashboard

Phase 4 — Agency seat pricing

Per-seat billing, Stripe quantity-based subscription items
Brand-scoped membership if customers ask for it

5.3 Honest sizing

Phase 1 alone is comparable in size to the entire reverse-trial change, and it is riskier: a mistake in a rewritten RLS policy is a cross-tenant data leak, not a cosmetic bug. Phases 1–3 are the minimum for a usable feature. Phase 4 is small once 1–3 exist.

The security review skill should gate Phase 1 specifically.

6. Recommended sequence

Stripe self-serve billing — still a stub at webhooks.ts:222. Everything monetisable is blocked behind it, including the day-31 trial conversion that PR #754 depends on. Highest value in the backlog.
Per-brand add-on purchase flow — already designed and schema'd in PR #754; small once billing exists, and it validates the add-on shape that seats would reuse.
Seats Phase 1–3 — only after the above, and only if customers are asking.
Agency per-seat pricing — last.

The one thing worth testing first

Before any of this: how many Pro customers actually ask for a second login? If the answer is "few," Phase 1's cost is not justified yet and the honest move is to keep single-user and compete on Buffer's axis. Instrument the request — even a "invite a teammate" button that captures an email and says "coming soon" would answer it in a month, for an afternoon's work.

That is the cheapest experiment available and it should precede a migration this large.