How I work.
If you're trying to figure out whether to bring me in, this is what you're actually buying, and where the whole approach came from.
What this looks like on a Tuesday.
What the work is
The job, on a normal day.
- Sitting with the actual user.On a call, in their tool, in their office. Watching what they actually do, not what the spec says they do.
- Troubleshooting the technical layer myself.Reading logs, fixing configs, writing the integration. The customer doesn't need an escort.
- Translating what the customer means into what the product needs.The signal is usually buried in the third thing they say, not the first.
- Writing the automation when something gets repetitive.If I do a task more than three times by hand, something's wrong.
- Staying past the launch.The first three weeks are when you find out what's actually true.
What the work isn't
What I don't sign up for.
- Treating every account the same.The template approach is a leading indicator of churn.
- Shipping and walking away.If I don't know whether it worked, I haven't finished.
- Pretending I don't know how the code works.I do. It's faster for everyone if I read the stack trace myself.
- Building features for a deck.If we can't define how we'll measure whether it worked, that's a real conversation to have first.
An unconventional path to staying close to the customer.
Ten years ago I was running fire protection crews at a nuclear plant in South Carolina. It's a job where the cost of a small mistake is well-documented and the cost of a careful one is invisible. You learn fast to be the second kind of person.
I taught myself to code on nights and weekends because I wanted to build things that helped people more than once a decade. I started small, took freelance work, and kept getting deeper into the part of the job nobody else wanted: figuring out what the customer actually needed, not what they'd asked for.
The technical side opened up from there: health-tech engineering, HIPAA platforms, eventually agentic AI systems on Bedrock and four AWS AI/ML certifications in 2025. But the through-line never changed. The most useful thing I've ever done is stay close to the person trying to use the thing.
Things people tend to ask.
What if you don't already know my industry?+
I've worked across pharma, education, physical therapy, continuous glucose monitoring, medical devices, and now AI/ML platforms. The pattern that holds across all of them: the technical surface keeps changing, but the work doesn't. Figure out the actual problem, ship something useful, find out whether it helped. I get up to speed by sitting close to the people who already know the domain, then build from there.
How do you actually measure whether something worked?+
It depends on what we shipped. For TechFix it was student engagement and admin hours recovered. For Morphose it was clinician adoption and patient adherence. The trick isn't picking the metric. It's naming it before you build and then being willing to look at it honestly afterward. Most projects skip the second part.
Why solo? Why not build out a team?+
I've worked in teams, on contracts, as a founder, and as the only engineer in the room. Solo isn't a permanent religion. It's the configuration where I add the most value, because the value lives in the gap between customer, code, and outcome. That gap doesn't survive being handed off across three departments.
You're in Montana. Does that get in the way?+
Mountain Time overlaps cleanly with most US business hours and most of Europe before lunch. I've worked async with teams across four continents. Remote and async aren't a perk for me. They're how I work best, and have for a decade.
What kind of work won't you take on?+
Anything where I can't get close to the people who have to use the thing. Anything where “success” is defined as “shipped” rather than “did the thing we said it would do.” Anything where the only success metric lives in a slide deck.