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 |
| AcquisitionBoard | Deal pipeline + underwriting + IC workflow | Sourcing → DD → close → handoff to UnitBoard on the same hub |
What the hub-and-spoke pattern looks like at the table level. The hub holds identity (users + their shared profile — display name, avatar, phone, locale), the ledger, the event log, and the AI action history. UnitBoard’s domain tables — properties, units, leases, residents, work orders — reference the hub via foreign key. Each spoke also keeps its own product-specific user profile (e.g. operator_profiles) so a single hub identity can have different defaults, roles, and preferences in each product they touch. RLS policies decide who reads what. Postgres enforces referential integrity in one transaction.
The dashed-arrow rows (⇢) point at hub tables. vendors.default_account_id joins to hub.accounts; every payments row writes a hub.journal_entries row in the same transaction. The ledger is never out of sync.
Each spoke gets a Postgres role. UnitBoard’s role can read every table in its schema and only the hub rows scoped to its org_id. A vendor logging in via TenantPort can’t see a journal entry. Security is structural, not bolt-on.
Bo’s tool registry includes typed read access to UnitBoard and the hub. Ask it for portfolio NOI and it joins hub.journal_entries against hub.accounts filtered to the operator’s org_id — one query, one source of truth.
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.
“You wanted an MVP in 90 days. I shipped the demo in 6.”
Scott Molluso — AI Product Builder & Database Architect, based in Austin. 3x co-founder. $4M+ ARR shipped. 20 years in PropTech. Full-stack: frontend design through database architecture, design systems through RLS policies. Founder experience on top — pricing, GTM, hiring, the whole loop, not just the IDE. Built internal operating platforms for two prior asset / property management companies before this round of solo product work.
The last six months: 35 repositories shipped solo across leasing, brokerage, residency, capital markets, and the workflows in between. The methodology is AI-augmented and ruthlessly iterative — ship in days, watch what real users do, refine, compound the patterns. RexOS isn’t the first attempt; it’s the architectural thesis the other ten products kept pointing at.
Real estate sales, brokerage operations, transaction management — built software for operators because I was one.
Across prior products. Not pitches, not pilots — recurring revenue from real customers, generated by software I built.
Built and run companies before. Knows the difference between shipping fast and shipping debt that compounds.
Modern stack, RLS-gated Postgres, type-safe end-to-end. Every workflow ships with AI in the seam, not bolted on later.
Built the custom internal operating platform managing 3,300+ residential assets across Baltimore, Cleveland, Detroit, and Pittsburgh. Adopted by 80+ employees as the daily operating system across leasing, maintenance, and operations.
Rebuilt the company’s entire technology stack — WeWeb frontend + Xano backend — in 3.5 months, replacing all legacy systems.
Most ERPs are built by 30-person teams over 30 quarters. UnitBoard was built by one engineer over six days because the toolchain finally caught up — Claude in the loop, Postgres + RLS as the substrate, every workflow shipped end-to-end before moving on. The codebase isn’t a prototype; it’s production-grade with type safety, tests, audit trails, and a real GL. The next 90 days don’t require rewriting any of it — the architecture absorbs depth without collapsing back into rework.
RexOS isn’t another bet in the portfolio. It’s the consolidation — six months of pattern-recognition across PropTech, applied to one shared hub, with an AI substrate that compounds with every new spoke.
Three reasons we picked the name — and why the .com is on hold.
The product surfaces every unit in a portfolio on one board. That’s exactly what an operator opens it for — to see every door, every lease, every dollar in one place. The name describes the page.
Short, schema-shaped, the noun that names the substrate the product sits on. Same shape as every other RexOS spoke — when the suite is full, the naming reads as a system, not a grab-bag.
Listed on the secondary market right now. Held in reserve for when the .com upgrade is worth the spend — once the product crosses the threshold where the four-figure swap pays for itself in trust signal alone.
One database, three role-bound views, AI in every workflow, public API on every plan. Built solo in 6 days. The pattern works at multifamily scale today — the same shape extends to the whole Rex portfolio.