There is a version of this conversation that goes badly, and it starts when an engineering team finds out what the business has been building. The tone is somewhere between amusement and alarm. Look at this. No tests. Credentials in the config. It queries the production database directly.
All true, and all beside the point. Something more interesting is sitting in that repository, and it is not the code.
A procurement officer who builds a tender compliance checklist with AI has done something a development team could not have done, and it has nothing to do with programming. They have encoded years of knowledge about which documents get bids disqualified, which certificates expire at inconvenient times, and which section of the pricing schedule everyone fills in wrongly. That knowledge does not exist in a requirements document. It has never been written down, because nobody ever had a reason to write it down — until a tool made it possible to just build the thing instead.
The prototype is a specification that happens to run
This is the most useful way to think about citizen-built software, and it changes how the conversation goes.
Traditional requirements gathering asks people to describe their work in the abstract. It is a genuinely hard thing to do well. People leave out the exceptions, because exceptions feel like noise. They describe the official process rather than the real one. They forget the workaround they have used every day for four years, because it has stopped feeling like a workaround. Then the software gets built to the description, and it fails on contact with the actual job.
A prototype does not have this problem. The person built it against the work as they actually do it, because that is the only version of the work they have. Every exception they bothered to handle is one they genuinely hit. Every shortcut they took tells you which part of the official process nobody follows. The prototype is the most accurate requirements document the organisation is ever going to get, and it was produced by someone who would have found writing a requirements document unbearable.
The code will mostly be thrown away. That is fine. That was never the asset.
The two halves of the knowledge
What the prototype cannot supply is the other half — and this is where a certain amount of humility is required in both directions.
Neither column can be derived from the other. An engineer cannot work out from first principles which exceptions matter in a tender evaluation; the officer cannot work out what the tool costs at fifty times the volume, or where the data is allowed to travel. The failed internal tools we have seen were almost always missing one column, and it was usually the right-hand one — because the left-hand column is the reason the tool got built in the first place.
The mistake organisations make is treating this as a competition. It reads as a competition when the engineering team's first response to a prototype is a list of what is wrong with it, and when the business team's first response to review is that they are being slowed down. Both reactions are natural and both are corrosive.
Where the good ideas actually come from
If you want to know which workflows are worth automating, ask who is annoyed. The people inside a process can nearly always name its worst part instantly, and their answers are strikingly consistent:
- The report that four people rebuild by hand every Monday
- The handoff where work sits for two days because nobody is watching a queue
- The spreadsheet that exists because two systems will not talk to each other
- The approval that takes a week because the approver never sees that it is waiting
- The customer question that gets answered slowly because the answer lives in a document nobody can find
None of these are technology problems as stated. All of them are workflow problems that technology can address. And all of them are invisible from the outside — which is precisely why the automation backlog assembled by a central IT team so often bears no resemblance to what would actually help.
Giving people the ability to build a rough version of the fix is, among other things, the cheapest possible way to find out which of these problems are worth spending real money on. A prototype that gets abandoned after two weeks has told you something valuable: that problem was not as painful as it felt.
What has to be true for this to work
Enthusiasm alone produces the anti-pattern this series warns about later. Three things have to be in place, and none of them are technical.
People have to be willing to tell you what they built. This is the fragile one. The moment the organisational response to a citizen-built tool is confiscation or a lecture, the next tool will not be mentioned. It will simply exist, quietly, on somebody's laptop, doing something with customer data. Every organisation that has a shadow IT problem built it themselves, one discouraging conversation at a time.
There has to be somewhere for a prototype to go. If the only two available outcomes are "abandon it" or "hand it to engineering and hope", people will pick neither and just keep using it. There needs to be a visible, unfrightening route — register it, get it classified, find out what it would take. The intake route is the whole subject of a later part of this series.
The risk classification has to be honest in both directions. Most citizen-built tools should be left exactly where they are. If everything gets escalated, the process becomes a bottleneck and people route around it. A personal productivity script does not need an architecture review; it needs to be known about.
A worked example
Our own tender work is a reasonable illustration. The useful insight in TenderCity — which parts of a bid document actually determine whether a submission survives evaluation — is not an engineering insight. It comes from people who have lost bids on technicalities and remember exactly which technicalities.
The engineering contribution is different in kind: deciding where tender documents may be stored, what the system does when it is not confident about a clause, which outputs a human must sign before anything is submitted, and how to show afterwards what the system did and why. Neither half is optional. The bid knowledge without the controls is a liability; the controls without the bid knowledge is a very well-governed tool nobody wants to use.
How CloudNala can help
We often get called in after the prototypes already exist, and the first piece of work is usually a discovery and triage pass — find what has been built, understand what each thing is doing with data, classify it honestly, and separate the two or three that are quietly load-bearing from the many that are harmless. The output is generally less alarming than the organisation feared and more interesting than they expected: a short list of workflows worth building properly, already specified in unusual detail, by the people who live in them.
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