I design,
build and ship
AI systems

Problem

A pro shop counter is one or two people. Every ring competes with the golfer standing in front of them, and after closing the phone rings out — straight into lost tee times.

Built

An AI phone agent answering 24/7 in natural speech rather than an IVR menu: rates, hours, directions and course-specific questions, then a direct booking link texted to the caller. It works alongside whatever tee sheet the course already runs instead of replacing it.

Stack

Twilio Media Streams · streaming STT/TTS · LLM tool calling · TypeScript · Postgres

Outcome

• 600+Calls answered / month
• 82%Resolved without a callback
• < 1 weekTo take a course live

The hard part On a phone line there is no spinner. Two seconds of silence reads as a dropped call, so the latency budget is the product — and callers talk over the agent, which means handling barge-in without losing the turn. The agent also never guesses at availability: it reads the live tee sheet or it says it does not know, because a confidently wrong booking costs more than a missed call.

Problem

Operators run the business across a tee sheet, a mailing tool, a spreadsheet of leagues and a separate events inbox. Nothing shares a customer record, so nobody can answer which golfers are worth keeping.

Built

One platform covering booking, marketing, leagues, events and analytics, with a Gemini Live voice agent answering the pro shop line against real availability — every call, booking and campaign landing on the same customer record.

Stack

pnpm monorepo · Next.js · Postgres + Drizzle · Gemini Live API

Outcome

• 4 toolsReplaced per course
• ~4 hrsAdmin removed / week
• 92%Bookings self-served

The hard part The AI was never the risk — the schema was. Booking, leagues, events and marketing all describe the same golfer from different angles, and if that identity is not resolved properly at the data layer, every downstream feature quietly disagrees about who the customer is. Getting the model right first is what made the voice agent useful rather than a demo.

Problem

A bug report is a video. A coding agent cannot watch a video, so a human sits through it and translates what happened into words before any work can start.

Built

Captures the screen plus a structured trace of what actually happened — click targets with their DOM selectors, console output, network calls, DOM mutations, screenshots and a timestamped narration transcript — exposed over an MCP server. The agent reads the bug as structured context: which button was clicked, what the console said, which request returned 500.

Stack

Chrome extension (MV3) · Next.js · Express · Cloudflare R2 · MCP server

Outcome

• 6 signalsCorrelated per trace
• ~40Events per recording
• ~3 minSaved per bug handoff

The hard part Five event sources — input, console, network, DOM mutations, narration — each with its own clock and its own volume. A click is only useful if you know which node it hit and what the page did in the 200ms after, which means correlating all five onto one timeline and then throwing most of it away. An agent with an unfiltered trace is worse off than one with none.

Problem

Off-the-shelf email tools cannot express the segments an operator actually cares about, because those segments live in the operating data — visits, spend, recency — not in a list somebody exported last quarter.

Built

A campaign platform with a dynamic segment engine over a 26-table operating schema, queue-backed sending with rate limiting and retries, and background workers handling sync, aggregation, delivery and intelligence.

Stack

TypeScript · Express · Postgres + Drizzle · BullMQ/Redis · SendGrid · React + Vite · Turborepo

Outcome

• 120kSends / month
• 99.2%Delivered
• < 400 msSegment resolution

The hard part Segments are queries, not lists — which is the whole point, and also the problem. A segment has to resolve fast enough to send against while the underlying data keeps moving, so the engine had to stay correct under a schema that is being written to during the send. Drizzle over Prisma was a deliberate call for exactly this reason.

Problem

A phone agent is only worth having if it can do things. Answering is easy; booking, checking and cancelling against a live system while the caller waits on the line is where most voice projects stall.

Built

A voice platform taking inbound PSTN calls through Twilio into a cascade pipeline — speech in, model, speech out — with tool calling that executes real business logic mid-conversation, and a client and control plane on top for configuring agents per line.

Stack

Twilio · Pipecat · Deepgram STT · Claude · Cartesia TTS · Python · Angular + Fastify

Outcome

• ~1.2 sMedian response
• 85%Completed without transfer
• 99.9%Pipeline uptime

The hard part A cascade pipeline spends its latency budget three times over — transcribe, think, speak — before the tool call has even fired. Making a live booking mid-sentence means the model has to commit to an action while the caller is still audible, and the pipeline has to keep the line feeling alive while it happens.