Integrating Six Businesses with an AI Stack: A Hands-On Guide to Self-Hosted Supabase and VAPI

Why would one engineer run six businesses at once?

Real estate wholesaling, demolition services, valet parking, credit repair, mineral rights, and SaaS — six seemingly unrelated businesses all exist under one company called Load Bearing Empire. The founder's real problem: a traditional SaaS stack quickly becomes expensive and unwieldy in cross-business collaboration scenarios.

According to the team's disclosure on their technical blog, they previously relied on Twilio, SendGrid, and Make.com for communications, email, and automation, with monthly SaaS costs exceeding $8,000 and integration latency frequently surpassing acceptable thresholds during cross-business calls. More critically, data was locked into multiple vendor silos, making it impossible to form a unified business logic layer.

This prompted a decisive move: completely tear down the existing SaaS toolchain and pivot to a self-hosted AI stack.

The Core Architecture of the Self-Hosted AI Stack

Supabase: Single Source of Truth

The entire system's data layer is built on a single Supabase instance with the project ID whxtjboruayowkqyjvcq. This instance contains 98 tables, covering all entity relationships across the six business lines, and runs 42 Edge Functions to handle business logic.

This "single-instance multi-tenant" design means: a seller lead from real estate wholesaling can directly trigger the follow-up process for the credit repair business; payment records from valet parking customers can sync in real time to the subscription management module of the SaaS product. Cross-business logic no longer needs a third-party automation platform to glue things together — it's accomplished through relationships and functions inside the database itself.

Supabase is an open-source Backend-as-a-Service (BaaS) platform, often described as the "open-source Firebase." Its core capability is building a managed database on top of PostgreSQL, and on that foundation providing authentication, auto-generated APIs, real-time subscriptions, object storage, and Edge Functions (lightweight serverless functions based on Deno). Unlike Firebase's closed data model, Supabase directly exposes standard SQL and the relational model — developers can write native SQL, use foreign keys, triggers, and stored procedures, or self-host the entire service. The "single-instance multi-tenant" approach in this article relies precisely on this relational database capability: all business tables live in the same PostgreSQL instance, allowing free JOINs, shared RLS policies, and foreign key constraints — making cross-business data naturally connected without relying on external automation platforms for synchronization.

VAPI Multi-Agent Orchestration: 26 Specialized Agents

The voice interaction layer uses VAPI's multi-agent orchestration capabilities. The team deployed 26 specialized AI agents, each corresponding to a different operational process. For example, the demolition business needs to handle on-site photos and quotes, while the credit repair business needs to parse credit report dispute items — these agents each have independent prompts, tool sets, and knowledge bases, but share the same Supabase backend.

Communication between agents doesn't go through an external message queue; instead, they directly read and write shared state tables in Supabase, compressing integration latency to under 100 milliseconds.

VAPI is an orchestration platform for voice AI applications that combines speech recognition (STT), large language model inference, speech synthesis (TTS), and telephony network access into an end-to-end voice agent pipeline. Developers can configure independent prompts, function calling, and knowledge bases for each agent, then connect via phone or web. VAPI's "multi-agent orchestration" means multiple agents can divide and collaborate: one answers the call, one retrieves knowledge, one executes tasks, and then hands off the call to a more suitable agent via SIP or API. The key reason for choosing VAPI in this article is its ability to interface with a self-built Asterisk PBX via the SIP protocol, while also allowing agents to read and write to the same backend database — thereby avoiding storing state in an external message queue.

Asterisk 18.10 PBX + Vultr: Self-Built Communications Foundation

To completely escape Twilio's per-minute billing model, the team self-built Asterisk 18.10 PBX on Vultr cloud servers. This provides SIP trunking, call recording, IVR, and other basic telephony capabilities, while writing call data directly into the self-hosted database.

VAPI agents interface with Asterisk via the SIP protocol, bridging AI voice interaction with traditional telephone networks. While this approach adds initial configuration complexity, it completely eliminates usage-based communication costs.

Asterisk is the most well-known open-source PBX (Private Branch Exchange) software, enabling an ordinary server to play the role of a traditional telephone switch. It supports SIP trunking, IVR, call recording, conferencing, queues, and more, and can interact with external programs through dialplans and AGI/ARI interfaces. Self-hosting Asterisk means taking on the role of a telecom carrier yourself: you need to configure SIP trunk providers (call termination), handle NAT/firewall, manage codecs and security policies, and ensure high availability. In exchange, you no longer pay per-minute fees to CPaaS providers like Twilio, and all call data can be written directly to your own database. Deploying Asterisk on Vultr, as in this article, is a typical "IaaS + open-source telecom software" combination — suitable for scenarios with high call volume, the need for real-time AI intervention, and sensitivity to data sovereignty.

