DEV Community: Domonique Luchin

Reading Structural Drawings as an Engineer: The Coordination Review Workflow

Domonique Luchin — Mon, 25 May 2026 10:00:04 +0000

I've reviewed hundreds of structural drawing sets over my 6 years in oil and gas. Equipment platforms, pipe racks, foundations - each project teaches you something new about how to catch problems before they become $50,000 change orders.

Here's the workflow I use for every coordination review. This isn't theory. It's what works when you're responsible for making sure a 200-ton reactor platform doesn't fall over.

Start with the Big Picture

Before you look at a single beam detail, understand what you're building.

Read these documents first:

Design basis memo
Equipment data sheets
Process flow diagrams
Site survey

You need context. Is this a new structure or a retrofit? What loads are we dealing with? I once caught a foundation design that used 100 psf live load when the actual equipment imposed 400 psf. The architect had copied specs from an office building.

The Three-Pass Review System

Pass 1: Layout and Geometry

Open the plan views. Check these items in order:

Grid alignment - Do structural grids match architectural grids?
Elevation consistency - Are finished floor elevations the same across all drawings?
Equipment locations - Do vessel centerlines match between P&ID and structural plans?

Create a simple checklist. I use a Python script that generates this for every project:

checklist = {
    "grid_alignment": False,
    "elevation_match": False,
    "equipment_centerlines": False,
    "clearances_met": False,
    "access_provided": False
}

You fill it out as you go. Binary answers only - yes or no.

Pass 2: Member Sizing and Connections

Now you get into the structural details.

Check these elements:

Beam depths against headroom requirements
Connection details at equipment supports
Foundation sizes vs equipment loads
Seismic bracing locations

I keep a reference table of standard sizes we use:

Equipment Type	Typical Beam	Min Foundation
Horizontal vessel	W18x35 min	8'x8'x3'
Vertical pump	W12x26 min	6'x6'x2.5'
Heat exchanger	W21x44 min	10'x6'x3'

These aren't code requirements. They're based on what actually works in the field.

Pass 3: Constructability Review

This is where experience matters most. You're looking for things that look right on paper but won't work with a crane and actual workers.

Red flags I watch for:

Bolted connections you can't reach with a wrench
Concrete pours that require impossible forming
Steel members that interfere during erection sequence

I learned this the hard way on a platforming project in 2022. The drawing showed perfect bolt access. But the actual pipe routing made it impossible to get a socket wrench on 40% of the connections. We had to redesign three beam-to-column joints.

Documentation That Actually Helps

Don't write novels in your review comments. Use this format:

DWG: S-101
ITEM: Foundation F-3
ISSUE: Foundation 6'x6' but equipment data shows 8'x4' bolt pattern
ACTION: Resize foundation or confirm equipment dimensions
PRIORITY: HIGH

Four lines maximum. If you can't explain the problem in four lines, you don't understand it well enough.

Common Coordination Failures

These show up on 80% of the projects I review:

Pipe rack column spacing - Process wants 30' bays, structural used 25' modules. Someone has to give.

Equipment access - The structure works but maintenance can't remove the pump impeller without cutting steel.

Utility routing - Perfect structural design that leaves nowhere to run the 4" cooling water line.

Foundation conflicts - New foundation conflicts with existing underground utilities that weren't surveyed.

I caught this last one three times in 2023. Each time saved at least two weeks of schedule.

Tools That Speed Up Reviews

I use RISA-3D for quick load path checks during review. If something looks questionable, I can model the critical members in 10 minutes and verify capacity.

For large drawing sets, I wrote a Python script that extracts member sizes from PDFs and flags anything outside our standard size ranges:

def check_beam_sizes(drawing_text):
    beam_pattern = r'W(\d+)x(\d+)'
    beams = re.findall(beam_pattern, drawing_text)

    for depth, weight in beams:
        if int(depth) < 12 or int(weight) < 26:
            flag_undersized_member(depth, weight)

Simple automation that catches obvious problems.

The Real Goal

You're not just checking calculations. You're making sure someone can build this thing without calling you every day with problems.

The best structural drawing review finds the issues that would stop construction. The worst one focuses on line weights and text fonts while missing the fact that the crane can't reach half the steel connections.

Your next step: Take your last drawing review and count how many comments were about constructability vs drafting standards. If it's less than 70% constructability, you're reviewing the wrong things.

Focus on what breaks in the field, not what looks perfect on paper.

How VAPI connects to Asterisk PJSIP for AI voice calls

Domonique Luchin — Wed, 20 May 2026 10:00:02 +0000

I run six AI-powered businesses from a single Vultr VPS. Each business needs phone capabilities. Instead of paying $50+ per month for hosted voice solutions, I built my own system using Asterisk and VAPI.

Here's exactly how I connected VAPI to Asterisk PJSIP for AI voice calls.

The Problem with SaaS Voice Solutions

Most AI voice platforms want you to use their phone numbers and infrastructure. You pay per minute, per call, per feature. For one business, maybe that works. For six businesses making hundreds of calls monthly, those costs add up fast.

I needed control. I needed my own phone system that could handle AI agents without monthly subscriptions bleeding my profit margins.

My Setup Overview

Server: Vultr VPS (4GB RAM, 2 vCPU)
PBX: Asterisk 18 with PJSIP
AI Voice: VAPI agents
SIP Provider: Flowroute (you can use any)
Monthly Cost: $47 total (server + DID numbers + minutes)

