Open to roles · San Francisco

Full-stack · Production AI · San Francisco

I build production
AI systems end-to-end.

7+ years full-stack. I'm the sole engineer on Brad Paws, where I run a Claude agent, an OAuth2 + PKCE MCP server, and a client portal on Cloudflare Workers. Looking for Forward Deployed, Solutions, or Software Engineer roles in SF.

Brad Paws is live, handling bookings and billing for dozens of paying SF clients.

The operator-engineer who ships production AI, talks to customers, and writes the tests.

→ Email me See the projects

01 Featured work

Three systems running in production, plus a public security audit.

01

Brad Paws Client Portal

A full-stack React 19 + Hono portal on Cloudflare Workers, running a live SF pet-care operation.

Live

Brad Paws is a pet-care business in SF, and this portal is its system of record. Dozens of clients and their pets run through it, with bookings and invoices processed every month. The credential isn't the business, it's the software: I treated a small operation as a place to build production patterns properly. I integrated the operator's existing tools instead of replacing them — Notion stayed the workspace, Google Calendar the scheduling source of truth, and the portal took over everything customer-facing. It's a TypeScript monorepo (client portal, API Worker, sync Worker, shared package) on Cloudflare Workers with D1, KV, R2, and Workflows, no origin server. The hard part was making external APIs feel local. I cache OAuth tokens in KV so 98% of Calendar operations never touch Google's auth endpoint.

React Router 7React 19HonoTypeScriptCloudflare WorkersD1 · KV · R2WorkflowsVitestPlaywright
30+active clients
60+bookings / month
30+invoices / month
98%fewer auth calls
Live site ↗ Code: private — walkthrough on request
Architecture & Infrastructure
  • Architected a TypeScript monorepo (React Router 7 client portal, Hono API Worker, scheduled sync Worker, shared domain package) on a 19-table D1 schema, running on Cloudflare Workers, D1, KV, R2, and Workflows with no origin server
  • Chose this stack around one constraint, that the operator never manages infrastructure: zero monthly cost, no cold starts, nothing to scale, with a documented path to Durable Objects if write concurrency ever demands it
  • UUID primary keys for distributed ID generation, E.164 phone normalization, and ExternalId-based cross-source deduplication throughout
Google Calendar Integration
  • Integrated Google Calendar v3 via service account with KV-backed token caching (55-min TTL), reducing live OAuth calls by ~98% under normal load
  • Implemented multipart/mixed HTTP batching for Calendar writes: raw boundary construction (no library support in Workers), 50 PATCH requests per HTTP call, response parsing, and 429/500/503 retry with exponential backoff, staying within Cloudflare subrequest limits and Google rate constraints during migrations
Reliability — Workflows Backfill
  • Re-architected a fragile calendar backfill that was tripping Cloudflare's subrequest cap into a Cloudflare Workflows fan-out / fan-in: one durable instance per date window, an idempotent count-based fan-in, and exactly-once finalization. Backfills now retry per window and recover from a crash without skipping or double-writing data
  • Built observability for unattended automation: structured JSON logging, workflow run tables, heartbeat rows, cron failure emails, and a watchdog that catches silent never-ran failures
Booking, Invoicing & Payment Pipeline
  • Built conflict-aware booking across boarding, house-sit, and walk/check-in with a server-enforced cancellation policy and fee tiers, plus automatic Google Calendar rollback on DB failure
  • Designed a multi-source payment pipeline (Notion REST, Venmo CSV from R2, Gmail) normalized into idempotent events with per-source cursor commits, and automated past-due detection (grace periods, ambiguous-owner handling) that emails the operator weekly
  • Automated monthly invoicing: pdf-lib synthesis → R2 storage → emailed delivery, with authenticated batch ZIP download (fflate, ~5MB peak memory) behind ownership-verified Hono endpoints
Testing & CI/CD
  • Wrote 1,500+ tests (server coverage near 100%) with Playwright end-to-end suites, covering auth, booking, cancellation, calendar parsing, AI tools, and every dashboard component
  • Gated by a CI pipeline that runs type generation, typecheck, ESLint, Prettier, and tests on every push, with Cloudflare auto-deploy on merge to main and production source maps
02

Brad Paws AI Chat Agent

