Client Platform — Off The Map Productions

Polaris

Commercial truth, computed in the database.

Polaris is the CRM and partner-program engine we built for Off The Map Productions. It owns clients, contracts, invoices and payments, and it calculates referral commissions the moment money is verified — in Postgres, on an immutable ledger, with caps, month limits and refund reversals that cannot be argued with after the fact.

Explore the platform Read the case study

993 Unit tests

31 Schema migrations

RLS On every money table

Built for Off The Map Productions, LLC AI-accelerated creative studio · off-the-map.com

Core Capabilities

From referral link to paid partner

A referral program is a promise to pay a real person a real amount at a real time. Polaris treats every step of that promise as a financial control rather than a CRM field.

Client Pipeline

Every client — referred or direct — with service, status pipeline, invoices, tags, follow-ups, activity history and search. The commercial record the rest of the stack reads from.

Partner Lifecycle

Application to approval to auto-generated referral code, with atomic approval and a self-referral guard. Partners get their own portal; the studio gets one place to see what is owed.

Commissions on Verified Money

The commission engine fires only through the payments engine, on recorded payment — never on an invoice someone flipped to "paid". The base is the pre-tax amount, with caps, per-month limits and thirty-day refund voids.

Immutable Ledger

Commission credits and debits are append-only. Refunds prorate, disputes claw back, and nothing is edited in place — a balance is the sum of entries, so a balance can always be explained.

Atomic Batch Payouts

Every partner over the threshold, batched in one click, in one transaction. A payout run either happens completely or does not happen — there is no half-paid state to reconcile by hand.

Public Intake

A branded intake form that resolves referral codes server-side, so attribution never depends on a query string the browser can rewrite. Partners share one link; the credit lands correctly.

Webhook Idempotency

Payment events are claimed once. A settlement failure propagates out of the handler so the claim stays retryable, rather than being swallowed and silently dropping money on the floor.

A REST Surface Other Systems Consume

The API is the contract and the admin UI is swappable. Compass reads it for referral validation; Nautilus receives signed events from it. The database layer is the interface.

Append-Only Audit Trail

Admin actions write to a log nobody can quietly edit, with search-path pins on every database function so a privileged routine cannot be tricked into resolving the wrong object.

Under the Hood

The money logic lives in Postgres

Commission math in application code is commission math that can be bypassed by the next integration. In Polaris it is a database function on a transactional path, so every writer gets the same answer.

Next.js App Router on Vercel

Gated admin dashboard, public intake, and a server-only service-role API

Supabase Postgres with RLS

Money tables are service-role only; views use security invoker so RLS still applies

Thirty-one ordered migrations

Schema, RLS, payments engine, ledger atomicity, dispute clawback, outbox

Signed outbox to Nautilus

Durable HMAC event emission — growth never invents a commercial fact

SLO, incident runbook, DR plan

Written before they were needed, with a certification tracking every open item

0007_commission_pretax_base.sql

-- Commission fires on verified money only.
-- The base is what the studio actually earned,
-- not what the invoice totaled.
CREATE OR REPLACE FUNCTION calculate_commission(
  p_invoice_id uuid
) RETURNS void
LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = public  -- pinned
AS $$
DECLARE
  v_base numeric := total_amount - tax_amount;
BEGIN
  -- append-only ledger entry, capped,
  -- voidable for 30 days on refund
END;
$$;

The Boundary

One envelope, one signature, two directions

Polaris and Nautilus exchange commercial facts across a single signed contract. The contract exists so that neither system ever has to infer something the other one owns.

Envelope: Thirteen fields against a versioned schema, pinned at 1.0. Every event carries its own id, an idempotency key, and the aggregate it belongs to.
Canonical form: Both ends serialize identically before signing — keys sorted, no whitespace, non-ASCII escaped — so a Python sender and a JavaScript receiver hash the same bytes. Numbers stay integers on the wire, enforced at runtime on both sides, because a decimal point that two languages spell differently reads as a forged signature.
Signature: HMAC-SHA256 over the canonical bytes, compared in constant time. Separate keys per direction, so either can be rotated without a flag day.
Delivery: A durable outbox with retries and per-aggregate ordering. A fact that cannot be delivered is parked, not dropped, and a later fact about the same client never overtakes it.
Idempotency: Event id and idempotency key are both unique on the receiving inbox, and the inbox is never pruned. A replayed event is acknowledged as a duplicate and has no second effect.
Authority: Polaris is the only writer of money. Nautilus may report on a commercial fact; it may not create one.

Revenue systems that hold up under audit

Polaris is the commercial spine of the three-system stack we built for a working studio. If you are paying partners out of a spreadsheet, we have already solved the parts that go wrong.

Start a conversation Read the case study See Nautilus