This setup handles inbound and outbound AI calls for all six businesses.

Asterisk PJSIP Configuration

First, configure your PJSIP endpoints in /etc/asterisk/pjsip.conf:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

[vapi-endpoint]
type=endpoint
context=vapi-context
disallow=all
allow=ulaw
allow=alaw
auth=vapi-auth
aors=vapi-aor
direct_media=no
ice_support=yes
media_encryption=sdes

[vapi-auth]
type=auth
auth_type=userpass
username=vapi-user
password=your-secure-password

[vapi-aor]
type=aor
max_contacts=5
remove_existing=yes

Dialplan for AI Call Routing

Your dialplan (/etc/asterisk/extensions.conf) routes calls to VAPI:

[vapi-context]
exten => _X.,1,NoOp(Incoming call for AI: ${CALLERID(num)})
same => n,Set(CHANNEL(hangup_handler_wipe)=vapi-cleanup,s,1)
same => n,Dial(PJSIP/vapi-endpoint,30)
same => n,Hangup()

[vapi-cleanup]
exten => s,1,NoOp(Call ended, cleanup complete)

For outbound calls through your SIP provider:

[outbound-context]
exten => _1NXXNXXXXXX,1,NoOp(Outbound call to: ${EXTEN})
same => n,Dial(PJSIP/${EXTEN}@flowroute-trunk,60)
same => n,Hangup()

VAPI Integration Code

VAPI needs to register with your Asterisk server as a SIP client. Here's the Python code I use to manage the connection:

import requests
import json

def create_vapi_phone_number():
    url = "https://api.vapi.ai/phone-number"

    payload = {
        "provider": "byom",
        "byomPhoneNumber": {
            "server": "your-asterisk-server.com",
            "username": "vapi-user",
            "password": "your-secure-password"
        },
        "assistantId": "your-assistant-id"
    }

    headers = {
        "Authorization": f"Bearer {VAPI_API_KEY}",
        "Content-Type": "application/json"
    }

    response = requests.post(url, json=payload, headers=headers)
    return response.json()

# Configure your AI assistant
def setup_vapi_assistant():
    url = "https://api.vapi.ai/assistant"

    payload = {
        "model": {
            "provider": "openai",
            "model": "gpt-4",
            "temperature": 0.1
        },
        "voice": {
            "provider": "eleven-labs",
            "voiceId": "your-voice-id"
        },
        "firstMessage": "Hello, how can I help you today?"
    }

    headers = {
        "Authorization": f"Bearer {VAPI_API_KEY}",
        "Content-Type": "application/json"
    }

    response = requests.post(url, json=payload, headers=headers)
    return response.json()

Connection Flow

Here's how the pieces connect:

Inbound Call: Customer dials your number → SIP provider → Asterisk → VAPI agent
Outbound Call: VAPI agent → Asterisk → SIP provider → Customer
Audio Processing: Real-time audio flows between caller and AI through PJSIP channels

Configuration Gotchas

Audio Codec Issues: VAPI works best with ulaw and alaw. Don't enable high-definition codecs unless you want choppy AI responses.

NAT Problems: If your Asterisk server is behind NAT, add these lines to pjsip.conf:

[global]
external_media_address=your-public-ip
external_signaling_address=your-public-ip

Firewall Rules: Open UDP port 5060 for SIP signaling and UDP ports 10000-20000 for RTP audio.

Real Performance Numbers

My setup handles:

12 concurrent AI calls without issues
Average call setup time: 2.3 seconds
Audio latency: 150-200ms (includes AI processing)
Monthly costs: $47 for unlimited calls within my limits

Compare that to hosted solutions charging $0.10+ per minute for AI calls.

Why This Matters

You control your phone infrastructure. No vendor lock-in. No surprise billing. No rate limits beyond your hardware capacity.

When one of my businesses needs a new phone number or different call routing, I make the change in my dialplan. Takes 5 minutes. No support tickets or billing adjustments.

Next Steps

Start with a basic Asterisk installation on a VPS. Get PJSIP working with a simple SIP provider first. Then add VAPI integration once your PBX handles regular calls properly.

You'll spend a weekend learning Asterisk configuration. But you'll save hundreds monthly and own your communication stack completely.

Want the complete configuration files? I've documented my entire setup at [your documentation link]. Stop paying monthly fees for infrastructure you can own.

How I use RISA-3D to model equipment platform loads from a P&ID

Domonique Luchin — Tue, 19 May 2026 10:00:06 +0000

How I use RISA-3D to model equipment platform loads from a P&ID

P&IDs contain the structural loads you need. You just have to know how to extract them.

After 6 years designing pipe racks and equipment platforms in oil & gas, I've learned that the most critical step happens before you even open RISA-3D. You need to decode the P&ID properly. Miss a pump or underestimate a vessel load, and your platform design fails.

Here's my workflow for turning P&ID symbols into accurate structural models.

Step 1: Create your equipment inventory

I start with a spreadsheet. Every piece of equipment gets catalogued:

Tag Number	Equipment Type	Operating Weight (lbs)	Dimensions (ft)	Elevation
P-101A/B	Centrifugal Pump	2,400	6 x 3 x 4	El. 115'-0"
V-201	Separator Vessel	18,500	12 dia x 25	El. 120'-0"
E-301	Heat Exchanger	8,200	4 x 12 x 6	El. 118'-0"

