What Six Months of AI Consulting Taught Us

The Experiment

When we started Mayura, we ran AI consulting engagements alongside product development. The logic was straightforward: get close to real problems, validate assumptions, fund the early stages. The work put us inside mid-market companies trying to make AI operational.

Six months later, we had learned more than we expected.

Two Client Archetypes

The engagements fell into two patterns. We started calling them "The Delegators" and "The Builders."

The Delegators had no internal technical staff for AI. They wanted us to handle everything: data pipelines, model selection, deployment, monitoring, and ongoing maintenance. They were willing to pay for outcomes and didn't want to think about the technology underneath.

The Delegator pattern is support-heavy by construction. Every question, every data format change, every integration issue lands on the delivery team. Delivered well, that is a services business, and we set out to build the software underneath it.

The Builders had technical teams, often small but capable. They wanted to understand the architecture, learn the patterns, and eventually own the system. These were our favorite clients to work with.

A competent technical team absorbs the methodology and builds internal muscle, which is what a Builder engagement is for.

Both archetypes taught the same lesson from different angles: what a client wanted to keep at the end was the system itself.

The Deeper Insight

Underneath both patterns was a more interesting signal. The same concern kept coming back, in slightly different words:

"We want AI, but we don't want another vendor we depend on."

The Delegators said it as anxiety about lock-in. The Builders said it as frustration with cloud API costs and data exposure. Our reading of both is the same underlying need: ownership.

In the engagements we ran, companies did not want to rent intelligence. They wanted to own the infrastructure, control the data, and predict the costs. The SaaS model that works for collaboration tools and CRMs starts to break down when the processing runs continuously. What they wanted read was concrete: the news feeds they follow, the email inboxes that matter, the web pages they track, and the PDFs those link to.

Think about the math. A mid-market company processing documents continuously through cloud AI APIs pays a metered API fee, and in Mayura's modeling that fee sits alongside data exposure overhead, vendor dependency, and budget unpredictability. The cloud AI tax breaks down where that money goes and sets out the assumptions behind the model. That same workload on owned infrastructure is a one-time hardware purchase plus a flat license, and where the crossover lands depends on volume.

What Mayura Changed

These six months reshaped our roadmap. We stopped asking "how do we scale consulting?" and started asking "how do we give companies the infrastructure to do this themselves?"

The answer wasn't another SaaS platform. We had already built one, and it worked: it processed sources around the clock, held onto what it learned, and surfaced what mattered. The mismatch was in the deployment model. A cloud platform requires sending data somewhere else and paying variable costs that grow with usage, which is the arrangement these companies were trying to get out of.

So we started pulling the architecture apart and reassembling it for a different deployment model. We rebuilt around an edge-first architecture: the intelligence runs on hardware the customer owns, it reads the outside world while their files stay on their machines, and running it harder does not cost more, bounded by the throughput of the machine it owns.

Consulting now serves a specific purpose: helping companies deploy and configure infrastructure they'll own. We stopped building systems that leave the customer depending on us to maintain them.

The Decision

The hardest part of this learning wasn't strategic. It was personal. Real relationships had been built, and the work was good work. Building the product these companies were describing meant reordering the whole business around it. That is the kind of decision you only make when the signal is unmistakable.

But the signal was clear. Both archetypes pointed at the same thing: companies wanted to own what they run on. Services stayed as the way we work alongside a team, and the product became what that work builds toward.

Six months of consulting gave us conviction about what to build next.