Jamison Bourque

Engineering — Newton, MA

I've never designed in pictures. I design in prototypes that run.

I came to backend work sideways: fifteen years designing products, half of that shipping front-end code, and the last two building the whole stack for a business I own. The agent system below takes real intake from real customers and decides whether to send a mechanic. Links go to running software, not screenshots.

Where I'm coming from Running in production

I'm not a bootcamp grad. I'm a designer who kept picking up the parts of the stack nobody else wanted, mentored along the way by engineers I recruited by describing something and asking whether it was possible.

At Xbox and T-Mobile I delivered production front-end instead of design files. At Bose I wrote the iOS app for the AR sunglasses onboarding, reading the head-tracking IMU directly. Then I built a business, and building a business meant learning the back half — Python, FastAPI, a VPS, DNS, deploys at eleven at night when the booking form is down.

I'm looking for an engineering role where fifteen years of product judgment is worth something and I get to go deep on the code. I learn fast, I take review well, and I've already shipped the thing most candidates are hoping to build.

How the agent system works
doortodoorrepair.com — request path
customer
   │  photo + symptoms
   ▼
POST /chat  — FastAPI, HTMX partial response
   │
   ▼
intake agent  "Lloyd" — front desk, holds conversation state
   │
   ├─ mechanical?  ──▶ Ruth   drivetrain, brakes, wheels
   ├─ electrical?  ──▶ Hazel  e-bike controllers, sensors, batteries
   └─ pricing?     ──▶ Karl   quotes, membership plans
   │
   ▼
mode gate
   ├─ customer can fix it  ──▶ DIY walkthrough
   └─ needs a visit       ──▶ triage + quote + ETA
   │
   ▼
wake-word handoff  — mechanic named in thread
   │
   ▼
signed JWT join link ──▶ human takes the same conversation

Why HTMX

Chat turns are server-rendered partials. No client framework, no build step, no state duplicated between Python and JavaScript.

Why separate personas

Narrow scope per agent means shorter prompts, fewer wrong confident answers, and a clear place to fix things when one specialist misbehaves.

Why JWT on handoff

The join link lands a mechanic in a live customer thread. It's short-lived and signed so a leaked URL doesn't become an open door.

What I'd change

Routing is currently prompt-driven. A small classifier in front of it would be cheaper, faster, and testable in CI — that's the next build.

Recent example Karl — the pricing agent

The fix was deleting a sentence, not adding five sections

A prompt is code that argues with itself. This one cost me four rounds of live testing before I went looking for the cause instead of writing rules against it.

01
Symptom

The pricing agent kept recommending the expensive tune on brand-new bikes, and lost a $300 booking doing it.

02
Wrong fix

Five new prompt sections and a ceiling rule to outrank it. Four rounds of live testing; every patch opened a new hole.

03
Root cause

One clause written months earlier: "recommend Full." A new section doesn't outrank an old one just because you wrote it later.

04
Result

Deleted the clause. All four failing cases fixed, and the prompt ended up ~20% smaller than before the work started.

Shipped
Project Stack Status

doortodoorrepair.com

The customer intake desk. Four specialist personas take photos and symptoms at any hour, price the job, and get it on the calendar — so the mechanics only ever touch bikes, not phones. Full rewrite from a PHP stack.

FastAPIJinja2HTMX Anthropic APIJWTCloudflare
● In production Live site Source

Figma Layout Automation Tool

Published plugin on the Figma Community. Automates repetitive layout operations that eat a design team's afternoon.

TypeScriptFigma Plugin API
● Published Install

Bike Repair Tracker

Wear-state dispatch engine. Models component life against ride data and triggers a service visit on actual condition instead of a calendar.

PythonFastAPIScheduling
● In production See it

Coverage Map prototypes

Interactive front-end prototypes built against T-Mobile's CSS design system and merged into production rather than redrawn by engineers.

JavaScriptCSSDesign system
● Archived Open

No-code prototyping tool

Let T-Mobile designers assemble working prototypes without writing code. Built pre-LLM, and adopted across the design team.

JavaScriptInternal tooling
● Archived Try it

Some work from Best Buy, Bose, and Owl Labs is under NDA — happy to talk through it.

Open to AI engineering roles. Preferably close to the product.

Python, FastAPI, agent plumbing, and anything where design sense is an asset rather than a distraction.