Process automation · Systems integration
Much of what a team does every week is moving data around: copying it from one system into another, rebuilding the same report, telling someone a number changed. None of that needs a person. I connect the systems you already have and leave the process running on its own — without touching what already works.
In practice
Work that today depends on someone remembering to do it — and that starts happening on its own, with a record of what was done.
Publishing on one channel and repeating it on the others is repetitive and easy to forget. New content can trigger its own distribution.
This site's blog feeds an n8n workflow that reads the RSS feed, drafts the LinkedIn post and emails it to me for review. The workflow is open in the site's repository, with auto-publishing deliberately turned off.
n8n · RSS · Docker · APIs
An AI assistant is only useful when it can reach your data and your systems — not when it answers from memory.
My second brain is a vault of Markdown notes. On my own VPS, an MCP server gives read and write access to that vault: the AI I use answers with my real context instead of guessing, and writes the decision we reached back into it.
MCP · Node.js · Docker · VPS
Two systems that don't speak turn into a person copying data from one screen to another — typos included.
It's what I do every day: I maintain a critical government system in ASP.NET MVC and SQL Server integrated with a mainframe, where bridging old and new is the problem itself.
REST APIs · Webhooks · SQL Server · .NET
Information that requires someone to open a dashboard arrives late. Better for it to go after the person.
I use this on myself, over Telegram: every morning, a summary of what's scheduled; on the 1st of each month, the month-end checklist; and when a workflow fails, the alert reaches me before I notice something is missing.
Telegram Bot API · n8n · Cron
Process
Bad automation gets things wrong faster than people do. So it starts small, and only takes over once it has proven it gets things right.
A conversation about what your team repeats every week. You don't need to know what can be automated — that part is my job.
Not everything pays off. You get it in writing: what can be automated, how much time each piece gives back per month, and what is better left manual.
First the process runs and shows you what it would do, so you can check it. Only after it gets things right on its own does it earn permission to act unreviewed.
Automation that fails silently is worse than manual work: nobody notices it stopped. I ship it with monitoring and an alert for when something goes down.
Not sure your process can be automated? Tell me how it works today — figuring that out is on me.
Start the conversation