In 2011, Adam Wiggins published the twelve-factor app, made for a transition between a time where we dragged files on to FTP servers to "deploy" them, and losing a single server without a backup would mean the end of a business, to a time where we published our apps as "artefacts": deployable units that were versioned and launched independently.
12 Factor apps were "convention over configuration" for infrastructure: rules that you could follow to build a small app, which would ease your ability to run, maintain, and scale apps beyond their initial deploy. 12 Factor apps pretty well became the de facto standard for how we build and deploy web applications today, containerised, versioned, orchestrated, and deployed safely.
Things, however, have changed since 2011.
The 12 Factors are essentially a set of rules for humans to manage infrastructure upon which software is deployed. In 2026, whether we like it or not, we have AI: machines that can take frameworks like the 12 Factor app and build against them a lot more efficiently.
AI gives us new opportunities. The 12 Factor app didn’t make any assumptions about responsibilities outside of the architecture. Its basis was taking something already built and having a guiding set of principles for deploying that artifact responsibly.
Responsibly being the key word, AI gives us a new set of opportunities and a new set of challenges. An LLM will do what you tell it (with caveats), and you can choose to point it along paths designed with the assumption of human operators, or you can choose to point it somewhere new.
The eleven factors are an attempt to map out that new path. What is the value of code when it can be manufactured at scale? What are our responsibilities as software developers when anyone can use the same tools that we do just by asking? Are there opportunities and efficiencies that we missed while we burned other people’s money in a frenzied attempt to make them more money?
The eleven factors imagines that there are.
- I. Trust no one Secure systems with technology in addition to policy
- II. Let kids play If it isn't safe for a child, it isn't safe
- III. Encrypt everything What can be hacked will be hacked
- IV. Great design is for everyone Care is not a premium tier
- V. Intent is the system How closely does a system get to what it was designed to do?
- VI. Built by humanity, owned by humanity Software built with AI should be open source
- VII. Self-hosting is a right If you can't run it yourself, you don't own it
- VIII. Many small things Greater than one big thing
- IX. Inefficient builds efficient Justify ecological cost by building ecological efficiency
- X. Humans come first AI is opt-in, never required, always disclosed
- XI. Centralised infrastructure is glue Thin, blind, replaceable
I. Trust no one
"Didn't I warn you not to trust anybody, Dr. Jones?"
In the 15 years since 2011, there are those of us who have been consistently let down by people we once considered heroes and inspirations. Google’s "don't be evil" mantra turned out to be vacuous at best, and wherever they’ve been able, they've sought to monopolise any space they enter or burn beloved products after they decided they didn't want to run them any more. Big companies with millions and billions of users have forced a set of complicated tools on a generation of software developers who think they need heavy machinery instead of simple tools.
Data has been sucked from us relentlessly. Seemingly well meaning folks celebrate shifts in the Overton window, and people excuse fascism, sexism, racism, homophobia, transphobia and whatever else they can in an effort to provoke outrage and distract from their exploitation of entire populations to make a buck on a buck.
Trust has been eroded, and Walter Donovan’s message from "Indiana Jones and the Last Crusade" rings true.
We’ve all been taken for a ride. Trust needs to be earned, not assumed.
II. Let kids play
If it isn't safe for a child, it isn't safe.
The world is up in arms over the harms that can come to kids by the use of technology that has been created with addictive algorithms, which big companies deny existing. What do we do? We ban the technology from kids.
BANS DO NOT WORK. There are literally speakeasies in every city in the world that celebrate the golden age of alcohol distribution in the United States when alcohol was prohibited.
Have you ever met a child? The surest way of making them want something more is to take it away from them.
Meanwhile, the companies that produce the garbage that gets forced upon kids with those dubious algorithms face little to no accountability for allowing this to continue.
If it’s not safe for a kid to use, it isn’t safe. And a corollary: the technology that we use to secure our own digital space should also be applied to the spaces that our kids get to use.
Age verification is not the answer: building systems that protect ourselves and our children is. Surveillance is not the answer: we should be teaching kids how to have a positive relationship with technology, not using it to oppress them. We need to respect our children.
Here’s how the robots put it: 🤖 Building for kids forces honest defaults: private by default, no strangers by surprise, no dark patterns, no engagement mechanics tuned against an unfinished brain, no data trail that follows them into adulthood. It rules out entire business models — deliberately.
Just like accessibility is for everyone, including kids in the design from day one makes it safer for everyone.
III. Encrypt everything
🤖 What can be hacked will be hacked.
Every other week we hear about the latest database that has been hacked, leaking our email addresses, our phone number, our home address and more. There’s hardly a person on the planet who uses software online that hasn’t had some of their data leaked.
Crank calls, offers to sell crypto, cold emails from unscrupulous actors. Just out there for anyone to share. And all we can do is shrug.
HOW ARE WE OK WITH THIS?
Encryption technology is a mature field at this point. Every major software environment ships with advanced tools to encrypt data. Large companies who don’t sell fruit have forged a path as stewards of data, unlike other companies who have acted as data brokers, and we have collectively conceded a false truth: we don't care.
The first question anyone should ask of their software vendor is: how is it encrypted?
In the sorry absence of that question, every software vendor should ask themselves: do I want this data?
Unless it’s absolutely paramount to have access, the answer should always be no.
A weaker version of "encrypt everything" can also be: "separate everything" so that no customer data is mixed, and the attack surface for any customer is limited to just that customer.
IV. Great design is for everyone
Care is not a premium tier.
It’s hard to quantify great design, but it seems that the more secure something gets, the more compromises on how the product feels, and acts, and responses we accept. The result is that people tend towards less secure options that are better designed because they’re more convenient, more conforming.
Software (and a lot of technology in general) is a field where folks expect things to work frictionlessly, even without training. Great design can add to that.
Too many well-intentioned projects fail because their creators don’t have the time and resources to iterate to the point where they compete with products whose designers are paid far too much to make people want things they don’t need.
AI has the potential to level that field, and to bring an unrelenting ethic to user experience that has hitherto been economically unfeasible. Practitioners are still required to put the work in, but under-resourced individual practitioners can now do the work that perhaps teams were required to in the past.
V. Intent is the system
How closely does a system get to what it was designed to do?
Until very recently, good code has been the differentiating factor between good software and great. In 2026, that changed, with the expanding capabilities of computers to generate code on a par or in excess of the abilities of many software developers.
One positive benefit of this is that it expands the overall capabilities of individual software makers far beyond their skillset. It’s still important that software code functions, that it is tested, verified, and audited. Good software development practices still matter, LLM tools themselves are also very good at following good practices if directed toward them, of reviewing their own work, refactoring, and systematically following process.
When code is no longer the asset it once was, the value of a system shifts. If code is no longer the asset, the new asset is: what is the system supposed to do? The measure is: does it do what it is supposed to do?
Imagine as a user of a system, you were able to evaluate the decisions that went into shaping the system, both well-intentioned and the not-so-well intentioned. "Intent is the system" leads to asking whether these kinds of things are possible. What if, in addition to the code, we shared the ideas that led to the code? This leads to open record-keeping, like an open prompt ledger for AI-created systems, and potentially an open decision ledger for non-AI systems.
VI. Built by humanity, owned by humanity
Software built with AI should be open source.
There are those who believe that the way in which AI systems have been trained constitutes theft. There are others who say that public data was fair game to ingest since it was public. What nobody disagrees on: the data was used to train systems without the explicit consent of the authors.
There are ideologies and science fiction alike that believe that everything created by any human ought to immediately transfer into the public domain, share-and-share-alike. Today’s society hasn’t yet reached that pinnacle of the commons, and so copyright and private ownership of one’s own works prevail.
However, never before have we had such ambiguity about where the skills and ideas and intent of the creator ends and the synthesis of all that came before begins. We are in interesting times.
It seems though, that logically, if a tool synthesises as much of humanity’s collected knowledge as its creators could ingest to train it, then the moral obligation on the user of that tool is to return the output to the collective.
For software, the conclusion is that there ought to be no other software than open source. And further, if open source software becomes as convenient, as reliable, as easy-to-adopt, and as secure as proprietary software, then the only differentiator between open source and proprietary becomes: trust. Finally, if trust is final differentiator, who will you trust more: the vendor whose code is open source that you or others can scrutinise and verify, or the vendor who chooses to keep theirs private?
VII. Self-hosting is a right
🤖 If you can't run it yourself, you don't own it.
Infrastructure models for computing ebb and flow. Thin-client interfacing with a mainframe. On premise everything. The evolution of SaaS where computers more powerful than the servers they run on consume services via thin web clients. And now the same is happening with AI.
Self-hosting is almost always the wrong approach when building resilient systems, and almost always the right approach when building secure, and indeed sovereign ones. The full eleven factors make the case that self-hosting ought not necessarily be required for security, but the seventh factor is that it should always be possible, without compromise.
Eleven factor software, in an absolute sense, should essentially be uncontrollable, unbuyable by an external party. If, at any time, someone who uses an eleven factor app decides that they want to run it on their own hardware, this should be built in.
The ideal of this model is that self-hosting is not penalised in any way, unless a decision is made explicitly.
In practice, this means: self-hosting and "cloud" hosting are functionally the same. Self-hosters gain access to relay services, broker services etc. to allow for a "great-design" experience, but none of the centralised infrastructure is required.
Finally, at any point, the self-hoster should be able to decide to pin to any version and no longer receive updates they don't want. Most folks will want to be on the latest stable release, but that is a choice, not an enforcement.
VIII. Many small things
Greater than one big thing.
There are people who think that monopolies are the singular goal of system creation. This factor rejects that. There are those who think that big systems should be broken down into tiny parts to the nth degree. This factor also doesn’t fully accept that.
This factor is about building resilience into the system, rather than breaking things apart, and not necessarily splitting systems into tiny parts, but making complex systems deployable in small units.
The systems-thinking here is inspired by rebel cells (see the Bajoran resistance). Small autonomous units: take one out and the rest continues. Each unit is capable of a wide range of abilities, not just a thin-slice (e.g. this isn't the unix philosophy, although that feeds in).
"Many small things" is also inspired by healthy biological systems, as opposed to the proliferation of hypergrowth cells that eventually poison the host and suck the life out of the system. In biology, we call that cancer.
Many small things are more securable. Attack targets become more distributed. The economics of breaking into any cell—or instance—become lower return on effort.
Small systems are also much easier to understand, to distribute, and to run locally.
Small systems are easier to modify, to customise, and ultimately, to own.
The result: every user of software systems built this way is in control: control of where their compute and storage is hosted, control of whether they receive automatic updates, control of whether they update at all.
IX. Inefficient builds efficient
Justify ecological cost by building ecological efficiency.
One of the most scathing criticisms of AI is the dismantling of trends towards reducing the carbon footprint and ecological impact of technology. "Build more data centres!" "Buy up all the RAM!" "More GPUs!".
The land-grab towards "AI all the things" without considering the impact is typical of an industry that has spent 20 years taking, taking, taking and never asking first.
Citing AI’s proliferation as "inevitable", and attempting to force it into every aspect of our daily lives and society is as short-sighted and annoying as it is morally reprehensible in a climate emergency. We’ve seen this before with cars, and a systemic campaign over 100 years to villainise harmless pedestrians and cyclists without acknowledging that people in cars are one small slip away from causing death from the moment they start the engine.
This isn’t to say cars are not amazing. They enrich people’s lives and unlock possibilities beyond imagining before their creation. Cars have their place across a wide range of purposes.
There is a similarity here with AI. Where cars have been forced upon us to do tasks that would be orders of magnitude more efficient on, for example, a bicycle, AI is mooted as the solution for everything.
There is another analogy: factories. Factories sit at the intersection of innovation and regression: the ability to mass produce items at great ecological cost. Factories that produce cars amplify the problem, where factories that produce bicycles justify their cost by producing clean, efficient outputs.
One more: plastic. Plastic has allowed us to produce complex solutions at lower cost than more natural ingredients. But of course, plastics ended up being over-used and we ended up with the proliferation of single-use plastics for things (like bottles) that would be better off with more sustainable solutions. Same goes for the proliferation of single-use AI-generated tools.
Listen to how the robots describe themselves:
🤖 A large language model is a spectacularly inefficient way to compute anything — and the finest tool ever made for creating things that compute efficiently. That is not a paradox; it is a division of labour as old as tooling. The kiln burns hot so the brick doesn't have to.
It’s worth considering that cutting edge systems that burn carbon may well be justified to create efficient systems that run on old hardware with performance that today’s mid-range systems can only dream of.
X. Humans come first
AI is opt-in, never required, always disclosed.
Surely this is just common sense? It’s very tempting to leap ahead to a science fiction world where anything is replicable on demand. That world is yet to arrive. In the meantime, building software that cannot be operated by humans seems foolhardy.
Software for humans built by humans should be usable, reworkable, and maintainable by humans, no matter the tooling. AI systems are great at synthesis: taking existing ideas and using them to produce new output. Whether they become great at invention remains to be seen, but a human operator with LLM assistance has access to a larger library: tools and abilities that were out of reach for the sheer effort of researching all of the options.
The old adage is "the best tool for the job", which has always been bendable to fit any software choice, but with assistance, choosing "the best tool for the job" is within reach for any category: particularly when it comes to choosing tools, built by humans, that already exist to solve human-shaped problems.
Building for human maintainability leads to naturally more resilient systems, and the added benefit is that since AI is trained on human-shaped patterns, tools optimised for humans tend to work better for AIs too.
The final pièce de résistance of this factor is that it is truly inclusive: building for humans with AI does not preclude humans using the systems without AI.
XI. Centralised infrastructure is glue
Thin, blind, replaceable.
The final factor is the piece that takes all the principles above and compels us to build systems that feel uncompromising in their user-experience and ability to get started. The previous ten factors are not novel. All of them have examples and working models in the wild. What seems rarer are systems that contain all the factors, and conform to a standard of design and aesthetics, form and function that means they are usable by everyone.
To turn to wit: open-source products and systems, self-hosted tools and services are not "sticky". Deploying open-source and self-hosted systems at scale often comes with costs: overhead of setup, overhead of maintenance, conceptual overhead to carry for the people who want to use the systems. Proprietary systems tend to be more turn-key: much less conceptual overhead to get started.
Glue infrastructure aims to create the illusion of centralisation without the traditional compromises, whilst remaining decentralised, with self-hosting as first class.
Examples of glue infrastructure: credential vaults, push-notification relays, oauth brokers, image and service proxies. All of these services can be provided to instances in a decentralised system without compromising the security of the instances. Glue infrastructure exists to make using the system seamless for those who value simplicity and efficiency. One signin: all your stuff. "🤖 Complexity is hidden, never revealed."
For those who wish to self-host, glue infrastructure is offered as optional, but not required, and for those who wish to host their own glue infrastructure, that’s always a configuration change away.
When you want to make your open-source, decentralised system sticky, bring the glue.