A department listed its pain points for us. Overcrowded facilities. Budget allocated on design capacity rather than actual demand. Chronic understaffing as a direct consequence, with overtime eating money pulled from other programmes.
The correct next step, technically, was to talk about consolidating their data. Warehouse or lakehouse. Ingestion. A governance baseline.
We have had that conversation many times and we know how it goes: you can watch the room leave. Not because the audience is unsophisticated — because you are asking people who own an operational problem to get excited about plumbing.
So we did something else.
Building the proof without their data
We took their stated pain points and generated synthetic data shaped to them. Not their data — data with the same structure, the same relationships, the same shape of problem. Facilities with capacities and actual occupancies. Staffing establishments against allocations. Overtime accumulating where the gap was widest.
Then we pointed a model at it, asked it questions, and turned the answers into a dashboard.
It took an afternoon. Getting their real data would have taken months — data-sharing approvals, extracts from systems nobody fully owns, a security review, and a series of meetings to schedule those meetings. That timeline is not an obstacle to work around; it is a fact about how large institutions operate. If your first proof point requires their data, your first proof point is a quarter away.
When we showed it, the conversation changed in about ninety seconds. They stopped asking what the technology was and started saying this is accurate, and can it drill from here into that, and can it show us the rehabilitation programme completion rates too.
They were no longer evaluating a supplier. They were using a thing.
Say the word synthetic, every time
This technique has an obvious failure mode and it deserves the bluntest possible treatment.
Label it as synthetic, out loud, every single time it is shown. In the meeting. On the slide. On the dashboard itself. Not once at the start — every time, because decks get forwarded and screenshots get pasted into other people's presentations.
The reason is not just honesty, though that would be sufficient. It is that a synthetic dashboard is persuasive, and a persuasive artefact detached from its caveat becomes a claim about a real operation. If a number from your demo ends up in a briefing note, you have caused a genuine problem for someone.
What we say, and repeat: this is synthetic data illustrating the shape of the answer. When you give us your data, the same processing runs against it and the numbers become yours.
That framing does something useful, incidentally — it makes handing over real data the obvious next step rather than a big ask.
Why this works, structurally
Both conversations happen in every successful engagement. The architecture discussion is unavoidable and it is where the actual work is scoped. The question is only which one comes first.
Lead with the architecture and you are asking the client to trust that a set of components will eventually produce something valuable. Lead with the artefact and they can see the value, so the architecture question becomes theirs: what would it take to build this properly, with our data, so we can rely on it?
That question is the opening you were trying to force twenty minutes earlier. It arrives on its own, from them, with a completely different level of engagement attached.
What this is not
Three cautions, because this technique is easy to abuse.
A prototype is not production architecture. An afternoon's work pointed at a synthetic database is not a system. It has no access control, no audit trail, no cost ceiling, no operational story. The gap between that and something a department can rely on is most of the actual project, and if the demo has been oversold, that gap becomes an argument rather than a scope.
A connection to data is not a guarantee of truthful answers. The mechanism that lets a model query a database is a connection mechanism. It does not make the answers right. What makes them right is the definitional layer underneath — which is a whole article in this series and the single most under-appreciated part of this work.
Do not let the demo set the timeline. The most predictable consequence of a good prototype is a sponsor who wants it in production next month, because they have seen it and it looked finished. Being clear at the moment of the demo about what is real and what is illustrative is much easier than renegotiating expectations later.
Reading the sponsor's enthusiasm honestly
One more observation, offered without cynicism.
When an executive responds strongly to a prototype, they are usually responding to something specific: it would help them answer the questions they get asked in front of people who can make their life difficult. Oversight committees, boards, portfolio hearings. The recurring, uncomfortable experience of being asked a reasonable question about your own operation and not having the answer.
That is a legitimate need and a good reason to buy. It also means the enthusiasm is attached to a person and their circumstances — their term, their targets, their review cycle. Understanding that shapes how you sequence the work and how much you build around a single champion, which the next article takes up directly.
How CloudNala can help
We build these prototypes as a matter of course now, early, before any data-sharing agreement exists — generating realistic synthetic data from a client's own description of their problem and putting something on a screen they recognise. It is a small piece of work that consistently does more to move an engagement than a considerably better-argued architecture document.
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