// the premise

A builder whose output compounds. Since adopting agentic tooling, the leverage keeps multiplying — and so does the pace.

01 / machine · built solo

The software factory

The meta-machine: a control loop that supervises an AI agent building this very codebase — gating its actions, isolating its work, and feeding observability back so it self-corrects.

the hard part Keeping an autonomous agent safe on production work — and the frontier I'm climbing toward: getting many of them to coordinate.
stack ▸ Claude CodeBash hooksgit worktreesGitHub ActionsSlack
◆ You brainstorm → adversarial audit → spec
↓ the spec
the agent · inside the gates
scope → worktree → build → test ↺ → ship
↓ a PR
◆ You review the PR · merge or send back
↺ merge → next intent
  1. SessionStart primes context
  2. PreToolUse scope-gate routes the work
  3. PreToolUse worktree · isolated Postgres
  4. PostToolUse lint + format
  5. pre-push gate · tests · CI

next ▸ many agents, coordinated

02 / machine · built solo

The multi-party transaction CRM

A coordination layer for a transaction whose participants you don't control — opposing agent, a title company you didn't pick, a lender who's never heard of you — built as three role-scoped portals over one Postgres database, each party's slice drawn by row-level security.

the hard part Getting indifferent, even adversarial parties to transact through one surface, each seeing only their slice — enforced in the database, not the UI: RLS policies per user class, a role-keyed field-permission table (hidden / read-only / read-write across five staff roles), and a trigger-driven state machine that advances a deal's stage across submissions, listings, and offers so no object has to know the others' rules.
stack ▸ TypeScriptReactPostgres + RLSpg triggersSupabaseVercel
staging.access.realty/crm/deals
Access Realty CRM deal record — stage progress bar, role-gated tabs, and a computed counter-party label reading 'Buyer Name' on a sell-side deal

one engine, every record This page — and the listing, the list, and the dashboard that follow — are drawn by one generic renderer fed a config object. Twenty-four record types, one component.

  1. Stage state machine Pre-Execution → Closed. Postgres triggers advance the stage across submissions, listings, and offers — and map RESO MLS statuses onto internal stages — so no object has to know the others' rules.
  2. Role-gated tabs The System tab shows because I'm an admin. For a Realtor it isn't rendered at all — gating declared in config and enforced down to a per-field permission table in Postgres.
  3. Computed field labels Our side is Sell, so the counter-party fields read “Buyer.” On a buy-side deal the same config renders “Seller” — a label function declared in config, not an if-statement in the component.
01 / 04

03 / machine · built solo

Home-sale predictive analytics

Stitching dozens of un-normalized county, municipal, court, and utility sources into two models — who's likely to sell, and which homes are likely to profit — then marketing only to the overlap.

the hard part A hard part at every step — every county its own CAD and clerk with no shared schema, court sites scraped, neighborhoods named inconsistently. A poor man's CoreLogic, built so "undervalued vs. peers" actually means something.
stack ▸ FileMaker ProZytePython

A poor man's CoreLogic — dozens of un-normalized public and commercial sources, scraped and fused.

sources
County Clerks Municipal Records Appraisal Districts County Courts District Courts USPS Utility Records Zillow

Most sources feed both models — an appraisal roll gives tenure and value; a court filing signals motivation and equity.

The overlap — both true at once — is where every marketing dollar went.

Door Knock Profield · optimized routes
Zoho CRM widgetremote · sms · telnyx · vapi
  1. 1 Likely to sell — motivation that decays over time: a utility disconnect cools in weeks, a probate or divorce stays warm for months.
  2. 2 Likely profitable — z-score position against the neighborhood cohort: undervaluation, not absolute price.
  3. 3 The hard part — normalizing inconsistently-styled neighborhood names so the peer cohorts are real. The model is only as honest as the entity-resolution under it.

04 / machine · rebuilt with Claude Code

Custom Zoho CRM widget

A custom widget built into Zoho CRM that fuses SMS and Telnyx/Vapi calls into one conversation inbox — then runs scripted Action Plan sequences (timed, merge-fielded, multi-channel) against every lead.

