Give people the keys. Build the roads first.

Picture a capable employee copying information from one spreadsheet into another so that a third person can enter it into a system nobody particularly likes. The process passes through two departments and Helen, who knows what the yellow cells mean.

The employee can see a better way. Getting it built means explaining the problem, securing a budget and finding a place in someone else's queue. By then, Helen may have retired.

Suppose instead that the employee could enter an organisational AI studio, describe the problem and develop a solution through conversation. They could try it with safe data, inspect the results and refine it. Useful work could then find its way into an internal app store, where colleagues could discover and adapt it.

I think this is worth pursuing. People who understand the work should have more freedom to improve it. But the interesting question is what that freedom requires of the organisation, particularly once a promising experiment becomes something other people depend upon.

Beyond a better form

Citizen development is familiar territory. The ambition here reaches beyond assembling forms and approval flows. Imagine a studio in which people describe the behaviour they need and an AI assistant helps create the application, analysis or agent to deliver it. Much of the implementation would emerge through successive attempts, feedback and testing.

“Vibe coding” captures the informality of that process. It is a less reassuring description of how one might wish to run payroll.

Still, the business user's argument deserves a proper hearing. A service manager knows why requests get stranded. A warehouse supervisor knows which exception consumes an afternoon. Their knowledge can lose detail each time it passes from user to analyst to developer. Building an early version gives colleagues something concrete to challenge while the problem is still recognisable.

The benefit could begin before any software is released. Trying to specify a solution may expose an unnecessary approval or a rule that nobody can explain. The studio should help people explore those possibilities, including finding an existing tool. Sometimes the best result would be deciding that there is nothing worth building.

“Customer” already exists

The objection from the data team is entirely reasonable: freedom to build cannot mean freedom to invent another customer register.

Customers, employees, orders, products and assets are shared business objects. Each needs an identity, a meaning, relationships to other objects and rules governing its use. An order has a lifecycle. Someone owns its definition. Someone is authorised to change its status. Finance and fulfilment need to agree on what “cancelled” means before the van leaves.

The studio should make these governed objects easy to find and use through approved interfaces. Builders need to know which records are authoritative, what the fields mean and which operations they are permitted to perform. A team could then develop a better way to handle delayed orders while retaining the same underlying order records.

Without that foundation, the organisation has installed a communal water system and invited every department to improve the plumbing behind its own cupboard. Everything works beautifully until Procurement turns on a kettle and the customer database begins dripping through the ceiling.

Central governance has an obligation here too. Local experiments may reveal a missing relationship, an inadequate definition or a genuinely new object. There must be a practical route to propose and test changes. If the shared model cannot accommodate the work, people will find somewhere else to put the information.

Control also has to follow the data beyond the initial connection. A tool may read approved records and then create an inappropriate copy or derive information its user should not see. Access, storage, sharing, retention and deletion all belong in the design. A tidy front door offers limited comfort if every new application can add its own side entrance.

The demonstration is the easy part

A builder may recognise a useful result without being able to inspect the code that produced it. That is precisely why the studio matters. It must provide more assurance than an encouraging assistant and a publish button.

The business user should be able to describe what good work looks like, including awkward exceptions. The environment should help turn that understanding into acceptance criteria and repeatable tests. What happens when information is missing? When two people update the same record? When a connection fails halfway through?

AI can help generate and run those checks. Confidence must also come from known test outcomes, enforced permissions and independent review appropriate to the consequences. Two generated answers agreeing with each other may simply mean that the same mistake has acquired a colleague.

The distinction becomes sharper when a solution acts. Displaying delayed orders, recommending compensation and issuing refunds are different permissions. Access to the order object should not quietly confer authority to spend money.

A useful studio would make those differences explicit. Experimentation with synthetic data could be straightforward. Live access would follow existing entitlements. Changes to authoritative records would require validation and an audit trail. Consequential actions would have clear limits, approval requirements and recovery arrangements.

Such controls need to be part of the working environment. Asking every occasional builder to interpret a long policy correctly would transfer the difficult work to the person least equipped to do it. Equally, reviewing every harmless experiment as though it were a new banking platform would defeat the purpose.

Who pays for easy?

The financial argument is more complicated than the time taken to produce the first version. A tool that saves its creator an hour each week may be useful. Its value still needs to survive checking, support, model charges, maintenance and occasional failure.

There is a capacity problem as well. If creation accelerates while review remains scarce, the queue moves downstream. The organisation becomes extremely good at producing things that are almost ready.

Shared objects and reusable components could improve that calculation. Each new builder would inherit definitions and access routes that somebody had already established. But that foundation costs money and needs continuing care. The business case should include it honestly.

Success would mean shorter delays, fewer errors, better service or useful capacity released. Application count would tell us how busy the studio had been. A hundred new tools might indicate ingenuity; it might also suggest that nobody could find the first ninety-nine.

There is another cost easily missed in the excitement: the creator's time. Someone who solves a local problem has not necessarily volunteered to support six departments indefinitely. If the organisation wants initiative, it should provide time to exercise it and a route for successful work to acquire proper ownership.

Some tools could remain small and locally maintained. Others would need specialist support, a handover or incorporation into an established service. The builder should learn enough to challenge results and recognise failure, rather than becoming dependent on an assistant to explain every unexpected outcome.

A shop with somebody behind the counter

An internal app store could help improvements spread. Publication, however, carries an implied promise. A colleague finding a tool in an organisational catalogue may reasonably assume that somebody has checked it.

The listing should explain the problem it solves, who owns it, where it has been tested and what it is allowed to do. Experiments, adaptable templates and supported applications should be clearly distinguishable. Popularity is evidence of interest, not proof that a solution belongs in every department.

The store would also need a record of dependencies. When an object definition changes or an interface is retired, the organisation must know which applications are affected. Reuse should allow different teams to handle an order differently while preserving agreement about which order it is and what has happened to it.

Some contributions would be ideas rather than finished software: an effective way to manage an exception, a useful test or an approval that can safely disappear. Giving those a place would make the catalogue more useful than a collection of applications alone.

And things must be allowed to leave. Without retirement, the store will eventually resemble a country shed in which every shelf holds something that might still be connected to the electricity.

Try the whole journey

I would begin with a business area that has a few persistent problems and a manageable set of well-governed data objects. Give people enough freedom to develop and test solutions, with specialist help available when needed.

Then follow the useful ones beyond the demonstration. Does the benefit survive regular use? Can another team adopt the solution without its creator standing beside them? What happens when the underlying data object changes? Can access be withdrawn and an incorrect update traced and corrected? Can someone else take responsibility for the application?

Those are fair tests of the proposition. If governance consumes the benefit, the approach needs revising. If small local tools repeatedly become brittle dependencies, wider adoption should wait. If improvements survive reuse, change and handover, there is a case for expanding the studio.

The unresolved question is how much organisational capability can grow from local invention. An AI studio and an app store could help, provided the organisation invests in the less conspicuous work that makes freedom dependable.

Give people the keys. Make the roads usable and maintenance somebody's actual job. We will know the idea is working when a useful solution can outlive its first enthusiastic owner, and Helen can finally take a holiday without bringing the spreadsheet.