I work with a small team doing millions a year. Everyone has their lane. Mine is the digital, technology, and operations side, which means I wear a lot of hats: the online store, orders, fulfilment, customer emails, reporting, content, outreach, and the systems behind all of it.
That does not mean one person is doing everything by force. It means we have spent years removing the work that never needed a person in the first place.
A spreadsheet copied every Monday. An order typed in twice. A customer asking where something is because the status lives in someone else’s inbox. That is where small teams lose time. Not in one dramatic failure. In hundreds of tiny handoffs.
I think about the setup in three layers: software that does the specific work, AI models that help me build and think through it, and an agent that keeps the whole thing moving.
Where we started
Part of the business works through a marketplace platform that delivers its order files through SFTP. That is simply how the platform sends us the data: CSV files arrive in the SFTP folder. There is no API or webhook we can use instead.
That is not glamorous, but it is real. If somebody has to download a file, copy it into a spreadsheet, check it, and email the next person every time an order comes in, growth just creates more admin.
So I started replacing the steps one at a time. Not with a giant transformation plan. Just by finding the annoying thing that happened every day and asking: does a person really need to do this part?
Over time, the answers became systems. One for orders. One for fulfilment. One for reporting. One for content research. None of them are exciting on their own. Together, they mean the team can spend more time on customers and less time moving information around.
The software layer
The software layer does not start with a software idea. It comes from the operation: seeing where an order gets stuck, mapping the work around it, and building the smallest thing that removes the friction. The code comes after the problem is clear.
The code is simple: scheduled jobs and small tools built for the way this business actually works.
The marketplace order flow is a good example. A script picks up the incoming file, brings the order data into the system, tracks its status, and triggers the next update. The old transcription step disappeared. If someone needs to know where an order is, they can look instead of asking around.
Fulfilment works the same way. Product details are already mapped, so creating carrier consignments takes seconds instead of a run through a web portal. When the carrier makes the easy path difficult, the system has a browser fallback. It is not clever. It just does the boring work consistently.
There is also a contractor hub, store tools, customer-email workflows, and the quiet overnight jobs that collect numbers before anybody starts the day.
The point is not that every business needs a custom system for everything. It is that software becomes useful when it removes a repeated decision or a repeated click. You build the smallest thing that makes tomorrow easier, then you keep going.
Models are interchangeable
I use Hermes for most of the work. The model behind a job is the part I am happy to swap.
If I need help planning something, writing code, researching a subject, or cleaning up a draft, I route the job to the model that fits it best at the time. That might change next month. It should not mean rebuilding everything around a new favourite model.
The systems, context, and way I work stay put in Hermes. The model is the worker I bring in for a particular job. If a better option shows up, I can use it without losing the rest of the setup.
That gets me to a first version much faster. I can describe a tool, have a model draft it, test it in the real workflow, find the edge cases, and tighten it up. Sometimes that gets done in an afternoon. Sometimes it takes days. Either way, I spend more time on the actual problem and less time typing boilerplate.
The judgment is still mine. A model does not know which exception will annoy a customer next month, which shortcut will create a mess later, or whether the process should exist at all. It helps me make the next version quickly. I decide whether it is the right version.
The operator layer
Software only helps if it runs when it is supposed to.
That is where Hermes fits. It is the operator layer for my setup: the place I go to check what happened overnight, run a fulfilment job, pull a number, research something, or deal with an exception.
Most of my work happens through Hermes. I use it to build internal apps for customers, work through the operational systems, research, write, and handle the small exceptions that still need a person.
What is actually connected
At this point, Hermes is connected to the Shopify Admin API. That means I can handle the Shopify work we need from the same place instead of opening the admin and digging through orders, products, customers, and store data by hand every time.
It also works across the SFTP order delivery, the operations database, fulfilment and its carrier fallback, customer-email workflows, reporting, content research, and the contractor hub. Some jobs run on a schedule. Some I start from a message. It is not one magic system. It is a pile of useful connections built as the work demanded them.
Some of those systems help me make decisions, not just move work around. I use them for market analysis too: pulling competitor activity, product information, market signals, and our own numbers into one place before deciding what to list, what to pursue, or what to change. It does not make the call for me. It means I am not making it from memory or a random tab.
That includes small internal apps for customers’ teams when an automation alone is not enough. Sometimes the right answer is a scheduled job. Sometimes it is a tiny app that gives someone a clear place to do the work. Hermes helps me build either one.
It connects the systems rather than replacing them. The marketplace order system still does its job. The store still does its job. The shipping tools still do their job. Hermes gives me one place to work across them and lets scheduled tasks keep the routine stuff moving.
By morning I can have a short briefing: new orders, shipping status, anything that needs attention. If an order has gone sideways, that is the part I should see. If everything is normal, I do not need another dashboard to babysit.
I also use it for content and research. I can ask it to gather sources, compare a few directions, or turn rough notes into a first draft. Then I read it properly. I cut what is wrong, add what only I know, and make sure it sounds like me.
That last bit matters. Automating the first pass is useful. Automating taste is not really the goal.
What has changed
The business did not grow because we found a magic AI button. It grew because more of the operation could handle volume without asking the same people to do more manual work every time.
The systems give us leverage. AI makes building and operating those systems quicker. Hermes gives me a practical way to work with them day to day and change models without rebuilding the whole setup.
You do not need to copy my stack to do this. Look at your own job or business. What do you touch every week that makes you think, “why am I still doing this by hand?” That is usually a better starting point than picking an AI tool first.
Keep a list for a week. Repeated clicks, copied information, reports you make from memory, questions everyone asks, decisions made from a dozen open tabs. Pick one small problem, map what actually happens, and build the smallest useful fix. Run it for a week, then decide what deserves the next layer.
That is how this happened here. Not all at once. One annoying process at a time.