Self-service analytics has been promised for about as long as I have been working. It never quite arrived — the tools were always more self-service in the brochure than in the hands of someone who just wanted a number.
Natural-language querying is the closest it has come to being real. Which means, for the first time, organisations are about to find out what happens when everybody can actually ask.
Success is the cost event
This is the part that catches teams out, and it is worth stating plainly because it is counter-intuitive: the cost problem arrives when the platform works.
Before, four analysts ran a set of scheduled reports. Predictable load, predictable bill, and the analysts had internalised which queries were expensive and avoided them without anyone having to say so.
After, four hundred people can ask anything in plain language. They do not know which questions are expensive. They cannot know — that was the entire point of removing the technical barrier. So somebody asks a vague question that scans everything you own, and it costs what it costs, and then they ask a slightly different version because the first answer was not quite it.
None of that is misuse. That is people using the thing correctly. But the load profile has fundamentally changed, and an architecture designed for the first picture will produce an alarming invoice under the second.
I have heard the failure described as a customer paying something approaching the GDP of a small country. That is hyperbole, and the underlying pattern is not: costs on a query-billed platform scale with usage, usage scales with accessibility, and the whole project was about accessibility.
The four things that decide it
Repeated identical queries. In any organisation, a large fraction of questions are the same questions. The same regional summary, recomputed from raw data, forty times on the morning of the monthly meeting. Cache aggressively — this is the single cheapest win available.
Everything hitting raw tables. People ask a predictable distribution of questions. Build materialised aggregates for the common ones so the raw layer is reached only when something genuinely novel is asked.
Unbounded natural-language queries. A vague question translated into SQL by a model can produce a scan across everything. Put a ceiling on it — query timeouts, scanned-data limits, a cap that fails with a helpful message rather than a bill. "That question is too broad, try narrowing to a date range" is a good user experience and a necessary control.
No cost attribution. Nobody moderates a bill they cannot see is theirs. Attributing cost by team or department changes behaviour more reliably than any technical control, because it turns an invisible shared resource into someone's budget line.
Build it in, do not bolt it on
All four of those are dramatically cheaper at design time.
Retrofitting cost controls onto a platform people already use means changing something they have started to depend on. Introducing a query limit after six months means telling users that a thing which used to work now does not — and you will lose the argument, because they will correctly point out that you built it that way.
Introducing the same limit on day one is simply how the platform behaves. Nobody objects to a boundary that was always there.
The failure this actually causes
The cost problem does not usually manifest as a platform being switched off. It manifests as something quieter and worse.
The bill arrives. Somebody senior asks what is going on. The response is to restrict access — fewer users, fewer queries, approval required. Within a quarter the platform is back to being four analysts running scheduled reports, except now it is an expensive platform doing what a cheap one used to do, and everybody has learned that the data team's projects cost a lot and change little.
That is how a technically successful project becomes a political failure. The lesson the organisation takes is not "we should have architected for cost" — it is "self-service does not work here."
Getting the balance right
There is a commercial dimension worth being honest about, because the incentives are not automatically aligned.
If you are the partner building and running this, more consumption can mean more revenue. That is a genuine conflict of interest and pretending otherwise helps nobody. The position I would defend: a platform the client stops using because it costs too much has failed, however elegant it was, and however good the revenue looked for two quarters. Optimising a client's bill is not giving away margin — it is the difference between a platform that becomes infrastructure and one that becomes a cautionary tale in their next procurement.
Concretely: show the client their cost drivers, build the caching before they ask, and put the limits in on day one.
The question to ask at design time
One question, asked before the architecture is fixed:
If this works exactly as well as we hope, and everybody uses it constantly, what does it cost?
Not the pilot cost. Not the expected-adoption cost. The success cost. If that number is uncomfortable, the architecture needs to change now, while changing it is a design decision rather than a difficult conversation with people who have come to rely on it.
Success is the scenario worth costing. It is also the one nobody models.
How CloudNala can help
We cost the success case explicitly during design, because it is the scenario that breaks platforms and the one that rarely appears in a business case. In practice that means caching and aggregates built before anyone asks for them, sensible ceilings on open-ended queries from day one, and cost visible per team — so that when adoption goes well, the invoice is something the sponsor expected rather than something they have to explain.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za