the hard part Building a real-time, multi-channel comms surface inside Zoho's widget sandbox — and keeping the automated outreach TCPA-compliant and carrier-deliverable at scale.
stack ▸ Zoho CRM widgetRingCentralZoho VoiceTelnyxVapiJavaScriptDelugeClaude Code
crm.zoho.com · conversations widget
Custom Zoho CRM conversations widget — unified SMS and call inbox with Action Plan sequencing
  1. Urgent vs. important Helps busy salespeople tell what's urgent — incoming messages — from what's important — planned follow-up — and keep up with both. The Inbox holds the urgent; the Needs-AP queue holds the important.
  2. Signal tags Stage and motivation tags — Inherited, Motivated, Offer Sent — route each lead into the right Action Plan.
  3. Multi-carrier calling Calls and texts ran on RingCentral, then Zoho Voice, now Telnyx — carrier-agnostic, swapped out without touching the workflow.
  4. Call routing Inbound calls route to a live answerer or a Vapi voice agent — by availability and intent — and every call logs inline beside the texts.
  5. Action Plans Scripted, timed SMS and voice sequences with merge fields — "Post-Offer Follow-Up (10-day, 5 touches)"; the next SMS fires if no reply by a set time.
  6. Role-scoped visibility The conversation scope is role-aware — a rep sees their own threads, a manager sees the whole team's — cross-user visibility controlled by role, from one shared widget.

05 / machine · designed & directed

Door Knock Pro

A route optimizer that turns the predictive target list into a day's driving plan — start, end, and a stop budget in; the highest sell-and-profit doors, in the best order, out.

the hard part Maximizing the sell-plus-profit score collected between two fixed points within a stop budget — a prize-collecting routing problem over targets whose scores decay with time.

inputs ▸ start · end · stop budget · predictive target scores

9.28.47.8 START APPOINTMENT
  1. 1 Objective, not shortest path — give it a start, an end, and how many doors you have time for; it maximizes the total sell score + profit score collected along the route (a prize-collecting / orienteering problem).
  2. 2 Anchored to appointments — knocks and leave-behinds bundle onto trips the acquisitions managers were already making, so incremental high-value touches cost almost no drive time.
  3. 3 Scores decay with time — each door's sell score carries a motivational weight that cools as its trigger recedes: a utility disconnect fades in weeks, a divorce stays warm for months.
  4. 4 Fed by the predictive platform — every door is ranked by the same Venn scores; the route just spends the day on the best reachable ones.

06 / machine · built solo

The SEO engine

A programmatic engine that turns live MLS data into a hierarchy of local-market pages — county to ZIP to address — architected from ~585 live pages toward 1.88M, refreshed monthly by an AI editorial routine.

the hard part Keeping 1.88M pages factually fresh and genuinely useful — refreshing 500+ geographies of editorial for ~$50–75 a month, not a newsroom.
stack ▸ AstroTypeScriptSupabase/PostgresVercelAI editorial routine
direct-list.com/home-values/collin-county
DirectList Collin County market-data page
  1. Live MLS data Every figure is computed from ~1.4M live MLS records per geography — median price, days on market, sale-to-list.
  2. 28-metric snapshot A two-phase aggregation precomputes 28 monthly metrics per geo, so trailing stats render instantly across 800+ markets.
  3. Market signal Buyer-vs-seller read derived from months of supply — generated, not hand-written, and defensible on the data.
  4. 24-month trend A rolling time series per geo. An AI editorial routine deepens every page monthly — freshness that compounds into SEO authority.

// by the numbers

What one person shipped

1.4M MLS records synced
365 database migrations
1.88M SEO pages architected
230+ API routes
17 edge functions
10 custom lint rules
5,000 SMS / day, per operator
$50–75 to refresh 500+ geo editorials

// who i am

I'm a builder who optimizes for leverage — I design the machines, and lately orchestrate AI agents to run them, so one person can ship what used to take a team.

I care about real estate specifically because the transaction is needlessly expensive, and that friction stops people from moving to where their work is worth more. Lower the cost of moving and the whole economy gets more fluid.

Most recently I ran a real-estate venture that a rate shock cut short. I used the runway to build an entire product org solo. Now I want a team building at the frontier of agent-orchestrated software.

// get in touch

Looking for the next machine to build.

GitHub LinkedIn Résumé ↓