STRATEGY, AI & IT CONSULTING — GLOBAL, REMOTE-FIRST

Strategy that ships, on systems built to run it.

Hamingcs pairs strategy and hands-on leadership with AI/data expertise and the systems, security, and DevOps architecture needed to put ambition into production — and keep it there.

Start a conversation See what I do

01 — AI & DATA

Strategy, leadership, and data vision

Building and running AI and data functions inside large organizations — from first strategy to global teams.

02 — SYSTEMS & SECURITY

Architecture that holds under load

Enterprise systems, cloud/SaaS transformation, and security architecture engineered for scale.

03 — STRATEGY & LEADERSHIP

P&L and teams, not just recommendations

Hands-on ownership of budget, global teams, and market strategy — comfortable with a P&L of any size, proven at director and CTO level with a 300-person team spanning the US, EU, Japan, China, and the Middle East.

20 years of experience
From software developer to team leader, architect, manager, director and CTO
Automotive, energy, tech
Industries I have delivered in, across four continents
Strategy to production
From AI vision and data governance through to secure, running systems

WHY THREE DISCIPLINES

Most AI initiatives don't fail on the model. They fail on the system underneath it — or the strategy and leadership that never turned the plan into a running function.

I've spent my career across all three: setting AI and data strategy at the leadership level, owning the P&L and team that deliver it, and — from the same technical grounding — architecting, reviewing, and securing the systems that have to carry it.

Hamingcs exists because those conversations are usually happening in different rooms, and shouldn't be.

MY BACKGROUND

Two decades of enterprise experience, earned on the way up — not assembled from a slide.

Since 2006

  1. 01

    Developer

    Automotive diagnostic software, in Java.

  2. 02

    Team leader and architect

    Data models, work split across teams, root-cause analysis in production.

  3. 03

    Solution design architect

    Enterprise systems, designed to carry load.

  4. 04

    Manager and director

    Budget, P&L and delivery.

  5. 05

    CTO

    Technology and strategy at leadership level.

  • Automotive
  • Energy
  • Tech

Customers and teams across the US, Europe, Africa, the Middle East, Japan and China.

It started hands-on: building automotive diagnostic software in Java, then leading the architecture behind it — defining data models, distributing work across teams, and tracing production defects back to root cause when something didn't hold.

That technical grounding is what later underwrote the leadership: managing P&L on a project, then scaling into director and CTO-level ownership of an AI and data function — 300 people across the US, EU, Japan, China, and the Middle East, business and market strategy included, plus leading the cloudification and digitalisation of the technology stack underneath it. Hamingcs combines strategy, delivery, and security under one practice, in the order they were actually learned.

FOUNDER INTERVIEW

In the Founder's own words

Answers by the Founder

Why Hamingcs

Why start Hamingcs?

I love solving problems and building solutions, which is why I was always out visiting customers: understanding their issue first-hand, then building the solution for them. Colleagues used to call me the fixer from the UN, because I was the one who got sent in whenever a customer had a big problem that needed sorting out. I've never been able to lie to someone sitting in front of me. If my company had a product to sell that didn't actually fit their problem, I'd tell them it didn't fit. That earned me something more valuable than a sale: I had my own desk at nearly every customer site I worked with, a chair next to it, and I'd run what I called a "Tell me everything, I'm listening right now" session: just sitting, listening, learning what was actually going wrong for them. I ended up feeling like part of their team, not their vendor. Hamingcs exists because I wanted to keep doing that: building what a business actually needs, not selling them something so big they'll only ever use 10% of it.

What's different about how you approach this compared to a typical consulting engagement or AI vendor?

I start with a discovery session where I listen before I propose anything. I don't use subcontractors, so the person you meet at that session is the person who does the work. In my years leading a department at a large company, I saw how many consulting firms put a senior person in front of the customer for the first few days and then swap in juniors, so the customer ends up paying for their training. I won't run it that way. The people who start your project stay until the end, so they know the whole story and can answer your questions with real answers about what's happening on the project and in the market. On the QA side, when a pilot needs more capacity, I add another AI agent to the team rather than bringing in junior people, up to a limit that is configurable. I run Hamingcs the same way: when I need something new, whether that's maintenance, support, marketing or product management, I look first at whether an agent can do it. I also won't sell the dream up front. In my experience, many agile projects without clear KPIs end up delivering something other than the agreed scope, because every trade made to get past a blocker quietly shrinks what you get. I'd rather agree what is delivered, say what would change it, and tell you when a trade is happening.

AI projects

What's the real reason most enterprise AI projects stall?

