When not to automate
We turn down or rescope a meaningful share of enquiries. Here is the list of conditions that make automation the wrong next step, written so you can check yourself before paying anyone.
Vizanix engineering · about the author
- SECTION
- Why and when
- PUBLISHED
- 2026-08-30
- CHAPTERS
- 6
- READ NEXT
- 3
- LANGUAGE
- written in English
The case for automation is in why automate trading at all. This is the other side, and it is the conversation we have more often than clients expect.
1. You cannot state the rules
The test: write down your entry condition precisely enough that a stranger could implement it without asking you a question. Not the idea — the condition.
“Enter on a strong move with confirmation” is an impression. How many bars, what minimum size each, what counts as confirmation, what disqualifies it, what happens when two signals overlap? If those answers do not exist yet, automation will surface that at your expense.
2. The edge has not been demonstrated
If the strategy has never been tested on out-of-sample data with fees and slippage applied inside the loop, you do not know whether there is anything to automate. Building a bot to find out is the most expensive possible way to run that test.
The right first project here is a data pipeline and a purged backtest. It costs a fraction of a full system and answers the question that determines whether the full system is worth building.
3. It trades too rarely
A strategy that fires twice a month on one instrument produces about 24 trades a year. That is not enough to distinguish skill from luck within any useful timeframe, and the engineering cost cannot amortise across it.
Two fixes, both legitimate: widen the universe so the same rule fires across hundreds of instruments, or accept that this one stays manual. Automating 24 trades a year is a hobby project, which is fine as long as it is priced as one.
4. The data does not exist
Some strategies depend on inputs you cannot get reliably: order book depth history you never recorded, off-exchange information, something a human notices on a chart that nobody has formalised.
If a required input cannot be obtained programmatically and reliably, the bot will trade without it and behave differently from the manual version. Better to discover that in a conversation than after delivery.
5. You will override the risk rules
The most uncomfortable item, and it disqualifies more projects than the technical ones.
If a daily loss limit will be disabled after a bad morning, if the kill switch will be worked around, if position sizes will be raised manually after a losing streak — then automation adds latency to a discretionary process rather than replacing it. The bot inherits the behaviour that was the problem.
The honest question to ask yourself: when the system does the correct thing and it feels wrong, will you let it? If not, fix that before spending on software.
What we do instead
When one of these applies, the recommendation is usually smaller than the enquiry:
| Situation | What we suggest |
|---|---|
| Rules not formalised | A specification workshop. Often the whole deliverable. |
| Edge unproven | Data pipeline plus purged backtest. |
| Too few trades | Widen the universe, or keep it manual. |
| Data missing | A collector, running for a month, before anything else. |
| Risk discipline uncertain | Start with alerts only — a bot that watches and tells you, and places no orders. |
That last one is underrated. A monitoring bot that surfaces signals without acting costs a fraction of a trading system, proves the signal logic in production, and lets you find out how you behave when it tells you something you do not want to hear. Several clients started there and were better off for it.
This article describes engineering practice. It is not investment advice. Vizanix develops software and does not promise trading returns.