Customer Workflow Discovery
Getting close enough to a workflow to understand what people need to decide, route, review, or explain.
- Discovery through real examples
- Handoffs, edge cases, and review states
- Clear success criteria before automation
BACKGROUND
Customer workflows, AI systems, and production-minded interfaces.
I like work where the real problem is hidden in handoffs: customer context spread across tools, engineering state that is hard to interpret, and AI output that needs to be useful without becoming opaque.
Working Range
Production-Shaped Builds
Building projects with the same boundaries I would want in production: typed contracts, tests, local fixtures, and deployable service shapes.
- AWS Lambda and SAM-style deployments
- Slack apps, webhooks, and API clients
- Mock services for reviewable local runs
AI System Design
Using LLMs where they can compress investigation or drafting, while keeping source data, guardrails, and human judgment visible.
- Tool use over source systems
- Forced structured outputs
- Bounded cost, latency, and failure modes
Product Interfaces
Designing screens that make operational state readable: what changed, why it matters, and what should happen next.
- Dashboards and account views
- Slack-native command surfaces
- Reviewable AI drafts and handoffs
How I Think About Tools
01
Make the real workflow visible. Good tools respect the steps people are already taking.
02
Build close to the problem. The first useful version should exercise real data shapes, integration points, and review paths.
03
Design for trust. People need to know what changed, why it changed, and where their judgment still matters.