The model is rarely the reason an AI project stalls. It's almost always the architecture around it, the part nobody puts on a slide. I've seen prototypes that worked perfectly at small scale hit a wall the moment real volume showed up, because a decision that felt reasonable early on (no message queue, no shared data layer, security treated as a later step) quietly became a blocking problem instead of a future one. None of that is an AI problem. It's architecture and governance wearing an AI costume. I tell two of these stories in full in Issue #1 of my Substack.

QA Agents Cloud

Why build something like QA Agents Cloud yourself, instead of only advising on it?

Every QA team I've worked with hits the same wall: always more testing to do than hours to do it in, and regression suites that grow every sprint. There's a second cost underneath that one: when a QA analyst who's spent a year building context on a codebase leaves, that context leaves with them, and whoever backfills starts close to zero. None of that work is why anyone got into QA, and it's exactly the kind of work a well-instructed AI system can take off someone's plate, if it's built to actually understand the pipeline, not just bolted onto the end of it as a chatbot. I'd rather build the thing that tests that idea than only advise on it.

What's the one thing you refuse to hide from the people who own the result?

By default, nothing medium or higher gets filed until a person approves it, and neither does anything the system isn't highly confident about. Only low-severity findings it is highly confident about go through on their own. That line is a setting, and you can make it stricter, so every finding waits for a person. What I won't do is hide that choice from the people who own the result.

If this is how you want to work, let's talk.

Start a conversation

HOW I APPROACH STRATEGY

Define the issue before you solve it.

  1. 01

    Define the issue

    Before any solutioning, I frame the actual business problem — not the symptom the organization first brings me.

  2. 02

    Wargame the options

    Two or three real strategic paths, stress-tested against likely market, competitor, and internal responses before a euro or a headcount is committed.

  3. 03

    Decide, resource, and lead

    Once a direction is set, I take operational ownership of it — budget, team, and delivery — not just the recommendation.

  4. 04

    Execute and adapt

    Roadmaps get revisited against real market signal, the way a strategy built while penetrating new markets has to — not filed away after the kickoff.

HOW I WORK

A few working principles

01

Strategy is only useful if someone can operate it

I don't hand over a slide deck and leave. Recommendations come with an honest view of what it takes to run them.

02

Security and scale are designed in, not added later

Threat modeling and release architecture are typically part of the first design conversation, not a review at the end.

03

I work where you are

Global and remote-first, with direct experience across European, Asian, and Middle Eastern operating environments.

SERVICES

Three disciplines. One engagement.

I work across the full path from strategy to running system — engage me for any one discipline, or all three.

AI & DATA

Strategy, leadership & data vision

AI readiness & strategy

AI strategy consulting that starts with an honest assessment of where AI creates real value in your operations — and where it doesn't — followed by a roadmap your teams can actually execute.

Interim AI & data leadership

Hands-on leadership for building or scaling an AI or data function, including fractional CTO engagements: hiring, structure, budget and P&L ownership, and operating cadence.

Data architecture & governance

Designing the data vision, models, and governance an organization needs before AI initiatives can be built on top of it reliably.

Technical evaluation & AI-output review

Independent, hands-on review of code, technical designs, and AI-generated outputs — catching flawed assumptions and correctness gaps before they ship, not after.

Generative AI & LLM integration

Copilots, retrieval-augmented assistants, and workflow automation built on large language models — scoped to problems worth solving, not novelty demos.

AI governance & responsible AI

Putting risk, oversight, and compliance frameworks in place as AI regulation (like the EU AI Act) catches up with deployment.

SYSTEMS & SECURITY

Architecture built to run in production

Cloud & SaaS transformation

Moving on-premise products to secure, multi-region SaaS deployments — including the operational model to support and monitor them once live.

DevOps & CI/CD engineering

Building release pipelines that support frequent, reliable delivery across multiple product versions, at enterprise scale.

Security & threat architecture

Threat modeling, code scanning, and penetration testing that can be built into the release cycle rather than bolted on afterward.

QA automation & release strategy

Test classification and automation strategy that scales with a growing codebase instead of slowing it down.

Security & compliance audits

Readiness assessments against frameworks like SOC 2 and ISO 27001, with a practical remediation plan rather than a checklist to file away.

Cloud cost optimization

Reviewing cloud architecture and spend as usage grows, so infrastructure scales without the bill quietly outpacing it.

STRATEGY & LEADERSHIP

Business strategy, P&L, and team leadership

Business & AI strategy definition

Turning market and technology signals into a strategy the business can actually execute — including where I take direct ownership of it.

P&L & budget ownership

Full financial ownership of a function or programme, at any scale — budgeting, forecasting, and cost control, from lean project budgets to a large, multi-region P&L, not just a recommendation on a slide.

