↓ Skip to main content

How we work

Deploy, not advise. I’m here to put working systems in place, not to rent you my vocabulary. Every engagement follows the same shape — observe → design → build → transfer — and starts by understanding your workflow before choosing any model or tool.

1. Observe first
#

We start with the workflow, the baseline, the risk, and the value case — before choosing a model or tool. That means looking at how the work happens today, where time leaks or rework shows up, how ready the data is, and what constraints matter (approvals, data residency, hosting).

The entry point is deliberately low-commitment: the value check gives you a rough estimate, and the first discovery call is 30 minutes, no charge, and no pitch deck — we work out whether there’s a useful workflow to build and what “observe first” looks like for your context. What to automate first explains how to choose the workflow.

2. Design
#

Once the workflow is clear, I propose the smallest useful system that creates value: a workflow value map, a feasibility and risk review, and a practical path — with human review, permission boundaries, and governance designed in from the start, not bolted on later. If the honest answer is “no fit yet”, a smaller diagnostic, or deterministic automation, I’ll say so.

Why open-weight models are part of this
#

Where data genuinely cannot leave your environment, the model has to run inside it. That is a service in its own right rather than a footnote to this one: private AI deployment covers why open weights, where they run, what I would need from your side, and what handover looks like.

3. Build
#

I build with tools your team can already support — Microsoft 365, Python, APIs, KNIME, MarkLogic, local models, or your existing systems — so nothing depends on a stack only I understand. Where it makes sense, we prove one workflow first: a working pilot with real users and human approval points, and before/after measurement, before anything scales.

4. Transfer
#

You own what I build. Documentation and handover are part of the scope, not an extra invoice. Governance, permission boundaries, and a clean handover matter as much as the automation itself — so the system stays yours to run, with no lock-in. A running cost to know about: DocMark, where your pipeline renders branded documents, is a subscription billed through your engagement. If it can’t be handed over cleanly, it isn’t finished.

What I’ll ask of you
#

You don’t need to become AI experts, and you won’t be handed a system to run alone. What an engagement genuinely needs from your side is straightforward:

  • Someone who knows the workflow. Observe first is mostly about understanding how the work happens today — so early on, the main ask is access to the people and examples that show the real process, its inputs, and where it hurts.
  • Domain knowledge, not technical work. You bring the judgment about what “good” looks like and which constraints matter; I handle the building.
  • A reviewer who stays in the loop. Human review and approval points are built into every phase — we agree who on your side reviews and signs off, so the system reflects your judgment, not just mine.
  • The constraints, up front. Data residency, tool approvals, and risk are far easier to design around when they’re named early rather than discovered late.

The time commitment is agreed up front and scoped to fit your team’s capacity. In a pilot it is typically 2–4 hours a week from one person. Heavier involvement early — showing us the real workflow — tends to produce a better result, but the pace is set with you, for your context, not imposed.

What a pilot looks like
#

These are typical figures, not a quote. The fee and data terms are my defaults. Your own figures go in the scope we agree before we start, and that is what counts.

  • How long. Typically 4–8 weeks from kick-off to the before/after measurement.
  • Your time. About 2–4 hours a week from one person who knows the workflow. I mainly need other people during observe first.
  • How fees work. Staged. Observe and design are paid as each finishes; build is paid on delivery. You can stop at the end of any stage.
  • If the pilot misses the measure we agreed. You keep everything built and documented to that point, and I invoice nothing further for the work. If the workflow uses a subscription I billed through the engagement — DocMark, where documents are rendered — tell me to stop it and I will; keeping it running is your call. I’ll tell you plainly why it missed.
  • Where your documents live while we work. In your own environment by default. I work inside your Microsoft 365, cloud or on-premises environment, under an account you control. Nothing is copied to my systems by default. If a pilot needs a hosted model or a service I run — including the DocMark step that renders branded documents — we agree that with you first, before any document goes to it. DocMark can run inside your environment or as a service I run; which applies is part of that agreement. When the engagement closes, you revoke that access; I will ask you to.

Measure, don’t assume
#

If we can’t point to time saved or risk reduced, we haven’t finished. Value is the test at every phase — which is also why optional success-fee or value-share terms only apply where value can be verified, never from website inputs.

How this maps to the packages
#

The packages are entry points into the same model: an AI Quick Diagnostic is a light observe; an AI Value Finder is observe + design; an Agentic Value Pilot is build and prove one workflow; and a Managed AI Value Partner monitors, improves, and governs it over time. Typically, an AI Quick Diagnostic runs 2–3 weeks and needs about 3–4 hours of your team’s time in total; an AI Value Finder runs 3–5 weeks at about 2 hours a week from one person; an Agentic Value Pilot runs 4–8 weeks at about 2–4 hours a week, as in What a pilot looks like above. You start with the phase that fits.

The figures on this page are typical, not a quote, and every package is scoped per engagement. The scope we agree sets your own.


Start with the value check, or request a discovery call to talk through what “observe first” would look like for your workflow.