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.
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 screen where somebody re-enters the same fact. Keep the authority: the judgment, the exceptions, the relationships, the decisions somebody has to sign. Software can do a thing without being allowed to decide it. That's the gap we build in.
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. The person who reads it is the person who'd do 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. Explicit state, narrow authority, evidence you can inspect, boring code where boring is the right call, and a way home when it isn't.
Building the machinery underneath work that somebody has to answer for.
FBF is built around one question: what should the machine carry, and what still needs a person who can answer for it? We work with small teams where getting it wrong costs something real. A license. A contract. Somebody's money.
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. The screen is the least of it.
Operator Experience is whether the person on the hook can see what happened, spot what's missing, handle the weird case, recover when it fails, and use the authority the business 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 verbal override. The person everybody asks when the case gets weird. Nobody calls that a protocol. It is one, and every workaround in it 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, so you don't need us around to translate.
Explicit state. Narrow authority. Evidence you can inspect.
The rest follows: replay so you can rebuild what happened, and boring code wherever boring is the right call. AI where it helps, deterministic software where it counts, a person where it matters. The workflow should still make sense when the vendor changes. What the business means belongs to the business, and whichever tool implements it today is replaceable.
Factory Roster
Eassa Ayoub
Founder & Operator-Engineer
Eassa ran the work before building for it. Mortgage, accounting, sales: the kind where a clumsy process isn't a bad review, it's somebody's close and somebody's signature. Now he 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 the software, the specs and the tests, because "trust us, we know systems" isn't a technical standard. Open source is how we show our work. It isn't the 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
Name the states once and cast them to every surface that needs them: layout, GPU, ARIA, a machine manifest. No four hand-maintained copies drifting apart. This page runs on it, and it's the same idea as an operation with one truth and several views of it.
Macroonz
Code generation that can say what it made. A macro that emits tokens and hopes is the same problem as a process nobody can reconstruct afterwards, so this one names every unit it produced, proves the set matches its plan, and explains each decision before the compiler sees it. Then a harness tries to break it: generated inputs, injected faults, mutants of your own code.
We make the batteries.
When the same shape shows up in a third engagement, we pull on the reusable part: a state primitive, an adapter, a review surface, an evidence contract. That's when we find out whether we've got a battery or three problems wearing the same hat. It only pays if delivery time falls and the quality doesn't. One battery. One boundary.
Recover the real workflow
We start with cases, not a process diagram. The emails, the screens, the exceptions, the spreadsheet nobody mentions in the meeting. What happens on a normal Tuesday, what happens when the document is wrong, and where it goes when nobody's sure. Most of what matters was never written down.
a written account of what actually happensAutomate one boundary
One recurring piece of work with a clear owner and a real consequence. Software does the moving: validation, calculation, state changes, anything that has to happen the same way every time. AI extracts, compares, drafts and proposes. The person who answers for the result keeps the decision. We build it like infrastructure, with a way to undo it.
one bounded system, and the limits written downProve it beside the real work
It runs beside 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, we say so. The manual path stays open the whole time. And we don't build traps. When we're done, you should know what you own, how it keeps running, and how to move it somewhere else.
measured change, exceptions, and a way home
The questions people ask before the first call.
What does Free Battery Factory actually do?
We work with small teams doing work somebody has to answer for. We learn how it really happens, find one bounded place where software and AI can take real effort off a person, build that, and run it beside the existing process until we can measure whether it helped. Judgment, exceptions and the 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 afterwards. We're trying to build a factory. Every engagement should leave behind something reusable, so the next install costs less without getting thinner. When the same shape repeats enough it becomes a product, and not before. That's the bet, and we haven't proven it yet.
Why 'Free Battery Factory'?
A battery is a reusable piece of infrastructure that takes one recurring burden off 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: separable, portable, inspectable, nobody held hostage. 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 less AI than you expected. If a calculation can be deterministic, it should be. If a state change should be explicit, write it down as one. A model that only ever proposes is often the right design. Sometimes the answer is to leave it alone. If the thing works and replacing it buys nothing, we'll say so and go home.
Why is there so much source code on a company site?
So the claims can be checked. Released packages, specs, tests, and the lines we paused or ended are all under Open Source, each labelled with what it is right now. You never have to read any of it. It's there for the people who want to.
How do we start?
Send one real case, or book time. No deck, no intake form, no ticket number.
Got a weird case?
Bring the email thread, the spreadsheet, the screenshot of the vendor screen. 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, what got built in response, and what didn't work.
You're on the list. We'll reach out when there's something worth your time.