I sell.I build.I automate.
Nine years customer-facing at Patterson Dental across 400+ accounts. Around year six I started building the tools I wished the job came with. Three of them have run in production across three branches since 2024.
A rep's only scarce resource is time in front of a doctor. Everything else is overhead. I build the tools that give it back.
Open to travel and on-site deployment · Canyon Lake, TX
One database behind all three apps.
Three applications in production that share one database and cover the full sales cycle, from finding a practice to closing it. Each tool feeds the next, so the whole territory operation gets faster the longer it runs. More are in development.
Built from problems I hit in my own territory.
Every app here started as a real problem I hit in the field at Patterson Dental. I got tired of the workaround, so I built the fix. Three of these run in production across three branches today. The rest carry honest status badges.
Dental Prospector
Territory intelligence platform for field sales, covering 17,815 live accounts across three regional branches. Territory mapping, rep assignment, whitespace against existing accounts, and pipeline tracking on a live interactive map.
RootCRM
Routes come back about 40% shorter than manual stop ordering, measured by the optimizer against the same stop set. Mobile-first CRM for reps working out of a car: sequences the day geographically so stops are driven in one pass instead of criss-crossing a territory, with one-tap visit logging, GPS auto check-in, and overdue account scoring.
SMCC
Social Media Command Center. Proposal intake, a three-stage tokenized approval chain, asset generation, QR-code RSVP capture, and scheduled campaigns. All the coordination overhead around a branch event, removed.
PracticePulse
Prototype on sample data, not in production with any practice. Morning huddle page, fee schedule analysis, profitability scoring, and benchmarking for owners who want to run tighter operations.
AI Document Scanner
Photograph any document and Claude Vision extracts the tables into a clean Excel spreadsheet. Built for field reps who need data captured on the spot instead of retyped later.
Product Barcode Scanner
Customers scan a product barcode or photograph the item, Claude Vision identifies it, and the order routes to their assigned rep against a 7,638-product distributor catalog.
Patterson Part Finder
Photograph a part or type a partial number and get the catalog match. Claude Vision turns the photo into a search query, then a two-tier lookup runs an exact substring match and falls back to pg_trgm fuzzy matching across 7,638 parts.
Watch It Work
These aren't mockups. Prospector, RootCRM and TinyTally are the live applications, recorded through a proxy that replaces every name and number with synthetic data. PracticePulse is a prototype on sample data. field-notes-to-crm is an open source eval harness, so that walkthrough covers the dataset and the scores instead of a running app. Prospector has a second recording for the manager side, and one covers the schema all three applications share. SMCC has no recording yet.

