One identity. One workspace. Every Posterita product.

One identity across the Posterita family.

Today, every Posterita product carries its own user table. Retail OS knows you as a till operator. Legal OS knows you as a company secretary. Mail knows you as a mailbox owner. The same person ends up with three separate identities, three separate password resets, and a growing spreadsheet of who has what.

Account OS replaces that with a single account user per person. Product apps keep their own profile rows for local fields, but they link those rows to a stable account ID through a bridge table. Add a colleague once in Account OS and choose which products they get access to. Stop re-inviting your team to every tool the agency adopts next quarter.

A team roster you only build once.

Memberships and invitations live at the workspace level. Roles are kept product-neutral on purpose — owner, admin, member, viewer — so the account layer never has to know what a till operator or a company secretary actually does inside the product app. That stays in the product database, scoped to that product's rules.

When you invite someone, you pick the workspace and you pick the products. They click one link, accept once, and land inside each product with the right local role waiting for them. No shared spreadsheet of passwords, no “who set this up?” archaeology when a colleague leaves.

Product access as a single row.

Granting Retail OS, Legal OS, or Mail to an organisation is one row in account_product_access. Revoking is one row removed. There are no orphaned tokens left in the product app, no shadow users hiding in a side table, no quiet re-issued logins three weeks after offboarding.

The audit value is the point. When a regulator asks “who had access to that workspace on that date?” the answer is one query against one append-only audit log. Mutations writeaccount_audit_log by policy; nothing in Account OS bypasses that.

The neutral workspace record every product reads.

Three record types are shared across the family because they are genuinely the same data in every product. Managed companies — the legal entities your workspace operates. Locations — stores, offices, warehouses, billing addresses, legal addresses. Account contacts — the owner, admin, billing, technical, and legal points of contact every product needs to know about.

Each product reads what it needs via GET /api/account-core and merges into its own local cache. You enter your company name, registered address, and billing contact once. Retail OS prints it on receipts, Legal OS pre-fills it into filings, Mail attaches it to outbound correspondence. The same source of truth, five times less re-typing.

A bridge model that respects product boundaries.

The bridge is one table, account_product_user_links. Each row binds an Account OS identity to a product-local identity. The columns are stable and small:

• account_organization_id — the workspace
• account_user_id — the person
• product_key — legalos / retailos / mail
• product_organization_id — the product's local tenant ID
• product_user_id — the product's local user ID
• product_role — the product-specific role string

Account OS does not absorb product data. Retail OS keeps its catalogue, tills, orders, and POS configuration in its own Supabase project. Legal OS keeps companies, KYC, filings, and documents in its own. Mail keeps mailboxes, messages, and attachments in its own. The bridge is the only thing in the middle — small enough to migrate safely, opaque enough to let each product keep its own data sovereignty.

Three phases. One direction.

Phase 1 — bridge identity. Account OS is the source of truth for who belongs to a workspace and which products they can access. Each product still runs its own login surface. This is where we are today.

Phase 2 — shared login, central billing, workspace switching. One login carries you across Retail OS, Legal OS, and Mail. Subscriptions consolidate at the workspace. Cross-sell becomes possible because we finally know that the same person owns the shop, the company, and the inbox.

Phase 3 — SSO, SAML, central audit, capability governance. Enterprise-grade identity. Cross-product audit logs that regulators can read in one place. Capability tiers governed centrally so an agency operator can revoke an AI capability across every product at once. We ship the safe migration first, not the big-bang rewrite.

Operator-grade. Not for marketing pages.

The UI is dense, compact, and calm — closer to a serious admin console than a SaaS dashboard. Tables, not card grids. Predictable navigation, not parallax. Explicit mutations with visible workspace context, not floating action menus that hope you remember which tenant you are inside.

We do not pretend Account OS is for customers. It is for workspace owners, administrators, and Posterita internal operators. The audience drives the visual language. That is also why this page does not carry product screenshots — there is nothing to market here that an operator would not rather see in the real app.

Questions people actually ask.

The plumbing the family needs.

Account OS is the quiet layer underneath the products you actually use day to day. Get it right once, and every future Posterita product inherits the identity, the workspace, and the audit posture from day one. If that fits the way your team works, send us a note and we will walk through the bridge together.

The Posterita family

Retail OS runs the till. Agency OS supervises the agents. Legal OS files the company. Mail OS reads the inbox. Delivery OS executes the last mile. Commerce OS turns WhatsApp into a storefront. Account OS holds the identity underneath all of them — one team, one compliance posture, an operating system for SMEs in the developing world.