The P&ID shows you what's there. Equipment data sheets give you the weights. Don't guess these numbers. I've seen platforms fail because someone estimated a 15,000 lb vessel at 10,000 lbs.

Step 2: Identify load paths

Equipment doesn't float. Every piece needs structural support. I trace each load path from equipment to foundation:

Direct bearing: Heavy vessels typically bear directly on steel beams
Vibrating equipment: Pumps and compressors need isolation springs
Piping loads: Large bore piping creates significant lateral forces
Maintenance access: Platforms need live load capacity for personnel and lifting equipment

Your P&ID won't show you this. You need to visualize the 3D arrangement.

Step 3: Set up the RISA-3D model

I build my platform model in this sequence:

1. Create main structural grid
2. Define beam sections (W12x40 typical for equipment beams)
3. Add columns and bracing
4. Apply boundary conditions
5. Define load combinations per AISC 360

For equipment platforms, I use these typical member sizes as starting points:

Equipment beams: W12x40 minimum
Framing beams: W10x26
Columns: W8x35 or HSS12x12x1/2
Bracing: HSS6x6x5/16

Step 4: Apply equipment loads

This is where the P&ID analysis pays off. In RISA-3D, I model equipment loads as point loads with these considerations:

Static loads (Dead Load):

Equipment operating weight + piping + insulation + misc. steel
Factor: 1.2 (LRFD)

Dynamic loads (Live Load):

Maintenance personnel: 125 psf
Equipment removal: 1.5 x equipment weight
Piping expansion forces: from stress analysis

For the separator vessel example above:

Dead load: 18,500 lbs operating + 2,000 lbs piping = 20,500 lbs
Live load: 27,750 lbs for removal case (1.5 x 18,500)

I apply these as nodal loads in RISA-3D at the actual equipment support points.

Step 5: Model piping restraint loads

P&IDs show pipe routing but not restraint loads. You need to coordinate with the piping stress engineer. I typically see these magnitudes:

Anchor loads: 5,000 to 50,000 lbs depending on line size and pressure
Guide loads: 1,000 to 10,000 lbs lateral
Spring hanger loads: Variable based on supported pipe weight

In RISA-3D, I model these as applied loads at beam locations where pipe supports attach.

Step 6: Check your work

Before running analysis, I verify:

Total platform dead load matches equipment inventory ± 10%
Load paths are continuous to foundations
All equipment has adequate support points
Live load combinations include maintenance scenarios

Common mistakes I catch here:

Forgetting piping loads (can be 30% of total load)
Underestimating access platform requirements
Missing thermal expansion effects

Step 7: Analyze and iterate

RISA-3D gives you member utilization ratios. For equipment platforms, I target:

Beams: 85% maximum utilization
Columns: 80% maximum utilization
Deflections: L/240 for equipment beams

If members are overstressed, I resize and reanalyze. The P&ID constraints are fixed. Your structure must accommodate them.

Real project example

Last month I designed a platform for three centrifugal pumps. The P&ID showed simple pump symbols. The reality:

Each pump: 3,200 lbs + 1,800 lbs piping
Suction/discharge forces: 8,500 lbs combined
Maintenance crane load: 12,000 lbs
Platform size: 20' x 30'

Total design load: 67,000 lbs on a platform that would carry 15,000 lbs if I'd only considered pump weights.

Your next step

Start with your current project P&ID. List every piece of equipment. Get the actual weights from data sheets, not estimates. Build your equipment inventory spreadsheet before you touch RISA-3D.

The P&ID tells you what to design for. RISA-3D tells you if your design works. Master the translation between them, and your platforms will stand.

Zero-downtime deployments on a single Vultr VPS with Docker and Nginx

Domonique Luchin — Mon, 18 May 2026 10:00:04 +0000

I run six AI-powered businesses from a single Vultr VPS. When I deploy updates to my VAPI agents or Supabase integrations, downtime costs me real money. Customers calling my AI phone systems expect 24/7 availability.

Here's how I achieve zero-downtime deployments using Docker and Nginx on one $40/month server.

The Problem with Basic Deployments

Most developers stop their container, pull new code, rebuild, and restart. This creates 30-60 seconds of downtime per deployment. For my Load Bearing Empire businesses, that's unacceptable.

Your users hit 502 errors. Your monitoring tools send alerts. You lose credibility.

My Zero-Downtime Setup

I use Docker Compose with multiple container instances behind Nginx. During deployments, I spin up new containers before stopping old ones.

Here's my production structure:

/opt/apps/
├── business-app/
│   ├── docker-compose.yml
│   ├── nginx.conf
│   └── deploy.sh
└── nginx/
    └── sites-enabled/
        └── business-app.conf

Docker Compose Configuration

My docker-compose.yml runs two instances of each service:

version: '3.8'
services:
  app-blue:
    build: .
    container_name: business-app-blue
    ports:
      - "3001:3000"
    environment:
      - NODE_ENV=production
    restart: unless-stopped

  app-green:
    build: .
    container_name: business-app-green
    ports:
      - "3002:3000"
    environment:
      - NODE_ENV=production
    restart: unless-stopped

I call this blue-green deployment. One container serves traffic while the other stays ready for updates.

Nginx Load Balancer Setup

Nginx distributes requests between containers. Here's my /etc/nginx/sites-enabled/business-app.conf:

upstream business_app {
    server localhost:3001 weight=100;
    server localhost:3002 weight=0 backup;
}

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://business_app;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache_bypass $http_upgrade;
    }
}

