LeRoy Michaelson

I work out what a system should be,
then build the part people touch.

Principal Solutions Architect

In short

Most of what I'm paid for happens before the code: understanding a business well enough to know which problem is actually worth solving, then drawing the boundaries so a team can build it without tripping over each other.

What keeps me interested is the two ends of that — the business case that justifies the work, and the person who has to use the thing on a Tuesday afternoon. Everything in between is negotiable.

Recent work

Memory Thread

2026 · solo build

A one-button voice recorder for a 95-year-old blind man who wanted to tell his life story. Custom Raspberry Pi HAT, multithreaded C++ firmware, studio-grade audio capture, a crash-safe cloud pipeline, remote fleet deploy. Twenty days from ordering parts to a working unit in his hands.

IMAGE SLOT — the school-bus-yellow unit with the red button.
Drops in here when the hero photo lands (ACTION-PLAN item 2), which is also the trigger to revisit the image-led direction in 2b-2.

How I work

Find out what's actually wrong first.

The expensive failures I've watched were not badly built. They were correctly built answers to a question nobody had checked. I spend the early time in the domain — with the people doing the work — because that's where the real requirement lives, and it is rarely the one written down. It's also where you find out what the thing is genuinely worth to the business, which is the number that should decide how much system it deserves.

Draw the seams.

Systems break at their boundaries: front end against back end, digital against analog, software against a person's hands. Most of architecture is deciding where those lines go and then making each side's responsibility narrow enough to state in a sentence.

Leave the team able to continue without me.

An architecture nobody else can extend is a liability with good intentions. The deliverable is usually a working system and a handful of people who now build that way by default.

How the work goes

  1. Understand the domain Enough to argue with a subject-matter expert and sometimes be right.
  2. Draw the boundaries Contracts and responsibilities, written down, before implementation starts.
  3. Build the thin path One real workflow end to end, in front of real users, early.
  4. Hand it over Patterns, review, mentoring, until the team owns it.

Note

I take on a small number of outside engagements.
lrm@integrity-design.com

Writing

What AI actually changed

date

Twenty days across five disciplines. The acceleration was real and it landed nowhere near where I expected — which means the size of the effect depends on a property of the engineer, not the model.