There's a version of this story where I tell you I discovered automation in 2025, took an online course, and built a tool that got recognized globally. That version is cleaner. More LinkedIn-friendly. Easier to digest.
But it's not true.
The real version starts in 2011, on the floor of a factory, debugging electromechanical systems before most people had even heard the word "workflow automation."
My first job was at ICC as an Electromechanical Technician. Not a startup. Not a tech company. A real facility with real machines that could not afford to fail.
That's where I learned the first principle that still governs everything I build today: design for failure — not for the demo.
On a factory floor, nobody applauds when the machine runs perfectly. That's expected. What matters is what happens when it doesn't — and whether the system recovers on its own before the line stops. I didn't learn that from a tutorial. I learned it from standing next to a broken servo motor at 2am wondering why the safety interlock didn't catch the fault.
Seven years at Festo. Global manufacturer. Precision automation. Pneumatic systems. Servo-driven machinery. Vacuum leak testers. Transfer lines that moved product through assembly at speeds that left no room for error.
The engineering philosophy was simple and uncompromising: zero fault tolerance. Every failure had a cause. Every cause had a fix. Every fix had a documented procedure. And the system — not the engineer — was responsible for detecting, logging, and responding to anomalies.
That's not software thinking. That's mechanical engineering thinking applied at scale. I didn't know it at the time, but I was building the mental model that would eventually become FoxOps.
In 2019, I started my own startup business — a pet grooming salon.
This wasn't a pivot away from engineering. It was a test of something I'd been thinking about for years: could I take the same operational discipline I'd applied to physical machines and apply it to a small business?
The Purple Furball launched in Alabang with QR-based digital check-ins, automated client records, and CRM logic I built from scratch. This wasn't a tech startup. It was a grooming salon. But it ran like a system — because I engineered it like one. It was the quiet birth of the Fabalos philosophy: apply industrial-grade logic to every operational layer, regardless of the domain.
Then the pandemic hit. The shop closed. I got sick — seriously sick. The kind of sick where you start doing the math on whether you're going to be okay.
I was. But it took time.
When June 2022 came and the world was reopening, I made the decision to close the business permanently. Not because it failed — it hadn't. Three years of operation, a loyal client base, real revenue. But I could see what was coming, and I had a body that had just spent two years fighting to recover. I chose to close it on my own terms.
That decision — closing something that was working, before it could break — is also industrial thinking. You don't run a machine until it burns out. You decommission it when the conditions change.
After closing the shop, I needed to move. A brief stint in insurance — I passed the licensing exam with high marks, discovered quickly that theory and sales are very different skill sets, and moved on. Then virtual assistant work. General admin at first. Then something shifted.
A client had a large product catalog on Shopify. Manual tagging. Hundreds of SKUs. They asked if anyone on the team could automate it. I said yes before I finished reading the message.
What I built wasn't from a template — there were no templates involved, there never have been. I mapped the logic from first principles, the way I'd always approached mechanical systems: understand the inputs, define the desired outputs, engineer the transformation layer.
It worked. And it was the first time I realized that everything I'd spent 14 years doing on physical machines translated directly to digital operations. The logic was the same. The domain had just changed.
In 2025, I formally launched Fabalos Automation. Not as a beginner. As someone with 14 years of automation engineering across physical and digital systems — who had been applying industrial logic to every operational context since before most current "automation experts" had built their first Zap.
The case studies went up. The methodology went up. And then I submitted FoxOps — an autonomous self-healing incident response system built on Make and MCP — to a global challenge.
Top 6 Finalist. Make × MCP Global Challenge. Hundreds of entries. Six selected.
FoxOps cuts incident response time from 45 minutes to 1.2 seconds. It detects failures, matches verified SOPs via vector search, executes fixes, and logs everything — without human intervention unless required. It's not a clever demo. It's an engineered system. The same way a pneumatic transfer line at Festo wasn't a clever demo. It was an engineered system.
Most automation breaks silently. Engineers build for the happy path — the demo scenario where everything works. Real production systems don't live in demo scenarios.
I've spent 14 years designing for the failure case. For the 3am alert. For the scenario where the data stops flowing and nobody notices until the damage is done.
That's the gap between impressive automation and invisible automation. Impressive automation makes a great demo. Then it breaks. Invisible automation just runs. You don't think about it. You don't babysit it. It handles its own exceptions, alerts you when something unusual happens, and recovers before you've finished your coffee.
That's what I build. It took 14 years on factory floors, three years running a business, a pandemic, and a very roundabout path through insurance and freelancing to get here. But I got here.