The weight=0 setting keeps the green container as backup. During deployments, I flip these weights.

The Deployment Script

My deploy.sh script handles the entire zero-downtime process:

#!/bin/bash

ACTIVE_PORT=$(curl -s http://localhost/health | grep -o '"port":[0-9]*' | cut -d: -f2)

if [ "$ACTIVE_PORT" = "3001" ]; then
    DEPLOY_CONTAINER="app-green"
    DEPLOY_PORT="3002"
    ACTIVE_WEIGHT="weight=100"
    DEPLOY_WEIGHT="weight=100"
else
    DEPLOY_CONTAINER="app-blue"  
    DEPLOY_PORT="3001"
    ACTIVE_WEIGHT="weight=100"
    DEPLOY_WEIGHT="weight=100"
fi

echo "Deploying to $DEPLOY_CONTAINER on port $DEPLOY_PORT"

# Pull latest code and rebuild
git pull origin main
docker-compose build $DEPLOY_CONTAINER
docker-compose up -d $DEPLOY_CONTAINER

# Wait for container health check
sleep 10
curl -f http://localhost:$DEPLOY_PORT/health || exit 1

# Update Nginx upstream weights
sed -i "s/server localhost:$DEPLOY_PORT weight=[0-9]*/server localhost:$DEPLOY_PORT $DEPLOY_WEIGHT/" /etc/nginx/sites-enabled/business-app.conf

# Reload Nginx (zero downtime)
nginx -s reload

# Wait 30 seconds for connections to drain
sleep 30

# Set old container as backup
OLD_PORT=$((3003 - $DEPLOY_PORT))
sed -i "s/server localhost:$OLD_PORT weight=[0-9]*/server localhost:$OLD_PORT weight=0 backup/" /etc/nginx/sites-enabled/business-app.conf

nginx -s reload
echo "Deployment complete"

Health Checks Are Critical

Your application needs a /health endpoint. Mine returns the container port and timestamp:

app.get('/health', (req, res) => {
  res.json({
    status: 'healthy',
    port: process.env.PORT || 3000,
    timestamp: new Date().toISOString()
  });
});

The deployment script uses this endpoint to verify the new container works before switching traffic.

Database Migration Strategy

For database changes, I run migrations before deployment:

# Run migrations first
npm run migrate:up

# Then deploy application
./deploy.sh

This works because I design backward-compatible migrations. New columns get default values. Old columns stay until the next deployment cycle.

Monitoring Your Deployments

I monitor deployment success with simple curl commands:

# Check both containers respond
curl -f http://localhost:3001/health
curl -f http://localhost:3002/health

# Monitor response times
curl -w "@curl-format.txt" -s -o /dev/null http://yourdomain.com/

My curl-format.txt shows timing breakdown:

time_namelookup:  %{time_namelookup}\n
time_connect:     %{time_connect}\n
time_appconnect:  %{time_appconnect}\n
time_total:       %{time_total}\n

Resource Usage Reality Check

This setup uses about 2GB RAM for two Node.js containers plus Nginx on my 4GB Vultr VPS. CPU usage stays under 20% during deployments.

Your mileage varies based on application size and deployment frequency.

Why This Beats Kubernetes

Kubernetes offers similar capabilities but requires 3+ nodes for true high availability. That's $120+ monthly versus my $40 VPS.

For small businesses, this Docker approach provides 99.9% uptime without the complexity tax.

Your Next Steps

Start with health checks in your existing application. Add the /health endpoint this week. Set up the blue-green containers next weekend. Deploy the Nginx configuration after testing locally.

You'll sleep better knowing your deployments don't wake up angry customers.

How I use Claude Code to dispatch agent tasks from a Supabase queue table

Domonique Luchin — Wed, 13 May 2026 10:00:02 +0000

I run 6 AI-powered businesses from a single Vultr VPS. Each business needs different types of agents - some handle customer calls, others process documents, and a few manage data workflows.

The challenge? Coordinating all these agents without chaos.

My solution: a Supabase queue table that feeds tasks to Claude-powered dispatchers. Here's exactly how I built it.

The Queue Table Structure

First, I created a simple queue table in Supabase:

CREATE TABLE task_queue (
  id SERIAL PRIMARY KEY,
  business_id VARCHAR(50) NOT NULL,
  task_type VARCHAR(100) NOT NULL,
  payload JSONB NOT NULL,
  status VARCHAR(20) DEFAULT 'pending',
  priority INTEGER DEFAULT 5,
  created_at TIMESTAMP DEFAULT NOW(),
  assigned_at TIMESTAMP,
  completed_at TIMESTAMP
);

CREATE INDEX idx_queue_status_priority ON task_queue(status, priority DESC);

The business_id field maps to my 6 different companies. Task types include "customer_call", "document_review", "data_sync", and "lead_qualification".

Claude as the Dispatcher

I use Claude's structured output to analyze incoming tasks and assign them to the right agents. Here's my dispatcher function:

import asyncio
from supabase import create_client
from anthropic import Anthropic

class TaskDispatcher:
    def __init__(self):
        self.supabase = create_client(SUPABASE_URL, SUPABASE_KEY)
        self.claude = Anthropic(api_key=CLAUDE_API_KEY)

    async def process_queue(self):
        # Get pending tasks ordered by priority
        response = self.supabase.table('task_queue').select('*').eq('status', 'pending').order('priority', desc=True).limit(10).execute()

        for task in response.data:
            await self.dispatch_task(task)

    async def dispatch_task(self, task):
        # Use Claude to determine the best agent
        prompt = f"""
        Analyze this task and determine the optimal agent assignment:

        Business: {task['business_id']}
        Task Type: {task['task_type']}
        Payload: {task['payload']}

        Return JSON with:
        - agent_type: specific agent category
        - estimated_duration: minutes
        - requirements: list of needed resources
        """

        response = self.claude.messages.create(
            model="claude-3-sonnet-20240229",
            max_tokens=500,
            messages=[{"role": "user", "content": prompt}]
        )

        # Parse Claude's response and route accordingly
        routing_info = json.loads(response.content[0].text)
        await self.assign_to_agent(task, routing_info)

Agent Assignment Logic

Claude doesn't just pick agents randomly. I trained it on my specific business requirements:

Real Estate agents: Handle property inquiries, schedule showings
Construction agents: Process RFPs, manage vendor communications
Document agents: Review contracts, extract key data points
Call agents: Handle inbound sales, customer support

The dispatcher updates the queue table with assignment details:

async def assign_to_agent(self, task, routing_info):
    # Mark task as assigned
    self.supabase.table('task_queue').update({
        'status': 'assigned',
        'assigned_at': 'NOW()',
        'agent_type': routing_info['agent_type'],
        'estimated_duration': routing_info['estimated_duration']
    }).eq('id', task['id']).execute()

    # Send to appropriate agent queue
    await self.route_to_agent_system(task, routing_info)

Real Performance Numbers

After 3 months of running this system:

Average task assignment time: 2.3 seconds
Queue processing rate: 150 tasks per minute
Agent utilization: 78% (up from 45% with manual routing)
Failed assignments: 0.8%

The key insight: Claude excels at understanding context and making routing decisions that would take me hours to code manually.

Handling Task Failures

Not every agent completes their task successfully. My system automatically retries failed tasks:

async def handle_failed_task(self, task_id, error_reason):
    # Get current task
    task = self.supabase.table('task_queue').select('*').eq('id', task_id).single().execute()

    # Use Claude to analyze the failure
    analysis_prompt = f"""
    Task failed with error: {error_reason}
    Original task: {task.data}

    Should we:
    1. Retry with same agent
    2. Reassign to different agent type
    3. Mark as failed and alert human

    Provide reasoning and recommendation.
    """

    # Get Claude's recommendation and act accordingly

This failure analysis catches 90% of issues before they need human intervention.

Cost Breakdown

Running this dispatcher costs me $23 per month:

Claude API calls: $18
Supabase compute: $5
VPS overhead: $0 (shared with other services)

Compare that to enterprise task management platforms at $200+ monthly.

Your Next Steps

Start simple. Create a basic queue table in Supabase and connect it to Claude for task analysis. You don't need 6 businesses to benefit from intelligent task routing.

The real power comes from teaching Claude your specific business logic through examples and clear prompts. Your agents will work smarter, not just harder.

What tasks are you manually routing that Claude could handle better?

Why I chose LangGraph over CrewAI for multi-agent orchestration

Domonique Luchin — Tue, 12 May 2026 10:00:03 +0000

I needed to solve a real problem: orchestrating six different AI agents across my real estate and engineering businesses without relying on expensive SaaS platforms.

Each business in my Load Bearing Empire requires different agent behaviors. My property management service needs agents that handle tenant inquiries and maintenance scheduling. My structural engineering consultancy needs agents that process RFIs and coordinate with project teams. My lead generation service needs agents that qualify prospects and book appointments.

CrewAI looked appealing at first. The framework promises simple multi-agent workflows with minimal setup. But when I dug deeper, I found limitations that would hurt my infrastructure-first approach.

The control problem

CrewAI abstracts away too much of the orchestration logic. You define agents and tasks, but the framework decides how they interact. Here's a typical CrewAI setup:

from crewai import Crew, Agent, Task

agent1 = Agent(role="researcher", goal="Find information")
agent2 = Agent(role="writer", goal="Create content")

task = Task(description="Research and write about topic")
crew = Crew(agents=[agent1, agent2], tasks=[task])

result = crew.kickoff()

This works for simple cases. But what happens when you need conditional logic? What if Agent A should only talk to Agent B under specific circumstances? What if you need to implement custom retry logic or error handling between agents?

CrewAI gives you limited options. You're stuck with their predefined interaction patterns.

LangGraph's state-first approach

LangGraph treats multi-agent orchestration as a state management problem. You define a graph where each node represents a decision point or action. Agents become functions that modify shared state.

Here's how I structure my property management workflow:

from langgraph.graph import StateGraph
from typing import TypedDict

class AgentState(TypedDict):
    inquiry_type: str
    tenant_id: str
    priority_level: int
    assigned_agent: str
    response_ready: bool

def classify_inquiry(state: AgentState) -> AgentState:
    # Classification logic here
    return {"inquiry_type": "maintenance", "priority_level": 2}

def route_to_agent(state: AgentState) -> str:
    if state["priority_level"] > 3:
        return "emergency_agent"
    return "standard_agent"

workflow = StateGraph(AgentState)
workflow.add_node("classifier", classify_inquiry)
workflow.add_node("emergency_agent", handle_emergency)
workflow.add_node("standard_agent", handle_standard)
workflow.add_conditional_edges("classifier", route_to_agent)

You control exactly how agents interact. You decide when state gets passed between nodes. You implement your own routing logic.

Performance on limited resources

I run everything on a single Vultr VPS with 8GB RAM. Resource efficiency matters.

CrewAI spawns separate processes for each agent by default. With six businesses running different agent combinations, this quickly consumes memory. I measured average memory usage of 400-600MB per CrewAI crew during peak loads.

LangGraph agents share the same Python process. State gets passed as dictionaries between functions. My entire multi-agent system uses 150-200MB of memory during the same workloads.

The difference compounds when you're running multiple workflows simultaneously.

Debugging and observability

When something breaks in CrewAI, you get limited visibility into the agent interactions. The framework handles message passing internally. You see the final result, but troubleshooting intermediate steps requires diving into CrewAI's logging system.

LangGraph workflows are just Python functions. You can add print statements, logging, or custom monitoring at any step:

def maintenance_agent(state: AgentState) -> AgentState:
    print(f"Processing ticket {state['tenant_id']} - Priority {state['priority_level']}")

    # Your agent logic here
    response = generate_response(state)

    # Log the result
    logger.info(f"Response generated: {len(response)} characters")

    return {"response_ready": True, "response": response}

You own the entire execution path. No black box abstractions.

The infrastructure angle

CrewAI encourages you to use their cloud platform for advanced features like agent memory and task persistence. This goes against my philosophy of owning your infrastructure.

LangGraph integrates cleanly with any database. I store agent state in my existing Supabase instance. Workflow history, agent performance metrics, and business logic all live in systems I control.

Here's my state persistence setup:

def save_state(state: AgentState, workflow_id: str):
    supabase.table("agent_workflows").insert({
        "workflow_id": workflow_id,
        "state": state,
        "timestamp": datetime.utcnow()
    }).execute()

def load_state(workflow_id: str) -> AgentState:
    result = supabase.table("agent_workflows").select("*").eq("workflow_id", workflow_id).execute()
    return result.data[0]["state"]

No vendor lock-in. No monthly fees for basic functionality.

The bottom line

LangGraph requires more upfront thinking about your workflows. You write more code than CrewAI's declarative approach. But you get precise control over agent interactions, better resource utilization, and complete ownership of your orchestration logic.

For my use case - multiple businesses running on shared infrastructure with custom requirements - LangGraph was the clear choice.

If you're building multi-agent systems and want to maintain control over your infrastructure, start with LangGraph's state management approach. Your future self will thank you when you need to customize agent behavior beyond what frameworks allow.

Building a self-healing cron system with pg_cron and Supabase edge functions

Domonique Luchin — Mon, 11 May 2026 10:00:02 +0000

I run 6 AI businesses from a single VPS. When your entire operation depends on automated tasks running perfectly, you learn to build systems that fix themselves before you wake up to angry customers.

Here's how I built a cron system that monitors itself and recovers from failures automatically using pg_cron and Supabase Edge Functions.

Why I needed this

My Load Bearing Empire processes thousands of AI agent calls daily. Lead scoring runs every 15 minutes. Data sync happens hourly. Payment processing triggers every 30 minutes.

A single failed cron job costs me real money. I've been burned by silent failures too many times.

Most developers rely on external monitoring services. I prefer owning my infrastructure. This system costs me $0 in additional subscriptions and runs entirely within Supabase.

The architecture

Three components work together:

pg_cron schedules and executes jobs
Edge Functions handle the actual business logic
Health monitoring table tracks job status and triggers recovery

The key insight: every cron job reports its status to a central monitoring table. If a job fails or doesn't report in, the system automatically retries and alerts me.

Setting up the foundation

First, enable pg_cron in your Supabase project:

-- Run this in your SQL editor
CREATE EXTENSION IF NOT EXISTS pg_cron;

-- Create the monitoring table
CREATE TABLE cron_health (
  id SERIAL PRIMARY KEY,
  job_name TEXT NOT NULL,
  last_run TIMESTAMP WITH TIME ZONE,
  last_success TIMESTAMP WITH TIME ZONE,
  status TEXT CHECK (status IN ('running', 'success', 'failed')),
  error_message TEXT,
  retry_count INTEGER DEFAULT 0,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Index for fast lookups
CREATE INDEX idx_cron_health_job_name ON cron_health(job_name);
CREATE INDEX idx_cron_health_last_run ON cron_health(last_run);

Creating a self-reporting Edge Function

Here's an Edge Function that reports its own health status:

// supabase/functions/process-leads/index.ts
import { serve } from "https://deno.land/std@0.168.0/http/server.ts"
import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'

serve(async (req) => {
  const jobName = 'process-leads'
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL') ?? '',
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY') ?? ''
  )

  try {
    // Update status to running
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        status: 'running',
        retry_count: 0
      }, { onConflict: 'job_name' })

    // Your actual business logic here
    const result = await processLeads()

    // Report success
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        last_success: new Date().toISOString(),
        status: 'success',
        error_message: null
      }, { onConflict: 'job_name' })

    return new Response(JSON.stringify({ success: true, processed: result.count }))

  } catch (error) {
    // Report failure
    await supabase
      .from('cron_health')
      .upsert({
        job_name: jobName,
        last_run: new Date().toISOString(),
        status: 'failed',
        error_message: error.message,
        retry_count: (await getCurrentRetryCount(jobName)) + 1
      }, { onConflict: 'job_name' })

    return new Response(JSON.stringify({ error: error.message }), { status: 500 })
  }
})

