Most software companies write documentation after the fact, if they write it at all. A feature ships, and someone describes what it turned out to do.
We did it the other way around. Before we built most of Factorial, we wrote its documentation: what each part of the product does, the rules it follows, and how it connects to everything else. The docs are still the source of truth for how Factorial behaves. When the code and the docs disagree, one of them has a bug, and we decide which.
It turned out to be one of the most useful things we've done.
It made us think about how everything connects
An MES is not a collection of independent features. A redline changes a task on a work order, which may place a hold, which blocks execution, which affects the queue a technician is looking at. An issue can put holds on inventory, tools, and several work orders at once. A procedure revision carries part requirements that have to stay consistent with the EBOM.
Writing a page about one feature forces you to answer what happens at every one of those edges. It's much cheaper to discover that two features disagree in a paragraph than in a migration.
Our agents hold us to our own rules
We build Factorial with coding agents, and the docs are part of the context they work from. That has had an effect we didn't fully expect: the agents catch us contradicting ourselves.
People forget the rules they wrote down months ago. Ask an agent to plan a change that quietly breaks one, say, a script that edits a record without the change being attributed to anyone, and it will often point to the page that says every change has an accountable person and ask which one should win.
It also makes planning with agents better defined. A request like "add a new kind of hold" isn't a blank page. The rails are already laid: how holds behave today, how they're reviewed, how they appear in history. The agent's plan has to fit them, and when it doesn't, that's a conversation worth having before any code is written.
We could ask for feedback before we built anything
Building software isn't instant yet, and rebuilds and data migrations are expensive. Documentation is a complete description of a product that costs a fraction of building it.
So we shared it. We asked friends in the industry to read the docs and tell us whether what we were describing would hold up in their factories. Their answers changed what we built.
The same docs help prospective customers today. They can see exactly how we think about traceability, change control, and integrations, including what Factorial is not for, before they ever talk to us.
It made us look at the product honestly
Reading your own product end to end, the way a buyer would, is humbling. We read it and asked a blunt question: would anyone buy this? Where the answer was "not yet," the docs showed us why.
They also became our list of gaps. Writing a page meant noticing what it couldn't say yet: an unanswered question, a workflow that stopped short, a case nobody had decided. Those became our work.
Documentation written first is a design document that customers can read. It keeps the product coherent, gives everyone, people and agents alike, the same rules to work from, and lets us find mistakes while they're still cheap.
Start with Why Factorial and The Tao of Factorial.