Operational AI for consequential small teams.
Automate the work. Keep the authority.
AI already made it into the office. The harder part is everything around the answer: what it saw, what changed, who's allowed to approve it, what happens when the case gets weird, and how you recover when reality disagrees. We learn the work first, then automate one boundary at a time.
Enterprise consequences. Small-team reality.
The office already has a protocol. It's just usually stored in people.
the/FBF. The line never stops.
The door's open.
Tell us about the workflow that works fine until the case gets weird. A human reads every message.
Received. We read every message. Talk soon.
Or just book time.
30 minutes, no pitch, no deck. Bring whatever the work actually looks like.
Book a call →Both halves are the point.
Both halves are load-bearing. Automate the work: the retyping, the chasing, the checking, the third place somebody has to re-enter the same fact. Keep the authority: the judgment, the exceptions, the relationships, and the decisions somebody has to answer for. Software can do a thing without being allowed to decide it. We build for that difference on purpose.
1/4 — tap to cycle
"The demo only has to work once. An operation has to survive Tuesday."
The line never stops.
No support maze. Send the problem. A human reads it. Same human who'd be doing the work.
Built like infrastructure.
If the system can't tell you what happened, who was allowed to do it, and whether retrying will do it twice, it isn't finished. That's the whole posture. Explicit state, narrow authority, inspectable evidence, deterministic behavior where deterministic behavior is the right answer, and a way home when reality disagrees.
Building the machinery underneath work that somebody has to answer for.
FBF is built around a pretty simple question: what should the machine carry, and what still needs a person who can answer for the result? We work with small teams where getting the work wrong actually matters. Sometimes that's a license or a regulation. Sometimes it's a customer, a contract, or money on the line.
The business needs machinery. People shouldn't have to become it.
Every office has people quietly acting as the memory, the retry loop, the reconciliation service, the permission layer, and the integration between four systems that don't talk. That's not inefficiency. That's a person doing infrastructure's job because nobody built the infrastructure.
That's Operator Experience. Not the screen. The work around it.
Operator Experience is whether the person accountable can see what happened, spot what's missing, handle the weird case, recover when it fails, and use the authority the business actually gave them. Who remembers what the software forgot? Every system has that layer. Almost nobody designs it.
The factory doesn't run the business. It builds the infrastructure around the people who do.
Go look at the actual work.
The spreadsheet somebody keeps because the official system doesn't quite work. The shared inbox. The vendor portal. The verbal override. The person everybody asks when the case gets weird. That's not mess — that's the real protocol, and the workaround is evidence. Something forced it to exist, and we'd rather find out what. You shouldn't need a distributed-systems vocabulary to follow why your process loses state — we'll explain the machinery where it matters, instead of needing us around to translate it.
Explicit state. Narrow authority. Evidence you can inspect.
Replay and recovery. Boring-safe software wherever boring-safe software is the right answer. AI where it helps, deterministic tools where it counts, human judgment where it matters, the messy middle. And the workflow should still make sense when the vendor changes — what the business means belongs to the business; whichever tool implements it today is replaceable.
Factory Roster
Eassa Ayoub
Founder & Operator-Engineer
Before building systems, ran them — mortgage, accounting, sales, the work where a clumsy process isn't a bad review, it's somebody's close and somebody's signature. Now works at the seam between how a business actually operates and how software represents it.
Built like infrastructure. You can inspect the machinery behind our opinions.
The engineering is public where it can be. We publish software, specifications and tests because "trust us, we understand systems" is not much of a technical standard. Open source is part of our evidence culture, not our business model.
batpak
An embedded append-only journal for Rust that refuses to be a database. Hash-chained ancestry, verifiable receipts, deterministic replay from zero. It exists because the obsession with provenance and recoverable history predates the marketing language.
LiteShip
One definition of meaning projected into every surface that needs it — layout, GPU, ARIA, a machine manifest — instead of four hand-maintained copies drifting apart. This page runs on it. Same idea as an operation with one truth and several views of it.
ThreadPak
Current systems R&D: typed history, authority, effects, receipts and reconciliation for work that mixes people, software and models. Architecture and typed specifications exist and the harness is being built. There is no released runtime, and it is not part of anything we sell today.
We make the batteries.
When the same operational shape keeps surviving across engagements, we pull on the reusable part — a state primitive, an adapter, a review surface, an evidence contract. By the third similar job we should know whether we found a battery or three problems wearing the same hat. It only pays if delivery time actually falls without the quality going with it. One battery. One boundary.
Recover the real workflow
We start with cases, not a process diagram. Real emails, real screens, real exceptions, the spreadsheet nobody mentions in the meeting. What happens on a normal Tuesday, what happens when the document is wrong, and who everybody routes to when it gets strange. Most of what matters is undocumented, and that's normal.
a written account of what actually happensAutomate one boundary
One recurring piece of work with a clear owner and a real consequence. Software moves what should move deterministically. AI extracts, compares, prepares and proposes. The person accountable for the result keeps the decision. We build it like infrastructure: explicit state, narrow authority, evidence you can inspect, and a way to undo it.
one bounded system, and the limits written downProve it beside the real work
It runs alongside the existing process before it replaces anything. We measure review time, exceptions, rework, and what still needs a human. If the review cost eats the savings, that's a finding, not a failure to bury. The manual path stays open the whole time. And we don't build traps: if we stop working together, you should know what you own, how it keeps running, and how to move it.
measured change, exceptions, and a way home
Straight answers about scope, authority, AI, and fit.
What does Free Battery Factory actually do?
We work with small teams doing consequential work — the kind somebody has to answer for. We learn how the work really happens, find one bounded place where software and AI can genuinely remove effort, build it, and run it beside the existing process until we can measure whether it helped. Judgment, exceptions and accountable decisions stay with the people who own them.
So this is AI consulting?
It's engineering work, and the part that matters is what happens to the learning. We're trying to build a factory: every engagement should leave behind reusable machinery — a state primitive, an adapter, a review surface, an evidence pattern — so the next install costs less without getting thinner. When the same shape repeats enough, it becomes a product. Not before. That's the bet. We haven't proven it yet.
Why 'Free Battery Factory'?
A battery is a reusable piece of infrastructure that removes one recurring operational burden from the people carrying it. It powers a defined part of the machine without owning the business, the professional judgment, or the customer relationship. One battery, one boundary. The 'free' is a direction we're aiming at — separable, portable, inspectable, not held hostage — and it only counts where the architecture, licensing and contracts actually earn it. It was never a pricing model. Some things cost money, and we'll tell you which.
What won't you automate?
Anything where being able to press the button isn't the same as being allowed to decide. Licensed judgment, exceptions, relationships, and irreversible calls stay human. We'll also argue for using less AI than you expected: if a calculation should be deterministic, make it deterministic; if a state transition should be explicit, make it explicit. A model that only ever proposes is often the correct design, not a limitation. And sometimes the answer is leave it alone: if the thing works and replacing it buys nothing, saying so is the useful outcome.
Why is there so much source code on a company site?
Because 'trust us, we know systems' is a weak technical standard. Released packages, specifications, tests, and the things we paused or ended are all on the Builders shelf, stated at their actual claim state. You never have to read any of it. It's there so the claims can be checked.
How do we start?
Send one real case, or book 30 minutes. No deck. A human reads every message.
Got a weird case?
Bring the email thread, spreadsheet, screenshot, vendor screen — whatever the work actually looks like. We'll start there. If you're not sure it's the right thing to bring, it probably is.
Message sent.
A human reads every message.
Field notes from the floor.
No drip campaign. Occasional notes on what we found inside real operations and what got built in response — including the things that didn't work.
You're on the list. We'll reach out when there's something worth your time.
Or just book time.
30 minutes, no pitch, no deck. Bring whatever the work actually looks like.
Book a call →