Huemor: a named diagnosis, a leaner stack, and AI at the center

The short version

Huemor is a digital agency. Good work, real clients, a portfolio most shops would want. They knew something in their development process was quietly eating their margin, and they could not point at it.

I spent ninety days finding out. The answer was not the tool they suspected, and the fix was not the one they expected.

How it started

They did not come to me with a website problem. They came with a feeling.

Projects were taking longer than they were quoting. Small client requests were burning hours nobody had budgeted. Everybody inside the company had a theory, and the theories did not agree with each other. One theory was the page builder. Another was the module library. Another was estimating.

When five people have five explanations for the same symptom, nobody has actually measured it. That is the real problem, and it is more common than you would think.

The first month was almost entirely listening

I did not open with a recommendation. I opened with access.

I got into their build environment, read through the shared module codebase they had built over years, and pulled retrospectives on a batch of recent projects. Then I talked to the whole technical chain, one at a time. The owner. The developer who owned the internal module system. The lead on the build team. The systems and security guy. Individually, so nobody was performing for anyone else.

That last detail matters more than it sounds. A group call gets you the official version of how a company works. One on one calls get you the real one. The gap between those two is usually where the money is going.

What was actually broken

Their discovery, creative, and design work was genuinely strong. Strong enough to justify what they charged for it. That was never the issue and I told them so early, because a diagnosis that flatters everyone equally is not a diagnosis.

The bleed was all in development, and it had specific causes:

Estimates and reality had drifted apart, and everyone had quietly accepted it. Builds were landing meaningfully over the hours they were scoped at. Not once. As a pattern. Nobody was tracking the gap closely enough for it to become a problem anybody owned.

The shared tooling was not getting used. They had invested in a module library so builds would be consistent and fast. In practice it was often faster to write custom code than to reach for it, so the thing meant to save time had become one more thing to maintain.

Nobody owned the standard. Not an insult to anyone. Just a seat that had never really been defined. Without an owner there was no standard, so every project reinvented decisions that should have been settled once.

Tool sprawl with no single source of truth. Enough separate subscriptions, dashboards, and logins that no one person could tell you the whole picture of what they were running or paying for.

The quick win, because a diagnosis should pay for itself

While the bigger analysis was still running, one thing was obviously fixable.

They were paying for premium licenses site by site across their portfolio, with a batch about to auto renew. I vetted the alternative with their systems lead and recommended consolidating onto a single cross host dashboard covering everything at once. They made the move. It cut real recurring spend, improved coverage at the same time, and replaced a manual site by site update grind across the whole portfolio.

That is not the interesting part of this engagement. But it is the part that paid for a chunk of it inside the first month, and it bought the credibility to have the harder conversation.

The part that actually mattered

The real shift was not a tool. It was showing them what building looks like now.

I have a direct relationship with the founders of one of the platforms they build on, and I used it to get them early access to AI tooling that was not generally available yet. Then I sat down with their dev lead and instead of describing what AI could do for their build process, I showed him, live, against their own stack and their own designs.

Most teams use AI the way most people do, for writing emails and the occasional code snippet. Almost nobody is thinking about it as the thing that builds the website. That is the distinction that changes a company.

Within two weeks their team had piloted an AI assisted build on a live client project and cut the time significantly. Within two months their own internal strategy had reorganized development around AI, with leadership signed on to a dated rollout.

Getting the quiet skeptic in the room

Most companies have someone senior who has been quietly unconvinced the whole time.

I asked for a call, and rather than sell to them I spent the first stretch of it figuring out what they were actually worried about. It turned out the objection had nothing to do with AI or modernization at all. It was about a specific promise the company makes to its clients, and whether the new direction would break it.

Once that was named, it was answerable in about ten minutes. A long stall, and it came down to one question nobody had asked.

Most stalled decisions are like this. The stated objection is rarely the real one, and nobody finds the real one because nobody asks directly enough to be uncomfortable.

Where it landed

They ended the engagement with a written diagnosis they had never had, a documented architecture direction, a handoff standard between design and development, a tooling stack that costs less and covers more, and a development process built around AI instead of around a page builder.

The thing I am proudest of is less concrete than any of that. I broadened their perspective on what was possible, and I helped them think about a genuinely more modern approach to how they build.

What I would do differently

I will be honest about the part I got wrong, because it is the most useful thing in this write up for anyone considering this kind of work.

I did the diagnosis, and then I taught them how to execute it, and I did both inside the same advisory engagement before scoping and pricing what came next. By the time I proposed the larger implementation, I had already transferred enough understanding for them to have a credible internal path to some of it.

That is not a complaint. It is a sequencing error and it was mine. The diagnosis is the product, not the free sample that earns you the real project. I price it that way now, and I get the next phase scoped and agreed while the thinking is still being delivered, not after.

The other lesson is sharper and I have already changed how I work because of it. When you are asking a company to change how it operates, a demo they can sit next to beats a better plan they have to imagine. Build the proof inside their environment, on their real work, with their people watching. Not a case study of somebody else. Not a document. The thing, running, in front of them.

I write these up honestly or I would not bother writing them at all.