SCROLL000%

Eassa Ayoub

Founder, The Free Battery Factory · Operator-Engineer

Businesses are full of people doing a job the software should be doing. I build the machinery underneath— for work somebody has to answer for.

The question is never "is this complex?" It's "who's carrying it?" The machine carries the machinery. The operator keeps the judgment.

Eassa Ayoub - founder of The Free Battery Factory

It usually starts smaller than people admit.

One more dropdown.

One more field.

One more place to remember what the system forgot.

Then someone says, "I'm just bad at this."

They're usually not.

The system is handing its bookkeeping to a human.

I build the other way.

Here's the pattern I can't unsee:

Every layer you add is complexity the user eventually carries. Transfer it back to the machine.

Ever seen a grown adult break down over a password reset?

Ever watched someone avoid their CRM like it's a haunted house?

Seen a colleague stare helplessly at a screen overloaded with dropdowns?

Heard someone sigh, "I'm just bad at keeping track of things"—when the real problem is their tools?

Cognitive Overload

Mental exhaustion caused by badly designed systems.

Most overload doesn't arrive as one dramatic failure. It arrives as dozens of tiny decisions the system could have made itself.

This isn't about special modes or accessibility theater. Cognitive ease is just better engineering. If it's easier for the most overloaded user, it's smoother for everyone.

Full Stack
METAL
where cycles matter
RUNTIME
where state lives
PRODUCT
where users live
INTELLIGENCE
where patterns emerge
RustWASMCargo
TypeScriptEffectNode.js
AstroReactConvexVitest
MCPAgents
METALRUNTIMEPRODUCTINTELLIGENCE

Common questions

What people ask before they reach out.

What do you actually do?

I build the machinery underneath work that somebody has to answer for. In practice that means learning how the work really happens, finding the place where a person is doing a job the software should have been doing, and automating one bounded piece of it — with the judgment and the authority left where they were. I run The Free Battery Factory, which is where that work lives. This site is me, the technical work, and how I think about it.

Why does an engineer keep talking about operations?

Because I ran them first. Mortgage, accounting, sales — work where a clumsy interface isn't a bad review, it's someone's close, someone's money, someone's signature on a mistake. That's not a credential, it's a bias: I don't treat complexity as an abstraction, because I was the one absorbing it. It's the difference between designing a screen and knowing who gets the phone call when the screen is wrong.

When am I the wrong person to call?

When you need more features bolted onto something that already works — that's not the job, and you'd be overpaying me for it. When you're shopping for the cheapest option, because I'm not it. And when nothing about the work has a consequence, because most of what I'm careful about stops being worth paying for. I'd rather say that now than invoice you to find out.

Do you consult, or do you actually build it?

Build it, mostly. Sometimes the useful thing is an architecture review and a written account you hand to your own team, and sometimes it's me in the codebase. I take fractional CTO work when the fit is genuinely there. And sometimes the honest answer is that nothing should be built — if the current thing works and replacing it buys nothing, saying so is the result.

What does "compliance-by-architecture" mean?

That the rule compiles instead of living in a policy doc. A healthcare tool leaking PII got rebuilt with local-only processing — HIPAA-safe by construction rather than by promise. Loan rules scattered across spreadsheets got encoded into a type system, so an illegal loan became a compile error. The constraint stops being something a person remembers to check and becomes something the build refuses to produce.

Why is there so much source code on a personal site?

Because "trust me, I understand systems" is a weak technical standard. The packages, the specs and the tests are public where they can be, stated at whatever claim state they're actually at — including the lines that stopped. You never have to read any of it. It's there so the claims can be checked.

Let's Build

I want small teams doing work that matters — where getting it wrong costs somebody something real.

AI that earns its keep

Features that do the work — not a chatbot bolted to your dashboard so the deck looks current.

Systems shaped like your team

Workflows built around how you actually think — not how the SaaS you're escaping wanted you to.

Fewer decisions, on purpose

Every dropdown is a tax on someone's attention. I collect less of it.

Before I built the systems, I ran them

Mortgage. Accounting. Sales. The work where a clumsy interface isn't a bad review — it's someone's close, someone's money, someone's mistake to sign off on.

So I don't treat complexity as abstract. It's a cost, and someone always pays it — usually the person with the least room to.

That's the lens. Work with me and it's the question I keep asking about your product: who's carrying this — and can we hand it to the machine instead?

The pattern persists