Global team leadership & scaling

Building and leading distributed teams across regions: hiring, structure, and operating cadence, drawn from scaling a function to 300 people across the US, EU, Japan, China, and the Middle East.

Market entry & expansion strategy

Defining go-to-market and driving penetration into new markets and customer segments, including direct experience opening accounts across China, Japan, and the EU.

Innovation consulting

Acting as innovation advisor to enterprise clients and internal stakeholders — from first idea to a funded, resourced initiative.

Academic & R&D partnerships

Structuring university and research collaborations, including PhD placements, that feed real capability into a commercial team.

HOW THE WORK IS DONE

One accountable person. A team of AI agents behind them.

Hamingcs has no subcontractors. I'm the person you meet, and I'm accountable for what you receive.

Where a task is repeatable, I give it to an AI agent (AI coding agents do the engineering work, under my review), and I review the result before it reaches you.

Each role can run as several agents at once, when the work needs it.

The longer explanation, with what is automated and what stays human: I built a QA team out of AI agents, and gave it a rule it can't skip.

HOW I ENGAGE

Four ways in, one point of contact.

Advisory
Ongoing

Retained strategy input for AI, data, and security decisions as they come up.

Start a conversation
  • Recurring strategy & architecture review
  • Direct access for ad-hoc decisions
  • Roadmap and governance input
Interim leadership
Embedded

A hands-on strategy, AI, data, or systems lead inside your organization — including full P&L and team ownership while you build the function.

Start a conversation
  • Everything in Advisory
  • Hiring, structure, and budget ownership
  • Operating cadence and delivery accountability
  • Handover plan built in from day one
Project delivery
Scoped

A defined engagement against a specific outcome — an architecture, an audit, a migration.

Start a conversation
  • Fixed scope and timeline
  • Delivered by me, with AI agents supporting where it fits.
  • Clear handoff and documentation
QA Agents Cloud pilot
Pilot

AI agents test your web app from your specifications, and a person decides which bugs get filed.

See the pilot

QA AGENTS CLOUD

AI agents test your software. You decide what gets filed.

QA Agents Cloud is the AI-assisted QA testing product I built and run myself. Give it the address of your web application. A small team of AI agents plans the tests, writes them and runs them, then writes up each bug it finds: the steps to reproduce, what it expected and what actually happened. A person decides which bugs get filed to GitHub Issues or Jira Cloud, or exported as a CSV file, and you choose how strict that is.

Everything below comes from a run on a sample application, not from a customer.

See it live

A run on a sample application, in under two minutes.

Video poster: the agent map of a run on a sample application, one coordinator agent connected to two tester agents.

Want to see it live with your own questions? Email me and I'll set up a short walkthrough.

Ask for a walkthrough

A small QA team, working in the open.

A coordinator agent plans the run and hands the work to specialists. A planner prepares the test plan from your specification, a generator writes the tests, and an executor runs them. A triage agent sorts real bugs from environment problems and says how sure it is, and a reporter writes up each bug with a title, description and labels. When something doesn't add up, such as a test case that can't pass, the coordinator sends it back to the right agent to fix before the run continues. The Standup room keeps the whole conversation, so you can read how each result was reached before you approve anything.

The QA Agents Cloud Overview: what happened across your targets and what needs your approval, with live agent count.
The Overview: what happened, and what needs you.

What to test, and where the bugs go

How a target is set up, and where approved bugs can go: GitHub Issues, Jira or a CSV download. Shown on a sample application.

Video poster: the Settings page of a sample target in QA Agents Cloud, with the Where bugs go card showing three choices, GitHub, Jira and Spreadsheet, with Spreadsheet selected, and the line: each approved bug is filed once, there.

Standup room

A recorded, read-only transcript of a finished run.

The Standup room transcript: the coordinator asks the test planner to fix test case AR-INVOICE-014, the planner replies with the fix, and the coordinator passes it to the test generator, which reports back.
The Standup room: the coordinator sends a test case back to the planner, and the fix goes on to the test generator. From a finished run on a sample application.
The Standup room transcript: the triage agent's summary sorting failures into real bugs and environment issues with confidence levels, followed by the bug reporter's summary of its filing decisions.
Triage sorts the failures into real bugs and environment issues, with a confidence level, and the reporter sends back its filing decisions. From a finished run on a sample application.
A run in progress in QA Agents Cloud: a progress bar at step 5 of 11 and the agents working, one coordinator and two test executors.
A run in progress: how many agents are working and how far along it is. From a run on a sample application.
The Approvals page: a group of two bugs held for a person, each with severity, confidence and Review, Reject and Approve buttons.

Approvals

