We run a paragliding marketplace of our own. It has been trading since 2017, it handles other people's money, and it is the system every other thing we build gets measured against. That is a useful position to write from, because we are not describing automation we sold to somebody else and never had to live with.
The honest starting point is that most automation projects fail for an unglamorous reason: somebody automated the interesting part instead of the annoying part. The interesting part is usually rare. The annoying part happens forty times a week.
Rule one: automate the thing that repeats, not the thing that impresses
The jobs worth handing to software share a shape. They happen often. They follow the same steps every time. They are boring enough that a human doing them will eventually do one wrong, on a Friday, while thinking about something else. And nobody notices the mistake until it costs something.
On a marketplace that means the plumbing between events: something is listed, something is paid for, something needs confirming, something expires, somebody needs telling. None of it is clever. All of it is the difference between a platform that feels alive and one that feels abandoned.
Rule two: the alert has to actually arrive
This is the failure we would warn any client about first, because we found it in our own code. A feature can be written, deployed, and visibly working — while the notification at the end of it goes nowhere. Nothing errors. No page breaks. The interface even tells the user that somebody has been informed.
That is the worst class of bug in any automated system: not the one that crashes, but the one that succeeds quietly and does nothing. It looks identical to working software right up until the day you need it to have worked.
The worst bug in an automated system is not the one that crashes. It is the one that succeeds quietly and does nothing.
So the rule we now apply everywhere: an automated step is not finished when the code runs. It is finished when somebody has proved the thing at the far end of it — the email, the record, the alert — actually arrived. We test that by forcing the failure, not by reading the code and agreeing with ourselves.
Rule three: know what must never be automatic
Not everything should be handed over, and the judgement about which is which is most of the value. Anything that moves money, accuses somebody of something, or cannot be undone gets a person in the loop by design — not because software could not do it, but because the cost of being wrong is asymmetric.
A wrongly-sent notification is an annoyance. A wrongly-released payment, or a wrongly-flagged customer, is a different category of problem. So the software prepares, gathers, sorts and recommends. A human decides. That division has never once felt like a limitation.
Rule four: fewer moving parts beats clever
Every service, key and integration you add is another thing that can quietly stop working a year from now, usually while you are busy with something else. We would rather run a boring pipeline that a different developer can understand cold than an elegant one that only its author can repair.
That is not conservatism for its own sake. It is what makes a system still be running in five years, which is the only test of automation that actually matters.
What this looks like for a client
Most businesses we talk to do not need a marketplace. They need the same four rules applied to whatever they currently do by hand: the order that gets copied into a spreadsheet, the enquiry that gets pasted into an email, the stock figure that lives in two places and disagrees with itself.
The work is rarely exotic. It is finding the forty-times-a-week job, making it happen without anybody thinking about it, proving the far end of it arrived, and leaving the irreversible decisions with the person whose name is on the business.
Common questions
What should a business automate first?
The job that happens most often and follows the same steps every time — the one that is boring enough that a human will eventually get one wrong on a Friday. Frequency matters more than sophistication. The rare, complicated task is usually the worst place to start.
What should never be automated?
Anything that moves money, accuses somebody of something, or cannot be undone. Software can prepare, gather, sort and recommend; a person should make the decision where being wrong is expensive or unfair. That division has never felt like a limitation in practice.
How do you know an automation is actually working?
By forcing it to fail and watching what happens. The dangerous failure is not the one that crashes — it is the one that succeeds quietly and does nothing, while the interface reports success. An automated step is finished only when somebody has proved the thing at the far end of it arrived.