The automation work here started as a practical necessity — not a service offering. It became one because the problems it solved turned out to be the same ones most online sellers face.
Labuda Automation is a one-person consultancy run by Karol Labuda — a UK-based e-commerce operator who has been selling on Amazon FBA and eBay for several years, managing everything from sourcing and logistics to accounting and customer service.
The automation work started internally — building systems to handle the operational overhead of running a multi-channel business: settlement reports, invoice processing, inventory updates, supplier emails. n8n, combined with Sage and various marketplace APIs, became the backbone of how the business runs.
At some point, the time saved and the reliability of those systems made it clear that other sellers were spending the same hours on the same manual work. That's where the consultancy side came from — not from learning automation tools, but from having already applied them to a real business.
The focus remains narrow on purpose: e-commerce operations and accounting workflows. These are the areas where the understanding runs deepest, and where practical, production-ready systems can be built with confidence.
There's a meaningful difference between a developer who's studied the Amazon Seller API and someone who has used it to process their own settlement data every week.
When a VAT classification decision needs to be made, or when a Sage contact deduplication strategy needs to account for customers who enter their postcode differently each time — that's where operational experience matters. The edge cases aren't hypothetical.
The processes I automate are ones I've had to manage myself. That changes how a solution is designed — it's built for the exception as much as the standard case.
Amazon FBA, eBay, multi-channel inventory, carrier integrations, BaseLinker — not as research topics, but as tools used in a live business.
Every project starts by agreeing exactly what the system will do and what it won't. Scope creep and over-engineering are both problems — I try to avoid both.
The workflows I build run on real infrastructure and need to keep working when things go slightly wrong. Error handling and monitoring aren't an afterthought.
A good automation project starts with a clear understanding of what the current process actually is — not what it's supposed to be, but what someone does on a Tuesday afternoon when there are 200 new CSV rows to process.
From there, the design is about finding the simplest version of the system that reliably handles the real data. That usually means spending time on edge cases, error states and the 5% of records that don't fit the pattern — because that's where manual work comes back if the automation doesn't account for it.
I work on a small number of projects at a time. Not to create artificial scarcity, but because good automation requires focus during the design and build phase. Spreading thin produces fragile systems.
n8n (self-hosted) · Sage API · QuickBooks API · Amazon SP-API · eBay Trading API · OpenAI API · PostgreSQL · Redis · Traefik · Ubuntu Server
No commitment required from a first call. Bring your process, your current setup and a clear sense of what outcome you're after — and we'll figure out whether automation is the right answer.