Client Case Study

Off The Map Productions

Three systems, one studio, hard boundaries between them.

Off The Map Productions is an AI-accelerated creative studio making cinematic video, brand systems, real-time visuals and product renders for creators and growing brands. We built the software the studio runs on: the platform that makes the work, the system that sells it, and the tool that proves it worked.

See the stack Visit the studio

3 Systems delivered

3,289 Automated tests across the stack

RLS Enforced in every database

Disclosure — common ownership

Off The Map Productions, LLC and PRJCT LAZRUS LLC share a founder. OTM is a real client running these systems in production, and this page describes real delivered work. The relationship is not arm's length, and we say so rather than presenting it as independent validation.

The Brief

A studio outgrowing its spreadsheets

OTM sells three things that each need different software: cinematic production at volume, a partner-referral program that owes real people real money, and monthly managed growth retainers that have to be reported on honestly. All three were being run by hand.

Production did not scale

Every AI video engine has its own grammar, its own failure modes and its own pricing. Producing at volume meant a human sitting between the brief and six different provider dashboards, re-prompting by hand and picking takes by eye.

Commissions were a promise on a spreadsheet

A referral program is a commitment to pay a named person a specific amount when a specific invoice clears. Tracking that in a sheet means the amount owed is whatever the last person to edit the sheet believed it was.

Retainers had no evidence

A monthly growth retainer promises a monthly report. Without a system recording what was planned, what was published and what it did, that report is a screenshot collection and an opinion.

The Stack

Three systems that refuse to own each other's facts

The interesting engineering was not inside any one system. It was in the boundaries — making sure two services can never both believe they own the same truth, especially where money is involved.

System 01

Compass

The production platform. One brief fans out across nine AI video engines in parallel, every take is scored against the director's spec, and the winners are assembled into a broadcast-deliverable edit with voiceover, score, sound design, captions and content credentials.

Compass in detail

System 02

Polaris

The commercial system of record. Clients, contracts, invoices and payments, with referral commissions computed in Postgres on verified money only, written to an append-only ledger, and settled through atomic batch payouts.

Polaris in detail

System 03

Nautilus

The growth-operations tool. It plans a client's content, measures every post, learns which hooks and pillars win on that specific account, paces goals against the paid period, and produces the report the service agreement promises.

Nautilus in detail

The Hard Part

Two systems that both pay partners is one system too many

Compass and Polaris both touch subscriptions and referrals. Getting that wrong does not produce a bug report — it produces a partner paid twice, or a commission nobody owns. So the boundary was written down as a contract before either side was allowed to move money.

One authoritative payout writer

With the Polaris backend active, the scheduled native payout job returns an authenticated skip and the owner-triggered route refuses outright — the switch cannot leave two writers running

Distinct signing secrets per endpoint

Each application verifies its own webhook signature; neither trusts a payload because the other one might have

No raw identifiers leave the CRM

Client UUIDs are never exported into payment-provider metadata; ambiguous matches go to manual review rather than being guessed

Failures stay retryable

Reversal and settlement errors propagate out of the webhook handler so the event claim is not silently consumed

payout-authority.ts

// The backend switch is the authority,
// and it is checked on every money path.
if (config.referralBackend === 'polaris') {
  // Compass does not write commissions,
  // does not call invoice mutations,
  // and does not run native payouts.
  return { status: 'POLARIS_AUTHORITATIVE' };
}

// The read-only surface stays open either way:
// referral validation, intake, dashboard reads.
const partner = await polaris.validateCode(code);

How We Know It Works

Verification that asks the live system, not the repository

Passing tests prove the code does what the code says. They do not prove the deployed database matches the migrations, or that a hand-applied function is not sitting in production. Each system carries verification for both questions.

3,289 automated tests

1,065 across the Compass dashboard, 1,231 in Nautilus, 993 in Polaris

Schema drift detection

Verification asks in both directions: what the migrations declare, and what the live database actually has

Grant coverage as a test

The application role's privileges are held to the tables the product's SQL actually names — in both directions

Written certifications

Security and operational readiness tracked item by item, with blocked items named rather than quietly closed

Runbooks before incidents

SLOs, incident runbook and a disaster-recovery plan written while nothing was on fire

Least privilege by default

Forced row-level security, pinned function search paths, service-role-only money tables

We build operating stacks, not features

Off The Map got three systems that hold a real business together and stay honest about what they know. If you are running an operation on spreadsheets, screenshots and provider dashboards, that is the work we do.

Start a conversation Compass Polaris Nautilus