← All posts

The title comes from companies that put engineers inside the customer’s business because the product only worked once it was wired into the customer’s actual mess. I use it because it describes how I work, not because of where I sit on an org chart.

The shape of the job

• 1Discovery. Interviews and direct observation with the people doing the work. On a manufacturing engagement that meant the retail counter and the shop floor.
• 2Mapping. The workflow as it actually runs, with the handoffs, the spreadsheets and the places it stalls.
• 3Requirements. Written down, in the business’s words, before code.
• 4Build. Usually TypeScript, React and Postgres, with LLM steps where judgment is needed and plain code where it is not.
• 5Delivery and adoption. Live, in the tools the team already opens, with the rules encoded in the interface.

TEAM

“I work with the people doing the job, map the workflow, document the requirements, and build the tools and integrations that help them get it done.”

What it has looked like for me

For a manufacturer: an order-to-floor system, from dealer portal to cut sheets. For an agency: a content pipeline that publishes unattended, a performance scorecard across six service lines, and shared proposal tooling. At a medical-device company: clinical software and an internal tool that makes 400+ engineering postmortems searchable.

Different industries, same sequence. The hard part is rarely the model or the framework. It is getting the requirements right with the people who will live with the result.

What I am still getting better at

To be honest, most of my career has been frontend. The last few years pushed me into backend work, workflow orchestration and LLM integration because I wanted to ship complete systems. Agent evaluation and guardrails are areas I am deliberately deepening. I would rather say that than pretend otherwise.