The Citizen as Maker

Some citizens go further and build things: a tool for a specific workflow, a site for a campaign, an integration between two services. Not everything needs to be production-ready — experimenting is enough. The public stack makes this possible by keeping the infrastructure open and composable. A maker doesn't need to start from scratch or ask permission — the shared foundation is already there. What they try, and what sticks, strengthens the whole.

Adoption

Democratic technology is inherently decentralised — there's no vendor deciding what you can run, no pricing tier that gates functionality. That openness drives adoption because ownership isn't binary: people don't have to choose between using a tool as-is and running the whole stack. They can design and shape it at whatever level fits them — suggesting a change, configuring an instance, building an integration, or experimenting with something new outright. A tool someone had a hand in shaping is a tool they're already invested in — ownership at the level people want is a stronger driver of adoption than any amount of polish on a finished product. See Starting Points and Assumptions for the kind of problems worth building for.

Responsibilities

That freedom comes with something expected in return. A maker who builds without regard for the other citizens living in the result — other residents, makers, and stewards too — or who reaches for custom code in general without checking it against the values and the rest of the stack, is just centralising differently — swapping a vendor's authority for their own. Building well means naming what a thing is for, being honest about what it isn't ready for yet, and not leaving half-finished things behind for someone else to clean up or remove.

AI is very useful here, but it doesn't remove this responsibility — it sharpens it. Code needs to stay human-readable, not just functional, and that means a maker still needs an actual relationship with the code: understanding what it does and why, not just the prompt that produced it.

It also means bringing people along rather than building around them. Sharing what was tried — what worked, what didn't, and why — is part of the job, not an afterthought once something ships. A maker who never explains their work quietly builds the same kind of dependency democratic technology is meant to avoid, just with themselves as the single point of failure instead of a vendor. That means showing up, and organising them, not just building: skip the meetings — the local group, the other working groups — and it's easy to stop being embedded, ending up building something technically impressive that nobody asked for and that fits into nothing else.

That responsibility doesn't end when something ships. What happens after matters just as much: documenting properly — which AI makes far less of a chore than it used to be — becoming a steward for the thing for a while rather than walking away from it, and staying a resident who keeps participating in the mutual aid that got you here in the first place. The knowledge and the effort invested to make you a maker weren't free, and they don't stay yours by default — they need to be reproduced, or the next maker starts from nothing.

Flourishing

Making isn't an endpoint either. A maker who keeps returning to the same tool, fixing what breaks and making sure it still fits, is already becoming a steward — the role that follows naturally once building tips over into caring for what got built. And a maker who spends more time helping others use and shape what exists than building new things is doing the quiet, essential work of a resident too.

That movement between roles is the point, not an exception to it. Makers who never let anyone else touch what they've built become the very bottleneck this stack is designed against. Passing on what you've learned — how something works, why it was built that way, what to watch out for — is what lets the next maker start from where you left off instead of from zero.