AI & Systems Consulting
Most consultants default to agents because it sounds impressive. I do the opposite.
The first question I ask is whether you actually need AI — or whether a reliable process solves the problem without introducing a system that breaks under edge cases. That triage is the work. Below: what I’ve built, how an engagement runs, and the three problems I get called for.
Selected work
In production · via Strategic Digital Solutions
Through Strategic Digital Solutions, I rebuilt the search layer for a public-facing state government platform serving millions of residents. It had been renting search from a monthly software vendor, a cost that climbed with traffic, on a system the client did not control. The replacement runs on self-hosted, open-source infrastructure: fifty million records searchable in under 150 milliseconds, with automated failover and a documented disaster-recovery plan so a service used around the clock stays online. When it shipped, the recurring bill was gone and the client owned the code.
$53K
per year in software cost removed
50M+
records, instantly searchable
<150 ms
query latency
Zero
downtime, with a full DR plan
In production · Hoch Health & Wellness
The system my own company runs on: client records, scheduling synced to Google Calendar, Stripe billing, session tracking, and multi-coach payroll in one application. Built it, run it, and still ship to it.
Open source · Florida State University
Python and R tooling for a university physiology lab that replaced manual, multi-file processing. Published on GitHub with documentation and example data.
2022–2024 · Active Life
Two years as R&D lead at an international coaching company. Co-developed the client software, wrote the company's first nutrition scope-of-practice curriculum, and built systems designed to keep working without me in the room.
01
A short intake covering your situation, your current process, and what you have already tried. The more specific you are, the more useful the response.
02
What the actual problem looks like, whether I am the right person for it, and what addressing it would take.
03
Scope in writing before anything starts. You own everything we build. Documentation included. Thirty days of availability after delivery.
No. The systems I build are documented in plain language and your team uses them without touching code. If you want to learn the technical side, that is available, but it is not required for the work to function.
For sensitive work, models can run locally on hardware you control, so the data never leaves your environment. Where a cloud model is the better fit, I use API access, which the major providers do not train on by default. Either way you get a plain list of what leaves your systems and what does not, before anything is built.
Businesses where at least one process involves repetitive information handling: documents, client communication, internal knowledge, reporting. Also research teams, healthcare-adjacent organizations, and media operations where data reliability and auditability matter. Industry is less important than workflow structure.
That is the point of building this way. Your business logic and context live in files, not in the AI layer. When a model updates or a better one becomes available, the swap is a configuration change. The underlying system stays intact.
It depends on the piece. A first bounded project is usually a few weeks. Full builds run in months. The search infrastructure above was a multi-month engagement and is still running under a support retainer. You get a scope and a timeline in writing before anything starts.
01 — Organization and behavior change
Most productivity and AI adoption efforts treat organization as a filing problem. It is not. Research in behavior change science is clear: lasting change requires satisfying fundamental psychological needs, competence, autonomy, and connection. Skip those and you get compliance without capability. People use the new system for two weeks, then revert.
The teaching philosophy I apply here is grounded in the same principles I use in clinical coaching: build genuine skill first, then independence follows naturally. The goal is not to hand someone a workflow. It is to build the mental model that lets them maintain and extend it themselves.
This is where every engagement starts, before any tool is selected or any system is built.
What this looks like
Honest assessment of the current state
Not what the system should look like in theory. What is actually happening, where things are breaking down, and why.
Structure matched to how people actually work
Folder hierarchies, context files, and knowledge bases built around existing habits, not idealized ones that collapse under pressure.
A mental model, not a manual
When people understand why the structure works, they extend it. When they only know how to follow it, they abandon it the first time something does not fit.
The common mistake
An organization buys an AI subscription. Someone demonstrates it in a meeting. People are told to use it. Three months later, usage has dropped off. The tools were capable. The problem was never defined.
A hammer used well can build a house. Used without a blueprint it just makes noise. The blueprint is the work.
02 — Problem definition before tool selection
Most people approach AI by asking "what can this tool do?" The more useful question is "what problem am I actually trying to solve, and what kind of thinking does that require?"
This distinction matters because the same tool can either accelerate your thinking or replace it with something that looks right but is not. The difference is whether the problem was defined before the tool was opened.
I work with individuals and teams to articulate what they are trying to accomplish at the level of thinking, not just output. From there, the right instrument becomes obvious. Sometimes it is a well-structured prompt. Sometimes it is a different tool entirely. Sometimes it is a folder.
03 — Systems implementation
In the coaching work I do with athletes, there is a distinction between preparation and expression. Preparation is the intentional training that builds the buffer: stronger tissue, broader capacity, more resilience. Expression is what you actually want to do with your life and work. The training exists to serve the expression, not the other way around.
The same principle applies to systems work. The system I build is not the goal. It is the preparation that raises the ceiling on what you can express. We move as fast as we can with the governor on, because the real constraint is not ambition but sustainability.
Implementation means the system is running, documented, and maintained without me. Your team owns it. When the next model drops, or the next tool changes, the foundation stays intact.
What changes after
Context re-explained every session. Files scattered. AI used reactively, for isolated tasks, producing output that requires significant review and revision.
Context lives in the structure. The right files travel with the right work. AI is used for the 10% that requires language and judgment. The other 90% runs on rules.
The ceiling rises. What was previously impossible, given time constraints, cognitive load, or team capacity, becomes routine. The work you actually want to do expands.
Describe it specifically. You will get an honest read on whether there is a fit, and if there is not, I will say so directly.
Start a conversation