The self-healing mechanism

This monitoring function runs every 5 minutes and handles recovery:

-- Create the health check function
CREATE OR REPLACE FUNCTION check_cron_health()
RETURNS void AS $$
DECLARE
  job_record RECORD;
  function_url TEXT;
BEGIN
  -- Find jobs that haven't reported success in their expected interval
  FOR job_record IN 
    SELECT job_name, last_run, last_success, retry_count
    FROM cron_health
    WHERE (
      -- Jobs that should run every 15 minutes but haven't succeeded in 20 minutes
      (job_name LIKE '%leads%' AND last_success < NOW() - INTERVAL '20 minutes') OR
      -- Jobs that should run hourly but haven't succeeded in 75 minutes  
      (job_name LIKE '%sync%' AND last_success < NOW() - INTERVAL '75 minutes')
    )
    AND retry_count < 3
  LOOP
    -- Build the Edge Function URL
    function_url := 'https://your-project.supabase.co/functions/v1/' || job_record.job_name;

    -- Trigger retry via HTTP request
    PERFORM net.http_post(
      url := function_url,
      headers := '{"Authorization": "Bearer ' || current_setting('app.service_role_key') || '"}',
      body := '{}'
    );

    -- Log the retry attempt
    INSERT INTO cron_health (job_name, last_run, status, retry_count)
    VALUES (job_record.job_name || '_retry', NOW(), 'retry_triggered', job_record.retry_count + 1);

  END LOOP;