Dental Prospector
Territory intelligence at scale. 17,815 accounts on a live map, with rep assignment, whitespace, and pipeline tracking across three branches.
Read the case study →
Prospector, the manager view
The same application signed in as a manager. Branch scoping through row level security, the rep leaderboard, contact recency, cycle time off an append-only status history, and the handoff queue.
See the RLS patterns repo →
RootCRM
One-handed CRM for reps in the field. Route-optimized stops, GPS check-ins, and overdue account scoring, all from a single screen.
Ask me for a live demo →
PracticePulse
Practice analytics that surface what the morning huddle misses. Fee benchmarks, profitability scoring, and specialty-level insights in one dashboard.
Ask me for a live demo →
TinyTally
Consumer app, being prepared for App Store submission. A baby tracker built for my own family: offline-first writes, two phones on one family in real time, and a pediatrician report. 1,609 tests across 111 files.
Ask me for a live demo →
One schema behind three apps
How the data model works. Row-level security for reps, managers, admins and inside sales, entity resolution across three source systems in SQL with provenance and rollback, and the status history the analytics read from.
See the entity resolution repo →
Seventy-three seconds, start to finish
The short version, cut from the walkthroughs below it. Three applications in production, 17,815 accounts live on the map out of 22,772 resolved locations, 77 provisioned users, adopted with no mandate.
Read the case study →
field-notes-to-crm
An eval for a Claude extraction prompt, built before the prompt shipped. 150 labelled notes, two prompt versions scored on seven fields, a bug the harness caught in its own metric, and a regression it caught in the prompt. Public repo.
Open the repo →Where a model runs, and how I know it works.
The three territory applications run no AI models. AI was my development tool there, not a product feature. A model does run in three smaller capture tools, where Claude Vision reads a document, a barcode label or a part photo and turns it into something the catalog can match. Before I trust a prompt anywhere, I want a labelled test set to say it is ready.
Claude Code is how I build
Most of the code in the territory apps was written with Claude Code, under rules that live in each repo: the strongest model plans and reviews, a cheaper one writes from an exact spec, and nothing counts as done until the build, the type check and a check against the live app pass. Every session ends with a written handoff, so the next one starts from facts instead of memory.
Evals before I trust a prompt
Two public harnesses, both graded by code rather than by another model. field-notes-to-crm scores a Claude extraction prompt against 150 labelled notes: written rules took contact extraction from 63.3% to 99.7% F1 and cut hallucinations from 19.3% to 12.0%, but dropped activity-type accuracy from 94.0% to 85.3%, and the harness showed which rule did it. crm-agent-evals replays every write a tool-using agent makes. On a one-line prompt, Sonnet carried out seven of eight bulk status-change requests without asking, 72 status changes in all. With six written rules it asked first every time and never wrote to an account the rep had not named.
Midas, the agent system I run for myself
A self-hosted agent system on a mini PC with one 8 GB GPU. Its agents run on local models through Ollama by default, at no per-call cost, and Claude is kept for coding. Memory is a notes vault indexed into a vector store every night, and my Claude Code sessions write their summaries there, so the agents know what I shipped that day. A 25-question retrieval eval runs nightly. One ad-hoc run scored 0 of 25 because the scorer's regex could not match a file path containing a space; scored properly it was 20 of 25, and the same bug had been reporting zero fabrication. I check the scorer before I trust the score.
The Arc
How a Dental Business Consultant became the engineer who builds the field's tools.
Learning the territory
Joined Patterson Dental in May 2017 as a Dental Business Consultant, with a modest territory and a notepad. Learned what 400+ practice owners actually need by driving it every day, not from a case study. Held 85% of key accounts as multi-year partners by building against their own one to five year plans, and those relationships account for the $1.5M+ in influenced recurring revenue.
Teaching myself to build
Taught myself TypeScript, React, and Postgres. First app: a territory intelligence map, built on nights and weekends. Reps in the branch adopted it with no mandate behind it.
Three apps in production
Prospector, RootCRM, and SMCC now run across three Patterson branches: 17,815 live accounts and 77 provisioned users. Claude Vision runs in three companion capture tools. Built Midas, a self-hosted agent system that runs on local models. Still shipping, still carrying a full quota. Now looking to scale what works from one territory to an entire org.
The Proof.
From Inherited Territory to $1.5M+ Influenced
I joined Patterson Dental's San Antonio branch, now part of South Central, and inherited a stagnant territory. No tools. No intelligence. Just a list of accounts and a car.
I built Prospector from scratch on nights and weekends: a live territory intelligence map covering every account I could source in the region. The following week, reps in my branch adopted it. No mandate. No rollout. Just a tool that actually worked.
Today the platform carries 17,815 live accounts across Dallas, Houston, and South Central, out of 22,772 resolved business locations, with 77 provisioned users. Modeled against a 1-in-7 Solea conversion rate, it projects $400K+ in incremental revenue per branch. Territory growth reached 500% from the inherited baseline.
I knew which screen a rep needs in a parking lot because I had been the rep in the parking lot.
I built all three, deployed them, and still support them while carrying a full quota.
Designed, deployed, and maintained solo
Nine years in the territory, then the software to run it.
Nine years selling for a $6B distributor. 400+ accounts across Central Texas. I learned what makes a territory grow by working one, and I ran into the same wall every rep hits: the tools don't match the work. So I stopped waiting for someone to fix it.
First it was simple automations. Then full applications. Three of them now run in production across three Patterson branches, covering the sales cycle from finding a practice to closing it. More are in development. Built nights and weekends, adopted the following week, with no mandate behind any of it.
I answer the customer question and then write the migration, usually in the same week. That is why reps adopt what I build. It was designed by someone who has done the job.
Credentials
Why this is already the job.
Forward deployed engineering is building software next to the person who has the problem. I have been doing that since 2023, with a quota attached the whole time.
I am the end user
Every feature started as a problem I hit in a territory that week. Nobody handed me a requirements doc, so I wrote the spec myself. A rep complaint became a schema change before I touched the UI. I can hold the same conversation with a practice owner, a branch manager, or a database.
Ship weekly while carrying quota
Three applications built since 2023 and running in production since 2024, all of it with a full sales territory on my back. Most features go from field complaint to deployed inside a week, because the feedback loop is a phone call, not a ticket queue.
Adoption is the only metric
Reps adopted all three applications with no mandate and no official project status behind them. Branch leadership backed each expansion because reps asked for it, and users report one to two hours a week returned to selling. I ran the onboarding sessions for reps and managers at all three offices, and was asked to present the tooling to branch leadership at multiple locations.
The engineering decisions underneath
Multi-tenant row-level security governing per-user record visibility: enabled on every table, with 128 policies across the 37 application tables. Geospatial filtering over 22,772 records, entity resolution across three source systems in SQL, tokenized multi-stage approval flows, offline-tolerant mobile behavior. I ran a read-only security review of my own production database before anyone asked; 45 functions now execute only under the service role, no anonymous caller can reach a security-definer function, and I wrote up the architecture for executive review.
The hardest problem in the platform was not the map
It was getting three lists to agree on what a customer location is. A federal provider registry, a places API, and hand-entered rep records describe the same office with three spellings, two suite numbers, and a phone number formatted three different ways. Exact matching finds nothing, and comparing every record against every other record is over 250 million comparisons. So I normalize names, street numbers, and phones; block on a shared phone or a shared street number plus postal code, which leaves a few hundred thousand candidate pairs; score those on trigram name similarity, exact phone match, and coordinate distance; merge above a threshold and queue the middle band for a human; then keep the best value of each field from whichever source had it. The result is 22,772 deduplicated locations across three branches, 17,815 of them live on the map today, and all of it is SQL I can walk you through line by line.
Read the SQL on GitHubThe patterns, written up.
The products themselves run on Patterson data and stay private. These are the techniques underneath them, pulled out and documented so you can read the actual work in a few minutes.
crm-agent-evals
An eval for a tool-using CRM agent. Seven tools over a seeded sales territory, 56 tasks a rep might type between stops, and a grader that replays every write against a fresh database instead of grading the agent's prose. It reports unsafe writes, invented ids and cost across prompts, models and schema modes, and it caught strict tool schemas leaking Sonnet's own markup into search filters: 16 of 238 calls, none with strict off.
field-notes-to-crm
Dictated visit notes to structured CRM activities with Claude, and the eval harness that says how well it works: 150 labelled notes, per-field scores, hallucination rate, cost and a regression gate. Every published number reproduces offline from the committed predictions, in TypeScript and in an independent Python scorer.
rls-multitenant-patterns
Postgres row-level security for multi-tenant field sales apps. Wide reads, narrow writes, and policies with tests against them.
n8n-approval-patterns
Tokenized multi-stage approval workflows. Single-use hashed tokens, GET to confirm and POST to commit, and an audit trail that survives a dispute. CI runs the workflow in a real n8n; its first run found eight bugs.
entity-resolution-postgres
Deduplicating messy business records in Postgres: normalization, blocking, weighted scoring and per-field survivorship. Scored against 1,135 labelled pairs of real registry and OpenStreetMap records: four fixes, measured on the same labels, took the true cross-source matches that reach a merge or a reviewer from 44 of 156 to 133, with 78 of 79 auto-merges right. The write-up says what is still missed.
supabase-security-audit
The read-only audit I ran against my own production database. RLS coverage, anon-callable SECURITY DEFINER functions, unpinned search_path, public buckets.
image-to-excel-converter
Photograph a document and get a clean Excel file back. Claude Vision does the extraction. This is one of three tools where a model actually runs, alongside the barcode scanner and the part finder. Everything else I run in production is deterministic.
Sales, full-stack, applied AI, and the industry itself.
Sales & Territory Management
- 9 years consultative B2B sales
- 400+ account territory management
- Multi-branch onboarding & training
- Competitive intelligence analysis
- Pipeline & CRM strategy
- Solea laser campaign model ($400K+ projected per branch)
Full-Stack Development
- TypeScript, JavaScript, Python and SQL
- React 19, Next.js 16 and Node.js
- Supabase (PostgreSQL, Auth, RLS, Realtime)
- Tailwind v4 and shadcn/ui
- Mapbox GL JS and OpenRouteService
- PWA architecture, CI/CD with Vercel and GitHub
Applied AI
- Claude API: tool use, structured output and Vision
- Evals: labelled sets, per-field scores, regression gates
- Claude Code, with plan-then-verify rules in every repo
- Claude Vision in three shipped capture tools
- Local models via Ollama, retrieval with ChromaDB
- n8n workflow automation
Dental Industry Domain
- 9 years in dental distribution; working knowledge of Patterson, Schein, and Benco go-to-market
- Dentrix · Eaglesoft · Open Dental workflows
- DSO vs. independent practice dynamics
- Capital equipment sales cycle (imaging, lasers, CAD/CAM)
- Salesforce, SAP and HIPAA-regulated environments
- Morning huddle workflow optimization
I have carried a quota and shipped production software at the same time, since 2024.
Nine years in the field. Three applications running in production. One person who does both. If you're hiring a Forward Deployed Engineer or a Solutions Engineer, that combination is the whole job. Let's talk.
Last updated: September 2026
Canyon Lake, TX • Open to travel and on-site deployment
