I don't hand you a strategy deck. I build the thing.
Most AI consulting ends at the recommendation. Mine starts there — I work inside your business, on your systems, until something is running that your team actually uses.
Embedded, not advisory
The usual engagement produces a document. Someone reads it, agrees with it, files it, and nothing changes — because the hard part was never the analysis. The hard part is the messy middle: the data that isn't as clean as anyone said, the exception your best staff member handles from memory, the workflow that only makes sense once you've watched it three times.
So I work the way a forward deployed engineer does. I sit close to the people doing the work, build against your real data rather than a sanitised sample, and put something usable in front of your team early enough that their reaction can still change the design.
A report recommending what you should build.
A working system your team is already using, and the knowledge to run it.
How I hold the work
Four rules that decide what I do when a project gets difficult.
Build against reality
No pilots on tidy demo data. I work with your actual files, your actual exceptions, your actual volume — because that is where projects fail, and finding the failure in week two is cheap.
Working beats complete
Something narrow and running is worth more than something comprehensive and theoretical. I'd rather solve one workflow properly and let you decide whether to widen it.
Your environment, your data
Wherever the work allows it, systems run inside your infrastructure and your data stays there. Privacy isn't a feature bolted on at the end — it's usually the reason a business can adopt AI at all.
Handover is part of the build
A system only you can operate is a liability I've sold you. Your team learns it as it's built, and documentation is written while the reasoning is still fresh.
What an engagement actually looks like
Not a Gantt chart. A rhythm: every phase puts something concrete in your hands, and you can stop after any of them.
- First
Sit with the work
I spend time with the people doing the job — watching the actual process, not the documented one. Where does time disappear? What gets re-keyed? What does everyone route through one person? This is also where I look at the real state of your data, which is almost never what the org chart suggests.
You end up with: A short, honest read on where AI would help and where it wouldn't - Then
Build the narrow version
One workflow, end to end, on real data. Small enough to exist quickly, real enough to be judged. You see it working — or not working — while it is still cheap to change direction.
You end up with: A working prototype against your own data - Then
Put it in front of the team
The first contact with actual users always reveals something the plan missed — a habit, an exception, a step nobody mentioned. I'd rather find it now. This is the phase where the design gets its final shape.
You end up with: A system reshaped by the people who will use it - Then
Harden and hand over
The unglamorous part: failure modes, access controls, the edge cases, monitoring, and writing down how it works. Your team runs it with me present, then runs it without me.
You end up with: A production system your team owns and can operate
Where the work runs
A recurring question from businesses holding sensitive information, and a fair one.
- Systems run inside your infrastructure wherever the work allows it — your server, your cloud account, your control.
- Confidential material is separated from shareable knowledge by design, so access rules are enforced by the system rather than by policy documents.
- Access control is decided before anything is built, not retrofitted once someone notices a problem.
- You own the code, the data and the documentation. There is no dependency on me and no platform to be locked into.
What I need from you
Short list, but the engagement depends on it.
Access to the people doing the work
A few hours with the staff who actually run the process. Not a summary from management — the real thing, including the workarounds.
Real data, early
Working against sanitised samples hides exactly the problems worth finding. The messier the truth, the more useful it is to see it in week one.
One decision-maker
Someone who can settle a scope question in a day rather than a fortnight. Momentum is most of what makes these projects work.
Honesty about what failed before
Most businesses have already tried something. What went wrong last time is the most useful information you can give me.
When it ends
An engagement should end. You get the code, the documentation and a team that understands the system well enough to change it — not a retainer you can't get out of.
Plenty of clients keep me on afterwards for the next piece of work, but that should be a decision you make because the first thing worked, not because you can't operate without me.
Why I work this way
This model has a name in the AI industry — forward deployed engineering — and it exists because frontier models made intelligence cheap while deployment stayed hard. The advantage is no longer in access to the technology; it's in getting it working inside a specific, messy business.
Read the full piece on forward deployed engineeringHave something you want built?
Tell me what's slow, what's manual, or what you've already tried. If I can help, I'll say how. If I can't, I'll say that too.
Talk to Hung