Launching the suite: three shells, one database, zero spreadsheets

Every production team we've worked with was running the same stack: Asana for tasks, Notion for the wiki, Google Sheets for budgets, DocuSign for proposals, Eventbrite or Ticket Tailor for tickets, a clipboard at the gate, a group text for the crew, and a prayer that nothing fell through the seams. It usually did.

The ATLVS Technologies suite is the consolidation of a decade of that duct tape. Today we're launching the three-shell GA: Atlas for internal ops, Gateway for external stakeholders, Compass for the field. One database. One identity. One set of RLS rules.

Why three shells, not three apps

The single biggest architectural decision was to treat Atlas, Gateway, and Compass as three route groups inside one Next.js app, not three separate deployments. It is one Supabase project, one single source of truth, one auth, one set of policies. The shells differ only in layout, nav, and a data-platform attribute that swaps the accent color and OG image.

What this buys us: no cross-app API contracts to version, no cross-app auth dance, no reconciling 'the truth' between three databases. A row in projects is the same row whether an admin reads it in Atlas, a client sees it via Gateway, or a crew member scans against it in Compass.

RLS on every table, no exceptions

Every one of our 33+ tables has Row-Level Security enabled with policies gated on is_org_member(org_id) and has_org_role(org_id, roles[]). There is no application code path that can return a row belonging to another org. The database itself won't let it.

The reason this matters: when someone leaves your company and you revoke their membership, access dies the next request. No cache invalidation. No permission propagation. No 'we forgot to remove them from the mailing list.' RLS is not a feature. It is the authorization model.

Gateway: the slug is the authorization boundary

External stakeholders don't sign up. They open a URL. /p/[slug]/client opens the client proposal. /p/[slug]/vendor opens the vendor rail. /p/[slug]/guest opens the guest guide. The slug is the grant. Rotate it and access dies globally.

Two vendors on the same project cannot see each other's pricing. RLS enforces it at the database. It is not possible to bypass by guessing a URL.

Compass: offline-first is a production requirement

Venues kill signal. A mobile scanner that stops working when the cell tower saturates is just an expensive lanyard. Compass's service worker caches the scanner shell and today's data. Scans queue locally in IndexedDB and replay in order when the network returns.

And it's a PWA. No App Store review, no build pipeline, no install fragmentation. Your crew opens a URL, taps Add to Home Screen, and they have a full-screen launcher indistinguishable from native.

What we cut

We said no to a lot. No per-seat pricing (per org, not per seat). No per-scan surcharges (scan as many as your event needs). No fake 'enterprise only' gates on features that should be standard (audit log, RLS, signed URLs, and HMAC webhooks ship on all tiers). No forced sales call to try the product (sign up; you're in).

What's next

Next on the roadmap: direct QuickBooks Online sync, redlineable proposals, iOS Live Activity for scan counts, and SOC-2 Type II certification. The full changelog lives at /changelog and is updated the day each change ships.

Start free at /signup. We'll see you at load-in.