A Supabase substrate that unifies the Rex Tech Ventures portfolio under one architecture.
A foundational, unifying layer that abstracts storage, compute, and management — decoupling data from any specific application. Disparate products read and write the same data within a single, cohesive framework. Improves scalability, enables modular data management, and lets AI reason across the whole portfolio instead of one product at a time.
Rex Tech Ventures has built ten exceptional products. Each ships independently, owns its own database, owns its own auth, has its own (or no) AI integration. The cost compounds.
Cross-product features cost 4–8 weeks of API work each. The portfolio's network effect stays theoretical.
The same vendor lives in IDCore + BillRoute + GetDone. The same resident lives in TenantPort + ProofUp. Reconciliation is manual and constant.
Claude can't reason across portfolio data because there's no shared substrate to point it at. Each product trains its own narrow model.
Each spoke owns its UX and domain logic, but reads + writes through the shared Supabase substrate. New cross-product features become joins, not integrations.
Identity, accounts, vendors, residents, journal entries, events — all in one schema. Each product reads/writes its own scope via RLS-enforced role-bound views.
Claude (and any model) sits over the unified data. AP-with-AI in BillRoute, fraud detection in ProofUp, copilot queries across the portfolio — same prompt-cached schema.
Each portfolio product exposes its capability as a documented REST endpoint. Cross-product features become method calls, not 8-week integrations.
AI that reasons across all 10 portfolio companies + the real estate side. Cross-product features ship as joins, not 8-week integrations. Single auth, single GL, single source of truth.
Every portfolio product becomes a typed contract — read inputs from the hub, write events back. No one product owns the data; the hub does.
| Spoke | Domain | Contributes to the hub |
|---|---|---|
| JobCall | AI assistant for property management | Operator chat + voice transcripts → events + tasks |
| CredBuild | Rent-to-credit reporting | On-time payment events → tradeline writes |
| ProofUp | AI fraud detection + income verification | Applicant docs → fraud signals + risk scores |
| PayUp | Vendor / owner / PM payments | Payment events → GL postings + reconciliation |
| GetDone | Maintenance operating system | Work orders + vendor dispatch → activity feed |
| BillRoute | AI invoice automation | OCR + GL coding → AP queue |
| InsurePro | Configurable B2B insurance | Policy lifecycle → COI + compliance ledger |
| OwnProp | Tokenized real estate marketplace | Ownership stakes → cap table + distributions |
| IDCore | AI vendor compliance | Vendor identity + insurance + W-9 → trust scores |
| TenantPort | Resident portal | Resident sessions → payments + work orders + comms |
| UnitBoard proof | AI-native multifamily ERP | Operator workflows → leases, work orders, GL postings |
Working multifamily ERP on Supabase. Operator + resident + owner portals + public API + AI layer + integrations directory. Built solo in 2 days. Proves the pattern.
TenantPort + IDCore + JobCall first — they share identity (residents) and vendor primitives. Each becomes a role-bound surface on the unified Supabase. Cross-product features ship in days. ~12 weeks.
All 10 spokes on shared substrate. Single auth (one identity per person, regardless of which spoke they entered through). Single AI surface that reasons across the whole portfolio. Single GL for cross-portfolio reporting. ~6 months total.
Some products will be rewritten. Older portfolio products with bespoke schemas may need a migration to the shared model. AI accelerates this — schema translation, codebase port, and test generation are exactly the workflows Claude is now strongest at.
Some products only need an API spoke. Newer products that already use Supabase or Postgres can publish events to the hub via a thin contract layer. No rewrite needed.
The hub itself is small. The shared schema is identity, accounts, vendors, residents/customers, journal entries, events, and a typed action log. The complexity lives in the spokes.
RLS does the gating. Each spoke gets its own role and policy set. A vendor in IDCore can't see resident data; a resident in TenantPort can't see GL entries. Security is structural, not bolt-on.
One database, three role-bound views, AI in every workflow, public API on every plan. Built solo in 2 days. The pattern works at multifamily scale today — the same shape extends to the whole Rex portfolio.