A production Claude Haiku 4.5 agent with ten tools, two-phase confirmation, and a circuit breaker.

Live

Clients talk to the portal in plain language. The agent runs on Claude Haiku 4.5 through Vercel AI SDK v6, with ten tools wired to the live system: schedule, reschedule, cancel, pull history, send a receipt. Most of the work went into the safety envelope, not the prompt. Destructive tools require two-phase confirmation. There are per-user rate limits, per-conversation token budgets, and a circuit breaker that takes the agent offline when upstream errors spike.

Claude Haiku 4.5Vercel AI SDK v6TypeScriptHonoCloudflare Workers
10 toolslive system access
2-phaseconfirm on mutations
Circuit breakerfails safe on errors
Live demo (gated) ↗ Security audit on request
Agent & Safety Envelope
  • Built the chat agent (Claude Haiku 4.5, Vercel AI SDK v6, 10 tools) with streaming responses over all booking, cancellation, and account services. Every mutation goes through an explicit confirmation card backed by a single-use KV token (5-min TTL), so no destructive action runs without approval
  • Implemented layered cost controls: per-user rate limiting (20 msg/hour), daily token budgets (50k tokens/day), and a circuit breaker (3 failures → 60s cooldown) — bounding API spend while maintaining availability
  • Designed chat persistence with a 20-message sliding window, automatic session rotation at 100 messages, and a 90-day retention cleanup cron
Why it matters: a chat agent in front of a live billing and scheduling system is a liability without guardrails. I put the circuit breaker at the agent layer rather than the model layer, so it still protects the downstream tools when the model itself is the thing misbehaving.
03

Brad Paws MCP Server

A standards-compliant Model Context Protocol server with OAuth2 + PKCE, stateless on Workers V8.

Spec-strict

I exposed the Brad Paws platform to MCP clients so I (and authorized agents) can drive the system from Claude Desktop, Cursor, or anything spec-compliant. The server implements the MCP spec and handles OAuth2 with PKCE for client auth. It's stateless across the Workers V8 fleet: every request stands alone, every token is verified, nothing held in memory between calls. This is the one where I read the spec end to end, twice.

MCP specOAuth2PKCE (RFC 7636)HonoCloudflare Workers
RFC 7636PKCE from scratch
Statelessacross V8 fleet
10 toolssingle source of truth
Code: private — walkthrough on request
MCP Booking Server
  • Built the MCP booking server (@modelcontextprotocol/sdk v1.x, Streamable HTTP) so external AI agents (Claude Desktop) can manage bookings through 10 shared tool definitions
  • Aligned MCP transport with Workers' V8 isolate model: stateless per-request server instances with closure-cached tool state — no server-side sessions, no Durable Objects required
  • Centralized tool definitions across the chat agent and MCP server in a single source of truth (names, Zod schemas, MCP annotations), eliminating behavioral drift between access channels
Authentication & Security
  • Built a full OAuth 2.0 authorization-code flow with PKCE (RFC 7636) from scratch — dynamic client registration, S256 code-challenge verification, single-use authorization codes, refresh-token rotation, IP-based rate limiting against brute-force enumeration, and hashed-token audit logging
  • Implemented cookie-based JWT auth (HS256 via jose) with HttpOnly/Secure/SameSite=Lax cookies and E.164 phone normalization — protecting the client dashboard from XSS and CSRF without a third-party auth provider
  • Added non-blocking D1 audit logging for all OAuth events with indexed queries by owner, action, and timestamp
04

AI Surfaces Audit

A security self-audit of every AI surface in a production Claude agent.

Writeup

I went after my own agent the way a security firm would go after a client's. I listed every AI surface (the chat input, tool outputs that re-enter the prompt, third-party content that lands in context) and walked the attack tree: prompt injection through Notion sync, tool-authority abuse, data exfiltration through tool responses. The writeup covers the findings, the mitigations I shipped, and the risk I chose to live with. It's what I send when someone asks how I think about AI safety once it's in front of customers.

Prompt injection defenseTool authorityThreat modelingMCP
Every surfaceenumerated
In-codemitigations shipped
Audit available on request
Most AI-safety writeups are theoretical. I wanted one grounded in a system I actually had to defend. The mitigations are concrete and live in code: two-phase confirmation, the circuit breaker, scoped tool authority, and a content boundary on third-party data. I kept the public version at the architecture level, so it's useful to a reader without handing an attacker a map.