JARVIS Brain Router: The Cross-Business Logic Hub

The most critical component is a custom routing layer called JARVIS Brain Router. It's responsible for dispatching requests to the correct VAPI agent based on the caller's phone number, customer ID, or business tag, and chaining multiple agents together when necessary to complete cross-business workflows.

For example, a mineral rights inquiry call might first be handled by the rights evaluation agent; if the caller is also a real estate wholesaling lead, the routing layer will automatically create a cross-business task. This kind of logic required extensive webhooks and conditional branches in the Make.com era; now it converges into a lightweight routing service.

Cost Comparison: How Much Does Self-Hosting Actually Save?

The most direct data point the team provided: eliminating over $8,000 per month in SaaS costs. This includes Twilio communication fees, SendGrid email fees, Make.com automation subscriptions, and various middle-platform tools previously purchased to handle scaling growth.

The fixed costs on the self-hosted side are mainly Vultr server fees and the operational investment for the self-hosted Supabase instance. For a business volume running six revenue streams simultaneously, the math is clearly favorable.

More importantly, the latency metric: integration latency dropped from the hundreds of milliseconds or even seconds of cross-SaaS calls to under 100 milliseconds. For voice interaction scenarios, this directly determines how natural the conversation feels.

Why the Traditional Startup Tech Stack Fails at Scale

The implicit argument of this article: a SaaS-centric tech stack sees marginal costs skyrocket as cross-business complexity increases.

Twilio and SendGrid bill by usage — when six businesses share customer outreach, usage stacks up rapidly; Make.com charges by number of operations — in cross-business automation scenarios, operation counts multiply; more fatally, each SaaS tool has its own data model, and cross-tool correlation requires additional development.

The self-hosted approach internalizes these costs: communications go through your own PBX, email through self-built SMTP, automation logic written in Supabase Edge Functions and the JARVIS router. Operating six revenue streams with one engineer from Day One — this in itself is a rejection of the traditional "pile on SaaS first, optimize later" approach.

SaaS pricing models like Twilio, SendGrid, and Make.com typically charge linearly or on a tiered basis by usage — for example, Twilio charges per call minute plus number monthly fees, SendGrid tiers by email volume, and Make.com charges by "number of operations." With a single business line, this model is simple and predictable; but when six business lines share the same customer outreach, call minutes, email counts, and automation operation counts multiply, and bills often grow faster than revenue. The more insidious cost is data silos: each SaaS maintains its own customer model and ID system, and cross-tool correlation requires additional sync tasks or intermediate tables — and this "glue code" itself requires development and maintenance. Self-hosting converts these variable costs into fixed asset investments (servers, ops time), making it more economical at high volume and high diversification.

Implications for AI-Native Infrastructure

The Load Bearing Empire case demonstrates an extreme form of "vertical AI stack integration": self-hosted data layer (Supabase), self-built voice layer (Asterisk), agent layer orchestrated with VAPI, logic layer connected by a custom router.

This architecture isn't suitable for every team — it requires the founder to have considerable backend and telecom engineering skills. But for operations-heavy companies with diverse business lines, dense cross-business logic, and sensitivity to latency and cost, this "tear down SaaS, build your own hub" path provides a reference blueprint.

The core lesson can be summarized as: a unified data layer is the prerequisite for cross-business AI automation, and self-hosted communications is the key step to eliminating usage-based billing anxiety.

One-line Summary

An engineer built an AI stack with self-hosted Supabase, Asterisk, and VAPI to replace SaaS and support six business lines.

Paragraph Summary

Load Bearing Empire's founder runs six business lines simultaneously — real estate wholesaling, demolition services, valet parking, credit repair, mineral rights, and SaaS — previously relying on SaaS tools like Twilio, SendGrid, and Make.com, costing over $8,000 per month with high cross-business integration latency and data locked in vendor silos. The team pivoted to a self-hosted AI stack: a single Supabase instance (98 tables, 42 Edge Functions) as the unified data layer, 26 specialized AI agents deployed on VAPI, a self-built Asterisk 18.10 PBX on Vultr replacing Twilio, and JARVIS Brain Router connecting cross-business workflows. The result: eliminating over $8,000 per month in SaaS costs and reducing integration latency to under 100 milliseconds. The article argues that traditional usage-based SaaS stacks see marginal costs surge as cross-business complexity increases, and self-hosted communications and automation are a viable path at scale.