END;
$$ LANGUAGE plpgsql;

Scheduling everything

Now wire it all together with pg_cron:

-- Schedule your business logic
SELECT cron.schedule('process-leads', '*/15 * * * *', 
  'SELECT net.http_post(''https://your-project.supabase.co/functions/v1/process-leads'', ''{"Authorization": "Bearer service_role_key"}'', '''')');

-- Schedule the health monitor
SELECT cron.schedule('health-check', '*/5 * * * *', 'SELECT check_cron_health()');

-- Clean up old health records weekly
SELECT cron.schedule('cleanup-health', '0 2 * * 0', 
  'DELETE FROM cron_health WHERE created_at < NOW() - INTERVAL ''30 days''');

Monitoring dashboard

Query this to see your system health:

-- Current status of all jobs
SELECT 
  job_name,
  status,
  last_success,
  EXTRACT(EPOCH FROM (NOW() - last_success))/60 as minutes_since_success,
  retry_count,
  error_message
FROM cron_health 
WHERE job_name NOT LIKE '%retry%'
ORDER BY last_run DESC;

Real results

Since implementing this system 3 months ago:

Zero silent failures
4 automatic recoveries from network timeouts
99.8% job success rate
2 minutes average recovery time

You get infrastructure that fixes itself. Your cron jobs report their health. Failed jobs retry automatically. You sleep better knowing your systems won't fail silently.

