Why every first automation attempt fails
You have a strategy. You've watched it manually for months. The setups work. The entries are clean. The risk/reward is there. So you automate it. A weekend project, maybe two. You set up TradingView alerts, wire them to a script, and wait for it to print money.
It doesn't. The first week it misses fills. The second week it doubles a position after a duplicate alert. The third week it crashes on a weekend during exchange maintenance and nobody notices until Monday.
The cause is almost never the strategy. Infrastructure is where things break, and it breaks for nearly every trader automating for the first time.
What people build vs. what actually works
What most people build
What happens
Works in paper trading. Breaks in live on the first edge case: duplicate alert, partial fill, API timeout, or process crash.
What actually works in production
Data feed
Real-time WebSocket with reconnection, heartbeat, gap detection
Signal validation
Deduplication, rate limiting, authentication check on alert source
State manager
Tracks all open orders and positions; survives restarts and crashes
Risk engine
Pre-trade: position size check, daily loss limit, max drawdown kill switch
Order management
Places order, monitors fill status, handles partial fills and rejects
Exchange layer
REST + WebSocket, retry logic, error classification (retry vs fatal)
Monitoring
Real-time PnL, fill quality, latency, anomaly detection, alerting
Audit trail
Every order state transition logged with timestamp, required for debugging
The 8 things manual trading handles implicitly
1. Fills are not guaranteed
When you trade manually, you watch your order fill. When your bot places a market order, the exchange might reject it, return a partial fill, or confirm it while the actual fill happens 200ms later. Your bot needs to handle every state: pending, partial, filled, rejected, cancelled. And it needs to decide what to do in each case.
2. The internet disconnects
A manual trader notices when their platform disconnects. A bot doesn't. Without reconnection logic, a WebSocket drop means your bot stops receiving price updates, but your open positions remain. The bot may re-enter because it thinks no position is open, or sit flat through moves it should be trading.
3. Exchanges have maintenance windows
Crypto exchanges often perform rolling maintenance at 08:00 UTC. Your bot needs to know when the exchange is unavailable, hold order submission, and resume cleanly. Not loop on API errors until it hits rate limits and gets banned.
4. Duplicate signals
TradingView can fire the same alert twice if your server is slow to acknowledge. Without deduplication, your bot doubles its position size. Once. Then your risk limits fire. Then your kill switch triggers. This is a recoverable failure, but you need to have built for it.
5. Your judgment is implicit
Manual traders constantly make micro-decisions: 'this setup feels weak, I'll size down', 'there's a news event at 2pm, I'll skip this trade'. None of that is in your strategy document. Automation executes every signal identically. This is actually the point, but it means your edge must be explicit and quantifiable, not intuitive.
6. No kill switch
A bug in signal logic can cascade. If your strategy flips direction on a volatile candle and the position sizing is wrong, the bot will keep placing orders. Without a global kill switch, a single button or API call that halts all order submission, you're watching your account drain while trying to manually cancel orders one by one.
7. Slippage is invisible in manual trading
When you trade manually, you see the fill price and move on. When your bot trades at scale or in thin markets, slippage compounds. A strategy that looks profitable at 0.05% slippage can be break-even at 0.15%. Your system needs to track realized slippage per order and alert you when it deviates from backtested assumptions.
8. State is lost on restart
Your laptop crashes. Your VPS reboots after a kernel update. Your bot process is killed by OOM. At restart, does it know its current position? Does it know which orders are open? Does it re-enter if it thinks it's flat, doubling into an existing trade? State persistence is non-optional.
Three levels of automation maturity
Level 1: Signal execution
Alerts fire orders. No state management. No risk layer. Works until the first edge case.
Level 2: Supervised automation
Proper order management, kill switch, basic monitoring. Runs unattended for hours. Needs intervention for edge cases.
Level 3: Production infrastructure
Full state persistence, reconnection, pre-trade risk checks, audit trail, anomaly detection. Runs unattended for months. Handles its own failure modes.
Platform-specific challenges
The infrastructure requirements are the same regardless of platform. But each platform has specific quirks that determine where things break first.
TradingView →
- ✕No native execution, alerts only
- ✕Duplicate alert risk
- ✕Alert payload formatting inconsistencies
- ✕Rate limits on webhook delivery
NinjaTrader →
- ✕State desync on reconnect
- ✕Sim vs. live mode divergence
- ✕Limited built-in risk controls
- ✕Complex multi-account management
MetaTrader 5 →
- ✕MQL5 limits for complex logic
- ✕Broker dependency
- ✕VPS latency variability
- ✕Painful Python-MT5 integration
Frequently asked questions
Why does my trading bot not work when my manual strategy is profitable?
Manual trading implicitly handles edge cases that code cannot. You notice unusual conditions, intervene when orders don't fill, and skip trades during news. Automation removes all of this judgment without replacing it, unless you explicitly build for every failure mode.
What does a production trading bot need that a simple script doesn't?
Persistent order state management (survives restarts), reconnection logic, pre-trade risk checks, a kill switch, realistic slippage modeling, monitoring and alerting, and a full audit trail.
How long does it take to properly automate a trading strategy?
A simple strategy with basic infrastructure: 2-4 weeks. A full production system with exchange connectivity, risk controls, monitoring, and deployment: 4-12 weeks. Scripts that take a weekend typically miss critical failure handling.
Ready to automate it properly?
We build production-grade execution infrastructure around your strategy: exchange connectivity, risk controls, monitoring, and deployment. Book a free 30-minute diagnostic to scope your project.