The $67.88 Lesson: What Two Trading Bots Taught Me About Automation

Before CryptoEdge was one careful app, it was two enthusiastic bots. One traded Bitcoin. The other traded several coins. Both ran on their own, wrote logs, and — I assumed — kept a record of how they were doing.

When I merged them into CryptoEdge, I wrote an importer to bring their trade history across. The importer was the first thing in the whole project that actually checked the bots' work. Here is what it found.

---

What the numbers said

Across both old apps the importer found 249 trades (182 + 67), with 6 test records flagged and excluded. There were 92,000 lines of logs. None of those logs had ever told me either of these facts.

Why automation hid it

Nothing was broken in the way programs usually break. No crash, no exception, no red text. Each bot did exactly what its code said:

• The Bitcoin bot wrote to a file called profitable_trades.csv. The name was a hope, not a measurement — the only rows in it were the ones I'd added while testing.
• The multi-coin bot's buy logic fired whenever its signal said "buy". Its sell logic needed a stricter condition that almost never happened. Automation repeated that asymmetry 182 times without getting tired or suspicious.

Logs recorded activity. Nobody — not the code, not me — was recording outcomes.

---

What changed in CryptoEdge

The rewrite is built around the opposite instinct: make every number explain itself, and put a human between a signal and money.

Explainable decisions, no black box on the main pages. The verdict — BUY, BUY SMALL, WAIT or AVOID — is weighted arithmetic over market data, and each component shows its contribution. An ML lab still exists under Advanced tools, but no main-page answer depends on it.

The app checks its own track record. One of the seven questions on the home page is "Have these signals worked on this coin lately?" — a backtest of the trend signal on 1-hour candles, shown next to the signal itself.

Paper mode by default, and a typed confirmation for real money. Live orders need Live mode, your own key, and typing LIVE. That friction is the point.

Kill switches. Maximum drawdown limits per 24 hours stop trading after a bad stretch instead of letting automation dig deeper.

Never send an order twice. When api.binance.com is unreachable, requests fail over to api1…api4. But an order only moves to another host if the connection never opened — an order that may have been delivered is never re-sent. Duplicate orders are the kind of mistake automation makes quickly and humans pay for slowly.

The importer is repeatable. python -m app.services.legacy_import (or a button) re-runs it and only adds trades it hasn't seen. Measuring outcomes is now a feature, not an afterthought.

---

The human part

The rewrite also involved two AI assistants working in parallel on different parts of the merge. Both sets of pages were kept. Reconciling them, deciding which ideas survived, and — most of all — reading the importer's output and believing it was human work.

The $67.88 wasn't the expensive part. The expensive part would have been never looking.

What I took from it

1. Measure outcomes, not activity. Every automated loop needs a number that would embarrass it.
2. Name files after what's in them.
3. Asymmetric logic needs a test. If buying and selling have different conditions, write the test that checks both ever happen.
4. Put friction before irreversible actions. Paper mode, typed confirmations, drawdown limits, never-retry-a-maybe-sent order.
5. Schedule the audit. The importer found in seconds what 92,000 log lines hid for months.

See the CryptoEdge case study →

---

Keep going: ← Previous story · Next story →