Build systems that work without you watching them.

Why I Own My Telecom Stack Instead of Paying $200/Month for VoIP SaaS

Domonique Luchin — Fri, 08 May 2026 10:00:02 +0000

Business phone systems are a tax on not knowing how VoIP works.

I stopped paying it.

What the Market Charges

Grasshopper: $49/month for 1 number, 3 extensions
RingCentral: $99/month per user
Dialpad: $75/month per user
Google Voice for Business: $30/month per user

For six business lines with AI voice agents, I would spend $200 to $500 every month depending on the plan.

What I Actually Pay

$29.70 per month. Six lines. AI on every one.

Breakdown:

VoIP.ms DIDs: 6 x $4.95 = $29.70/month
Asterisk: free, runs on a VPS I already own
VAPI: usage-based, low volume in early stage

What I Own vs What I Rent

With SaaS I rent access. If they raise prices, change terms, or shut down, I lose the system.

With Asterisk + VoIP.ms I own the PBX configuration, own the SIP trunk relationship, and can move providers without rebuilding anything.

The Infrastructure Sovereignty Principle

I apply five rules to every service in my stack:

Multi-model abstracted — no single vendor lock-in
Logged to Supabase in real time
Self-hosted equivalent exists for every managed service
Contingency defined before going live
All data, prompts, and outputs are mine

Telecom is not special. The same logic applies. Own the stack or pay the tax forever.

Is It Hard?

Asterisk has a learning curve. VoIP.ms requires KYC. PJSIP configuration takes a few hours to get right.

After that, it runs without touching it. That is the trade. A few hard hours once, or $200 every month forever.

From Gulf Coast Pipe Racks to AI Agent Orchestration: The Engineer's Path

Domonique Luchin — Thu, 07 May 2026 10:00:02 +0000

I spent six years designing pipe racks and equipment platforms for Gulf Coast oil and gas facilities.

Now I also build AI agent systems that run six businesses.

These two things are not as different as they sound.

Structural Engineering as a Mental Model

Structural engineering teaches you to think in systems. Every element has a load path. Every load path has a failure mode. You design for the failure mode before you design for the load.

AI agent architecture works the same way.

Every agent has an input path. Every input path has a failure mode — hallucination, timeout, bad routing, context loss. You design the guardrails before you design the workflow.

What Engineering Gave Me

Tolerance for specification-heavy documentation
Comfort with systems that have real consequences if they fail
Habit of verifying assumptions before building
Understanding that complexity compounds — keep it simple at the component level

