How I Work
Hands-on. In the codebase. From day one. I start with the business problem: what is worth building, who will use it, and what it has to connect to. Then I design the architecture, write code with your team, and integrate models, data, interfaces, and your existing systems. Every product ships with clear validation and operational boundaries: how quality is measured, what is monitored, and what it costs to run. I work fluently across product, design, engineering, and operations because that is where AI products succeed or fail. The engagement is temporary by design and the handover is planned from day zero. Here is what it looks like.
The Engagement Model
Analyse (2 days)
The diagnostic. I read the codebase, talk to engineers, designers, product owners, and business leads, and map the workflows. I look at the business problem, the data, the systems the product has to connect to, and where AI will genuinely help and where it will not.
You get three deliverables: a prioritised view of what is worth building and what stands in the way, a recommendation on what to fix first and why, and an honest call on whether further work makes sense. Sometimes the answer is "do not build this yet," and I will tell you that up front.
Validate (2 to 4 weeks)
A focused sprint on the highest-priority decision from the diagnostic. That can be a proof of concept against real data and real constraints, a technical spike on an architectural bet, or a small slice of production code that proves the new shape of the system works. For AI components, that includes an evaluation against real cases, so quality is measured, not assumed.
The goal is evidence for a go, change, or kill decision, not a demo. If the concept does not hold up, that finding just saved you months of building the wrong thing.
Build (Weeks to months)
Hands-on. In the codebase. With your team. I join as a working engineer. Daily standups. PR reviews. Architecture sessions. Pair programming when it is useful. I make decisions, write code, and establish the patterns your team will build on after I am gone.
The work spans whatever the engagement actually needs: module boundaries and build system, frontend architecture and design system integration, data pipelines and integration points, model integration where it belongs, evaluation, monitoring, cost control, governance, and documentation. I write the code, not just the recommendations. By mid-engagement your team is reviewing my PRs with the same confidence they bring to any other part of the codebase.
My time goes to the work that moves the needle: code, architecture decisions, and direct collaboration with engineers, designers, and product. Less time in meetings, more time shipping the product people will use. I use coding agents where they speed the work up, and I stay responsible for quality: everything I ship is reviewed, tested, and understood.
Exit (Final 2 weeks)
I plan my exit from day zero. During the final phase I shift from doing to teaching. Documenting decisions, pairing with the person who will own the architecture after me, and making sure the patterns I have established are understood, not just implemented.
The test is simple: can the team continue at the same quality without me? If yes, the engagement was successful. If no, I have not done my job.
What You Get
- An honest diagnostic that identifies root causes, even when they are not what you expected to hear
- Architectural clarity: how AI fits into your existing systems, module boundaries, ownership model, and the working mode your team needs. Documented, not just noted.
- Operational boundaries for every AI component: evaluation, monitoring, cost control, and a named owner after launch
- Decisions informed by 15+ years of seeing what works and what fails at scale across automotive, telecommunications, manufacturing, smart energy, and AI-driven products
- A single technical voice that designers, engineers, product, and operations can all align around
- Patterns and processes that outlast the engagement
- A team that is stronger, more confident, and fully equipped to continue without me
- Knowledge transfer that sticks. I train the people I work with so they own the architecture, not just inherit it
- A clean exit with no dependency on me
What I Don't Do
- Slide decks and steering committees
- Staff augmentation or body-shopping
- Open-ended retainers with no exit plan
- Technology recommendations without implementation
- Engagements where I can't write code
Typical Working Cadence
| Cadence | What it looks like |
|---|---|
| Daily | Standup with the team. Code review. Hands-on work. |
| Weekly | Architecture session, decisions documented as ADRs. Progress check with the engagement sponsor. |
| Bi-weekly | Broader update with leadership if needed. Honest assessment of where we are vs. where we need to be. |
| End of engagement | Written handoff document. Knowledge transfer sessions. Clear ownership map. |
Collaboration Principles
I have opinions. I hold them loosely.
I'll tell you what I think the right call is and why. I'm open to being wrong. If you have a better argument, I want to hear it. What I won't do is hedge. "It depends" is only useful if I explain what it depends on.
I optimise for the team that stays, not the one I'm on.
Every decision is made with the question: "Will this make sense when I'm gone?" If a pattern requires my presence to work, it's the wrong pattern.
I'm direct about problems.
If something is broken, I'll say it's broken. If a decision was wrong, I'll say that too, including my own. Polite disagreement is fine. Silence when something's going wrong is not.
I treat new technology as infrastructure, not magic.
Any new technology, whether an AI model, a platform framework, or a build tool, gets treated like any other external dependency: it has failure modes, it needs monitoring, and it will surprise you at the worst moment. My job is to design systems where that surprise is survivable. That requires the same rigour you would apply to a database schema, not the same optimism you would apply to a shiny new tool.
Working Style
Pragmatic, not dogmatic
I care about what works in your context, not what's trendy. If a "boring" technology is the right fit, that's what I'll recommend.
Collaborative by default
I ask a lot of questions. I assume your team knows things I don't. The best solutions come from combining what I've seen before with what you know about your business.
Direct about problems
I'll tell you when something's off, but I'm not interested in being right. I'm interested in getting it right.
Common Questions
What does the first week look like?
The first week is a diagnostic. I read the code, talk to engineers, designers, product, and business leads, map the delivery pipeline, and identify the real bottlenecks. At the end of the week you get an honest assessment: what I found, what I recommend, and whether I am the right fit for the engagement.
How do you integrate with an existing team?
I join as a working member. Daily standups, PR reviews, architecture sessions, pair programming when it is useful. I make decisions with skin in the game, not from the sidelines. Most engagements integrate smoothly. The collaboration typically feels natural within the first week.
What happens after you leave?
The exit is planned from day zero. I document decisions, pair with the person who will own the architecture after me, and ensure the patterns I have established are understood, not just implemented. The test is simple: can the team continue at the same velocity without me?
What if we need you longer?
Extensions happen when the scope genuinely requires it. But I will be honest about whether extending is solving a real problem or creating a dependency. The goal is always a self-sustaining team, not a permanent consultant.
Are you an AI specialist?
I am an AI Product Engineer. AI is the focus of my work, but I do not sell models. I build products: deciding what is worth building, designing how it fits into your existing software, implementing it with your team, and making sure it can be evaluated, monitored, and run after launch. LLM integration is one capability inside that, not the whole offer.
Do you use AI coding agents?
Yes, every day. They speed up the work considerably. I remain responsible for quality: every change is reviewed, tested, and understood before it ships, and your team can maintain it without the agents or me.
Typical Engagements
Architecture Triage
Read the codebase, talk to product, design, engineering, and operations, map what is worth building and what stands in the way. Three deliverables you can act on, with or without me.
Validation Sprint
Focused work on the highest-priority architectural decision: a proof of concept, a technical spike, or a slice of production code that proves the new shape of the system holds up.
Embedded Delivery
Integrated with your team. Architecture decisions, code, design system integration, build system, data pipelines, model integration, evaluation and monitoring, governance. For the move from validated concept to production.
Handoff and Exit
Documentation, knowledge transfer, ownership mapping. Planned from the first conversation. The goal is a self-sustaining team.
Most engagements begin with the Architecture Triage. No software team of your own, or want to start with where AI fits? See the workshops. Scope and commercial terms agreed per engagement.
Interested?
The first step is a conversation. Usually 30 minutes, no prep required on your side. Tell me what's going on and I'll tell you whether I can help.