Huemor: the bottleneck was never where they thought it was

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. Builds were coming back bug heavy. 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. The owner thought it might be the page builder. One developer thought it was the module library. Somebody else thought it 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 were fiction, and everyone had quietly accepted it. Builds scoped at around 285 hours were landing closer to 440. Not once. As a pattern. Nobody was tracking the gap closely enough for it to become a problem anybody owned.

The developers were routing around their own tooling. The company had invested in a shared module library so builds would be consistent and fast. In practice, developers found it faster to write custom code than to use it. So every site drifted, and the library that was supposed to save time became a thing to maintain on top of the work.

There was no technical leadership. Not an insult to anyone. Just an unfilled seat. Nobody owned the standard, so 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 security 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 roughly four thousand dollars a year, added vulnerability coverage they did not have before, and replaced a manual site by site update grind across around sixty properties.

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 Huemor early access to an unreleased AI integration that was not publicly available. 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.

They had people who used AI the way most people do, for writing emails and the occasional code snippet. Nobody was thinking about it as the thing that builds the website. That is the distinction that changed the 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 the owner’s own strategy document had reorganized the entire development operation around AI, and both partners had signed on to a dated rollout.

Getting the skeptic in the room

Every agency has a partner who has been quietly unconvinced the whole time.

Theirs had been silent for two months. I asked for a three way call, and rather than sell to him I spent the first stretch of it figuring out what he was actually worried about. It turned out his objection had nothing to do with AI or modernization. He was worried about a specific promise they make to clients, and whether the new direction would break it.

Once that was named, it was answerable in about ten minutes, and he went from the obstacle to an advocate in the same call. Two months of stall, and it was one unasked question.

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.

Their own words, from our last call: I broadened their perspective on what was possible, and helped them think about a more modern approach to development.

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.