A person decides what gets filed, as strictly as you choose.

Under the Strict rule, every bug waits for your approval before it is filed. Under the default Standard rule, only low-severity, high-confidence bugs are filed automatically.
The Run rules page: choose Standard or Strict for who approves bugs, and how many tester agents run at once, up to 1, 2 or 3.

Run rules

Who approves bugs, and how many tester agents run at once (up to 3 by default). Windows desktop apps are always Strict and run one tester agent at a time.

Run details

A finished run on a sample application: 23 tests run, 5 findings, and three real bugs waiting for approval.

Run results

A finished run on a sample application: tests, findings, and what needs approval. My own run, not a customer result.
Concurrency chart for one run: how many agents ran at the same time over about 40 minutes, with a peak of 3.

Concurrency

How many agents ran at the same time in one run. The tester limit is a setting I choose, not a guarantee. From a run on a sample application.
Estimated cost by agent for one run: the first four of eight agents, each with its duration, tokens and estimated cost.

Cost

See an estimate of what each agent costs.

Estimated cost by agent for the same run: the first four of eight agents. Costs are estimates; your own Anthropic account is billed directly.

Start with a pilot

The first step is a paid, fixed-scope pilot on your web application. Scope and fee are agreed in writing before it starts, and I make no promises about results. Windows desktop testing is proven on a sample application, not yet with a customer.

Request a pilot

Why it's different

  • You stay in control Any bug can wait for your approval before it is filed. You choose Standard or Strict, for the whole instance or for one target. On Windows desktop apps every bug always waits.
  • You can read the work Each run keeps its agents' written notes in the Standup room, including when a test case was sent back and why.
  • You see the cost Every run shows an estimated cost for each agent, and your own Anthropic account is billed directly.
  • It fits how you work Download the findings as a CSV or as a file for Jira import. File approved bugs to GitHub Issues or Jira Cloud (I confirm the Jira connection with you first). Get an email summary after each run, or a post to a Slack webhook.
  • Honest about what's proven I have run it on sample applications, including right-to-left Arabic and Japanese pages. Windows desktop is proven on a sample application only, not yet with a customer.
  • Your time goes where it counts The agents take the routine testing. The judgement calls stay with you, such as whether a finding is worth filing.
  • Scale the team up or down Choose how many tester agents run at once: up to 1, 2 or 3 (the default is up to 3). The coordinator is told to stay within that number; the other agents are not limited by it.
  • Need another role? Need a different role on the team, such as another kind of tester? I can build that as another agent. It is agreed in writing as part of the pilot scope.

FAQ

Answers to the questions that come up most.

How engagements start, how I work, and how confidentiality is handled.

What does Hamingcs actually do?
I pair strategy and hands-on leadership with AI/data expertise and the systems, security, and DevOps architecture needed to put it into production — any one discipline on its own, or all three as one engagement.
Who do you work with?
Mid-size to large organizations, primarily in automotive, energy, and technology, who need senior leadership on AI/data or enterprise systems without a full-time hire.
Do you work remotely?
Yes — Hamingcs is global and remote-first, with direct experience across European, Asian, and Middle Eastern operating environments. On-site work is available where an engagement calls for it.
How does an engagement start?
With a conversation about what you're building and where it's stuck. From there I scope whether it's advisory, interim leadership, or a defined project.
Can you cover strategy, AI, and systems architecture together?
Yes — that overlap is the reason Hamingcs exists. Engage me for any one discipline on its own, or all three under one point of contact.
Can you take P&L or leadership ownership, not just advise?
Yes — interim leadership engagements, including fractional CTO engagements, can include full P&L and team ownership at any scale, not just advisory input, drawn from direct experience running budgets from focused projects up to a large, multi-region P&L and a 300-person team across the US, EU, Japan, China, and the Middle East.
Do you work on retainer or fixed scope?
Both. Advisory is typically ongoing, interim leadership is embedded for a defined period, and project delivery is scoped and timelined up front.
Do you work under NDA?
Yes — an NDA is available on request, and confidentiality and data-handling terms can be agreed before an engagement begins.
Do you help with compliance frameworks?
Yes — including readiness assessments against SOC 2 and ISO 27001, and AI governance work as regulation such as the EU AI Act catches up with deployment.
Is security part of the AI work too?
It should be. Threat modeling and release architecture are typically part of the first design conversation, not a review bolted on at the end.

CONTACT

Tell me what you're building.

Whether it's a strategy question, an AI/data challenge, a systems and security review, or all three — get in touch directly.

EMAIL info@hamingcs.com
LOCATION Global
OPERATING MODE Global / remote-first
Email me

Substack: Hamingcs Insights