02 Experience

Seven years of customer-facing engineering, from Salesforce to my own product.

2022 — PresentSan Francisco
Brad PawsFounder · Sole Engineer

Sole engineer on a production stack: a TypeScript monorepo on Cloudflare Workers (D1, KV, R2, Workflows), a Claude agent with ten tools and a full safety envelope, a standards-compliant MCP server, and 1,500+ tests. See the four projects above.

2022San Francisco
FrontSoftware EngineerImpacted by RIF

Redesigned the Node microservice behind two-way email sync, which ran at 1.1M requests/hour, and shipped a REST API for account-level rules that pushed adoption up 30%. Upgraded core email infrastructure handling 200k+ emails/month.

2019 — 2021San Francisco
Total BrainSoftware EngineerImpacted by RIF

Engineering point of contact on enterprise customer-success and sales calls. Owned the HubSpot, Box, and SAML+JWT SSO integrations; migrated the backing store from MSSQL to DynamoDB (50% latency drop) and drove a 60% sign-up increase via Apple/Google/Facebook auth. Enterprise onboarding went from 2+ weeks to 3 days.

2017 — 2018San Francisco
SalesforceSoftware Engineer

Built an OAuth2 security filter for microservice API access control and the React management UI behind it, cutting internal test setup time by 40%. First exposure to security primitives at scale.

03 Technical stack

LanguagesTypeScript · JavaScript · Python · Java · Scala
FrameworksReact 19 · React Router 7 · Node.js · Hono · Vercel AI SDK · Spring · Play
AI & LLMClaude (Haiku, Sonnet) · MCP servers · agentic workflows · tool-use design · prompt-injection defense · AI security audits
Cloud & InfraCloudflare Workers · D1 · KV · R2 · Workflows · AWS · SQS · Docker
DataPostgreSQL · DynamoDB · MSSQL · SQL · NoSQL
Auth & SecurityOAuth2 · PKCE · SAML 2.0 · JWT · SSO · rate limiting · circuit breakers
APIs & IntegrationsREST · Google Calendar v3 · Notion · Gmail · HubSpot · Box · multipart/mixed batching · service-account auth
Testing & DevOpsVitest · Playwright · GitHub Actions · Jenkins · WCAG 2.1 AA

04 About

I'm a full-stack engineer in San Francisco, seven-plus years in. I started at Salesforce in 2017, worked through Total Brain and Front, then went out on my own in 2022. The thread across all of it: I like the seam where engineering meets the customer, and I like owning a system from the database up to the conversation a user has with it.

At Total Brain I was the engineering point of contact on enterprise customer-success and sales calls while owning the integrations and a MSSQL-to-DynamoDB migration. That's where I learned the "Forward Deployed Engineer" job description is real work, not a title. Today I run the whole Brad Paws stack solo: a TypeScript monorepo on a 19-table D1 schema with 1,500+ tests, and durable calendar sync on Cloudflare Workflows. I published an AI security audit because the agent sits in front of a billing system.

What I want next is a Forward Deployed, Solutions, or Software Engineer role in SF at a company shipping AI that's load-bearing. I'm most useful turning a customer ask into a working system, then keeping the trust that earns you the next one.

05 Now

CurrentlyJune 2026

Running Brad Paws and tightening the agent's tool surface around what clients actually ask it to do. Writing a second AI-safety post, this one on tool-authority scoping. Interviewing in SF for Forward Deployed, Solutions, and Software Engineer roles at companies shipping AI that matters to the product. Open to onsite-hybrid in SF, or remote with an SF anchor. Email is the best way to reach me.

06 Get in touch

I'm interviewing for Forward Deployed Engineer, Solutions Engineer, and Software Engineer roles in San Francisco. Best fit is a team that puts engineers in front of customers and ships AI the product actually leans on. Fastest reply is email.

Email
bradburch.jobs@gmail.com
LinkedIn
linkedin.com/in/burchbrad
GitHub
github.com/bradburch
Resume
Brad-Burch-Resume.pdf ↓
Location
San Francisco, CA
→ Email Brad