The easiest attack on any platform for direct democracy is the mob rule argument. It goes like this: give people a quick, easy way to vote on anything, and you hand power to whoever can whip up the largest angry crowd fastest. The majority tyrannises the minority. The loudest voice wins. Rights are voted away by people who were never asked to think carefully about what they were deciding.
This is not a fringe objection. Alexis de Tocqueville, writing in 1835 after travelling America and studying its democracy called it the tyranny of the majority. He argued that a majority taken collectively is simply an individual with power - and that giving unlimited power to a majority is no less dangerous than giving it to a king. The power to do everything, he wrote, which he would refuse to one of his equals, he would never grant to any number of them.
For DDD this is the first thing we had to answer before we build anything.
The Athenian lesson
In 427 BC, the Athenian assembly voted in a single heated session to execute every man in a city that had revolted against them and enslave the women and children. A warship was dispatched immediately to carry out the order. The next day, the assembly reconvened. Calmer voices were heard. The vote was reversed, and a second, faster warship sent to overtake the first. It arrived in time.
Historians recorded this not as a story about Athenian mercy but as a warning about decisions made in anger. The right outcome depended on a race between two boats.
Democracy got lucky.
DDD will be designed so that democratic decisions do not depend on luck.
Slow by design
Every mechanism in the platform is designed to slow things down - not to frustrate participation, but to make it structurally harder to reach a decision until it deserves to be made.
Petition thresholds mean an issue must demonstrate real, sustained support before it enters deliberation. A surge of overnight outrage is not enough.
Randomly selected citizen panels mean that before any issue goes to a wider vote, a group of people drawn by lot - not self-selected, not organised, not the loudest - spend time with the evidence, hear from those most affected, and produce a considered summary. This takes weeks, not hours. That is the point.
Deliberation periods mean proposals are scrutinised before they reach the wider community. The question put to a vote is the question that has been tested, not the question as it was first asked in heat or enthusiasm.
What slowness is actually protecting
But slowness alone is not the answer. And here is the thing that is easy to miss.
The problem with the mob is not that people cannot be trusted to make complex decisions. They can. The problem is that mob decisions are made before people have had time to trust each other - and trust is what makes it possible to reach a decision together rather than simply impose one.
A vote taken in the heat of a moment reflects whoever was loudest in that moment. A decision reached after deliberation reflects something more durable: the considered view of people who have had time to hear each other out, sit with the difficulty of the question, and find where they actually agree. Those places exist. They are almost always larger than the argument suggests. But they cannot be found quickly.
The Athenian assembly that reversed the decision was not slower because an authority told it to reconsider. It chose to come back. Citizens trusted each other enough to say: we were wrong yesterday. Let us look again. That capacity - to return, reconsider, and find a better answer together - is what deliberate design is trying to protect.
The build mirrors the democracy
The same logic shapes how DDD itself is being built.
A citizen mandate is only legitimate if citizens can trust the instrument they are using. This is why the DDD app will follow the Government Digital Service process - the same rigorous methodology used to build GOV.UK and NHS.UK, and the standard the UK public sector uses precisely because cutting corners on citizen-facing services produces expensive failures.
This process is slow by design. Discovery comes first: real research into what citizens actually need, before a line of code is written. Then alpha: testing the riskiest assumptions quickly and cheaply with real people. Then beta: a working version iterated continuously on evidence. At each phase, the citizen assessment panel - founding members of DDD who have committed to this from the beginning - decides whether the evidence is strong enough to proceed.
Nobody moves forward until the evidence says it is safe to do so. The build mirrors the democracy it is designed to serve.
This is also why the app will be open source - anyone can read the code and verify that the platform does what it claims. And why it will meet full accessibility standards, tested with real users throughout, because a democratic platform that excludes people through poor design is not democratic at all.
Speed is how mob rule works. The time it takes to find what we actually agree on, in a platform built to earn the trust of the people using it, is how real democracy does.