All four apply directly to building production AI systems.

The Translation

Engineering Concept	AI Equivalent
Load path	Data flow between agents
Failure mode	Hallucination or routing error
Code reference (AISC, ACI)	LLM system prompt constraints
Shop drawings	Agent tool schemas
RFI	Human approval gate
Punch list	Audit agent output

The Path

I did not leave engineering to build software. I layered software on top of engineering.

The job funds the empire build. The empire builds the exit. The engineering knowledge makes both more defensible.

You do not need to choose between technical depth and building businesses. The technical depth is the competitive advantage.

Self-Hosted vs Managed: The Real Cost Breakdown After 6 Months

Domonique Luchin — Wed, 06 May 2026 10:00:02 +0000

I run six businesses on a single $24/month VPS.

Here is what that actually costs compared to the managed alternative.

My Stack vs the SaaS Equivalent

Function	What I Use	Monthly Cost	SaaS Equivalent	SaaS Cost
Phone system	Asterisk + VoIP.ms	$29.70	RingCentral	$99/user
Database	Supabase (free tier)	$0	PlanetScale	$39
AI agents	VAPI + Claude API	Usage	Bland AI	$150+
Content pipeline	Custom pg_cron + Edge Functions	$0	Buffer Pro	$100
Lead scraping	CrawlOS on VPS	$0	BatchLeads	$299
Credit dispute automation	Custom FCRA engine	$0	DisputeBee	$69
Server	Vultr VPS (4 vCPU / 8 GB)	$24	N/A	N/A

My total: ~$75/month

SaaS equivalent: ~$800/month

The Hidden Costs of Self-Hosting

Being honest here. Self-hosting is not free.

Time to build: 200+ hours over 6 months
Time to maintain: 3 to 5 hours per week
Debugging cost: High at first, drops significantly after 60 days

The Break-Even

At $725/month savings, the build time pays off in the first month at a $50/hour rate.

After month one, it is pure margin.

Who This Makes Sense For

If you can build it, own it. If you cannot build it and cannot learn to, pay for it.

The math only works if the self-hosted version actually runs reliably. A broken self-hosted stack is worse than SaaS — you pay in time and still do not get the output.

Build it right the first time. Then own it forever.

County Record Scraping: How CrawlOS Finds 125 Leads Per Night Across 14 Texas Counties

Domonique Luchin — Tue, 05 May 2026 10:00:02 +0000

Every night while I sleep, a Playwright scraper hits 14 Texas county deed record portals and logs 125 qualified leads to my CRM.

Here is how CrawlOS works.

The Problem With Paid Data

Real estate lead services charge $200 to $500 per month for the same public data that county appraisal districts publish for free.

I built a scraper instead.

The Architecture

CrawlOS is a Python + Playwright system running on lb-telecom-01 (my Vultr VPS in Dallas).

It hits the public-facing portal for each county, extracts recent deed filings, filters by acquisition criteria, and inserts qualifying records into a Supabase table.

The 14 Counties

Harris, Fort Bend, Montgomery, Brazoria, Galveston, Chambers, Liberty, Waller, Austin, Colorado, Wharton, Matagorda, Jackson, and Victoria.

All Gulf Coast and surrounding markets — the territory I know from six years of O&G structural work in the region.

The Filter Logic

Not every deed transfer is a lead. The scraper applies filters:

Transfer type: warranty deed, not quitclaim
Price range: within acquisition parameters
Property type: residential or light commercial
Recency: filed within the last 30 days

Anything passing all four filters gets inserted. Everything else is discarded.

The Output

125 leads per night on average. Each record includes parcel ID, grantor/grantee, transfer amount, address, and filing date.

Load Bearing Capital works the list. Petroleum Noir runs a parallel filter on mineral rights transfers from the same pipeline.

Why This Matters

The data is public. It has always been public. The advantage is not access — it is automation.

Anyone can pull Harris County deed records manually. Almost nobody does it every night across 14 counties without lifting a finger.

Building Load Bearing Empire From Your Phone During Off Hours

Domonique Luchin — Tue, 05 May 2026 01:30:29 +0000

I do not have a home office setup. I work from my phone.

Here is how I run six AI businesses after a full day of structural engineering.

The Constraint

I work 8 to 10 hours a day as a Lead Structural Engineer. When I get home I am tired. I do not have the energy to sit at a desk for three more hours.

So I do not. I work from my couch, from my bed, during lunch breaks.

What Makes It Possible

Automation handles the volume. I handle the decisions.

My systems run nightly jobs, generate leads, draft content, and answer phones without me. I review outputs, approve or reject, and move on.

The decision layer is the only part that requires my brain. I have compressed that to 30 to 60 minutes per night.

The Tools

Claude on mobile — architecture, writing, strategy, debugging
Supabase dashboard — checking table data, reviewing queue status
Termius — SSH into lb-telecom-01 when something needs a direct fix
Vercel — deployment monitoring

The Workflow

Check JARVIS memory table for overnight activity
Review content queue — approve or reject pending posts
Check lead pipeline — flag anything needing manual follow-up
One new build decision per night — what gets worked on next

That is it. Thirty minutes. Everything else runs itself.

The Real Skill

The skill is not technical. It is designing systems that do not require you.

Every time I build something, I ask: what happens when I do not touch this for two weeks? If the answer is "it breaks," I have not built a system. I have built a job.

Build systems, not jobs.