Home / Articles / The citizen developer is good news: the spreadsheet grown up, the best briefs ever written, and the handover from explorers to villagers and town planners that makes them last
The citizen developer is good news: the spreadsheet grown up, the best briefs ever written, and the handover from explorers to villagers and town planners that makes them last
By Dinis Cruz · 2026-10-14 · article v1.1.0, 2 versions · newsroom v0.12.54 · citizen-developervibe-codingspreadsheetswardley-mapsvillagerstown-plannersvault-appssgitempowermentarticle
Abstract: At a conference today the phrase "citizen developer" came up as a worry, the new name for people outside IT building things they should not. I think it is one of the best things to happen to software, and a better way to talk about what is usually called vibe coding. It is not only citizens: it is the employee, the business owner, the expert, the person who knows the work. People have always built with what they controlled, and for most of them that was a spreadsheet; spreadsheets are full of errors, and the world runs on them anyway, because they were the only tool people had. Now they can build full applications, and those applications are also the best briefs ever written: what the user actually wants, in a form that runs. The work is the handover, from the explorer who built it to the villagers who harden it and the town planners who make it scale, with all the non-functional requirements the explorer never had to think about. Encrypted, versioned vaults are a natural carrier for that: a mini app with its UI and its data in one place, which is what a spreadsheet always was, with history, keys and a clean handover added. Done well, this lets people, organisations and even countries move from rent-seeking, control-based software to tools that serve them, which is also the direction of the business models this newsroom is testing.
In short
- A worry, turned round. The citizen developer is not a risk to contain; it is the best thing to happen to software in a long time.
- Not only citizens. The employee, the business owner, the expert: the people who know the work.
- The spreadsheet grown up. People always built with what they controlled; now they can build applications.
- The best briefs ever written. A working app says what the user wants better than any document.
- The handover is the work. From explorers to villagers to town planners, with the non-functional requirements added.
- A vault is a good carrier. A mini app with its UI and data, versioned, encrypted and distributed.
- From rent-seeking to empowerment. Tools that serve people, and business models where people choose to pay.
A worry, turned round
At a conference today, someone mentioned "citizen developers", attributed to an AWS event, with the tone people use for a problem: employees outside IT building applications that IT will have to clean up. I could not trace the exact quote, but AWS's own definition is neutral enough: "Business users with no or little coding experience, often called citizen developers, can build applications themselves." Gartner describes it as a persona rather than a job title.
I think it is a better way to talk about what has become known as vibe coding, the term Andrej Karpathy coined in February 2025 for coding where you "forget that the code even exists". And I think it is very good news. It is not only citizens, either. It is the employee developer, the business owner developer, the expert in a domain that technology has served badly for decades, building the thing they actually need.
The spreadsheet grown up
People have always built software with whatever they controlled, and for most of them that was a spreadsheet. A spreadsheet is a user interface and a database in one file, and the business world runs on them, errors and all. In Raymond Panko's audits, as The Register reported, "Of 54 spreadsheets audited between 1997 and 2000, no fewer than 49 were found to contain significant errors". JPMorgan's London Whale model "operated through a series of Excel spreadsheets, which had to be completed manually", and at one point "divided by their sum instead of their average". In October 2020, England's test and trace system lost 15,841 positive cases because an old Excel format "limited the number of rows to 65,536".
Those are not arguments against the people who built them. They are a testament to how badly technology served them: the spreadsheet was the only tool they had that they could change themselves. The SaaS apocalypse put it in one line: "Every department will now have people building software the way they build spreadsheets". Now those same people can build full applications, with a real interface, real data and real logic, because they can.
The best briefs ever written
The most useful thing about an application built by the person who needs it is not the application. It is the brief. Requirements documents have always been the weakest link in software: a description, by someone who knows the work, of something they have never seen, for someone who does not know the work. A working app, built by the user, is a brief that runs. It says exactly what the user wants, what they do first, what they never use, and what matters to them, without anyone having to guess.
That is also where the mistake people make is. The SaaS article called it "treating the brief as if it were already a product". A working app is not yet maintained, secured, documented, tested, versioned or able to scale, and the person who built it usually does not want to do any of that. They want to build it and hand it over.
The handover is the work
This is where Wardley maps help, and why I keep coming back to them. Simon Wardley describes three kinds of people for three stages of anything: explorers, villagers and town planners. The citizen developer is an explorer, and that is exactly what an explorer should be doing: finding what is needed, quickly, by building it. Then the villagers take the brief and stabilise it, harden it and put it into production, and the town planners make it scale, with the non-functional requirements the explorer never had to think about: security, reliability, observability, cost, documentation, support.
The newsroom went through exactly that move: Explorer to villager described slowing down to take what had been built quickly and make it something that can be maintained. With agents, the handover itself becomes cheap and visible: a move from one folder to another and a version bump, logged and reviewable. And the security of the result is now within reach of everyone, as The eyeballs get cheap argued: deep review is no longer only for teams that can pay for it.
A vault is a good carrier
The piece of the puzzle I think is underrated is where these mini apps live. A spreadsheet is a UI with data behind it, in one file, emailed around, never versioned. An sgit vault can hold the same thing, a small application with its interface and its data, and add what the spreadsheet never had: history, so every change is a commit; keys, so a reader can see without being able to change; encryption, so it can live anywhere; and a clean handover, because the villager clones exactly what the explorer committed.
I already work this way: small applications with a UI and the data behind them, in vaults, as Custom UIs are not the exception described ("A custom interface per message or moment is not an exception"), and as the wires on this site show, with research desks writing vaults that the site reads. What sgit is is the longer version of why. A vault is a distributed, versioned spreadsheet that can be a whole application, and that is exactly the carrier the citizen developer's work needs on its way to the town planners.
From rent-seeking to empowerment
The bigger point is what this enables. Industries, practices and people that technology served badly, or served by renting them software they could not change, can now build what they need. That applies to individuals, to teams, to companies, and to countries: sovereignty is the ability to move, and the ability to build your own tools is the first step to it. It lets people be creative and scale what they do in ways that were not possible before.
And it changes the business models around it. When the user can build, the business is no longer locking them in; it is serving them well enough that they choose to pay. That is what this newsroom is testing with its reading meter, where readers pay after they have read, and only for what they valued: Pay after you read is the experiment, and Paying after the value, published alongside this one, is the psychology behind it.
What this does not claim
- The conference quote is untraced. The AWS attribution came from a speaker; AWS's own definition is quoted instead.
- Spreadsheet errors are old evidence. Panko's audits are from 1997 to 2000; the London Whale and test and trace cases are well documented.
- Not every app should be scaled. Most citizen-built apps will stay small, and should; the handover is for the ones that matter.
- Vaults are one carrier. They are the one I use and build; the argument does not depend on them.
If you have people building their own applications and want help turning the best ones into something that lasts, write to agent@riskmandate.ai.
Where this comes from
A voice memo of mine on 14 October 2026, after a conference, written by this site's agent in the voice of this site; the argument and the editorial responsibility are mine. A research agent gathered the evidence and the quotes were checked on the pages themselves. AWS, What is low-code?; Gartner, citizen developer; Wikipedia, Vibe coding; The Register on Panko's spreadsheet audits and on the test and trace error; James Kwak on the London Whale's spreadsheets; Simon Wardley, How to organise yourself. All read on 14 October 2026.
Threads
Builds on
- The SaaS apocalypse will be decided by inertia, not by AI Incumbents and newcomers have the same AI; what separates them is how much past success each has to protect, so inertia decides which SaaS companies survive.
- Why I love Wardley maps: the best of ours, how I read one, and a map inside a map inside a map The best of our Wardley maps with their context, why the technique matters, one map read as a story, and a map inside a map inside a map.
- Go slow to go fast: moving the newsroom from an explorer project to a villager one, with the brief to do it The newsroom is live and charging. Move the reader code to its own repo, same bytes and same bugs, then map, test, review and refactor before new features.
- The eyeballs get cheap: why open source is about to become the most secure software we have, and why secure, sovereign and paid-for meet at the least code in production Cheap, deep AI security review gives open source the eyeballs it never had; with sovereignty and paid maintenance, all point at the least code in production.
- Custom UIs are not the exception: the inbox in 2026, where every message has its own universe Every message has a graph, so it can be shaped for the reader's moment; a custom interface per moment is now how interfaces get made, and each gets a policy.
- Git for things you cannot put on GitHub sgit is git for files you cannot put on GitHub: encrypted before they leave your machine, versioned like git, stored where the server cannot read a byte.
- Sovereignty is the ability to move: play where the ball is going, take away the dot, and keep a twin that works Sovereignty is the ability to move: take away each dot on the map, and keep a twin that works for the minimum viable company, tested in QA.
- Pay after you read: how a reading meter became a working business model in one afternoon, one release at a time Seven releases in one afternoon turned the reading meter into a working model: pay after you read, and the rating sets the price.
- Paying after the value: why a balance that can go negative feels different from a subscription, the psychology behind it, and the experiment this newsroom is running Most purchases are bets on future value; a reading balance that can go negative asks for payment when the value is already in view.
Article No. 127 · start a reading list with it