About Automaty

I build the systems that connect
how work comes in with
how it gets handled after.

Automaty works on two fronts of a service business: being found and contacted, and making sure the work that arrives isn't held together by one person's memory. They are different problems, and almost nobody has both at once.

The through-line

Always the same pattern.
The shortcut inside the system.

01 · Growing up online

Modifying what was already built

Deep in forums figuring out how to modify what others had built. I wasn't learning to code from scratch — I was learning to read a system and find its shortcut.

02 · Heavy operations

The same instinct in a mine

Blasting supervisor on site. When the manual reports became the bottleneck, I automated them. The instinct was the same — only now applied to a real production process.

03 · Technical training

No break, just continuity

Python course by IBM. It wasn't reinventing myself — it was putting a formal name to what I'd been doing for years.

04 · Automaty

The synthesis

Looking at a business as a system with bugs and finding where to intervene. The same thing from the forums, the same thing from the mine, now applied to service businesses.

The same instinct, at different scales.

The click

Why Automaty exists.

I watched someone close to me work too hard, knowing that with a system she'd work less. Tasks that repeated every month. Information that lived only in her head. The feeling that the business depended on her always being available. That's not a system — that's her working twice as hard.

Automaty is also the life I want. Geographic independence, my own project, something I love doing. I sell what I practice — if I don't build the system for myself, I have no right to sell it.

How I work

Two things that aren't negotiable.

01 · Cross-trained lens

I see the business as a program with bugs.

I come from heavy operations and from reading systems, so I bring both lenses at once: the people, the inputs, the outputs, the states a job passes through, and where information gets lost between them.

That view changes the diagnosis. Often what looked like a team problem turns out to be a structure problem — and sometimes it is the other way round, in which case this isn't what you need.

02 · Async by default

Everything gets written down.

I work from Australia, and later from other time zones. That forces everything to be written down, so nothing waits on me being online.

Which means you get what I practise: if something only works while someone is online to explain it, it isn't finished. That goes for your business and for mine.

Where the method came from

This didn't come
out of a book.

It came from a Chilean accounting practice running about fifteen clients with not one process written down. What actually held the business together was a spreadsheet nobody else knew how to use: lose it, and you lose the information.

In April 2026 we delivered the full diagnosis, a new document structure and the critical cycles written down properly. Then we stayed through a whole operating cycle to test it against real data rather than assumptions.

Out of that work came the principle that guides Automaty today: understand the problem first, build second. The method isn't a theory — it's what was left after untangling a real mess.

Automaty is a young company. The problem we solve isn't new.

Let's start by seeing where you stand.

Let's talk about your business →