Why I didn’t use existing tools: Most options I tried were either locked to one exchange or did fixed-amount DCA with naive execution. I wanted multi-exchange support and a way to scale buys during dips and preserve capital during rips. I also kept running into inconsistent API rate limits and small-order quirks, which made me prefer building.
Why turn it into a service: At first it was just JSON configs on my machine. More friends kept joining. I added a basic self-serve UI so I wasn’t SSH’ing to change params. Hosting costs stayed small, but my time did not. At that point it made sense to package it.
“multiplier DCA”: Instead of buying a fixed amount on a schedule, the bot computes a multiplier in the range 0.1–3× and scales the order size. During dips it buys more; during euphoria it scales back or skips. Inputs include standard indicators plus some AI and social context; guardrails cap the multiplier and enforce cool-downs so you don’t blow a week’s budget in the first leg of a dump. The goal isn’t to “time the bottom,” it’s to shift size a bit toward better prices without starving future buys.
Results so far (caveats included): On a public, static backtest over the last year, the multiplier approach accumulated ~30% more BTC than fixed DCA, with slightly higher total spend. Backtests aren’t reality; live trading taught me to add pacing and cool-downs.
Tech stack and latency: Watcher → queue → workers. Node.js services with AWS DynamoDB/Aurora for state, SQS for queues, Lambda workers for execution. Typical timings: ~20 ms to scan, ~10 ms to enqueue, ~100 ms–2 s for the trade depending on the exchange. We didn’t optimize for HFT; this is DCA, not microsecond arbitrage.
How long it took: The first script is ~6 years old. The multiplier engine grew out of a friend’s suggestion to size into dips. I iterated for years, added a UI this year, and opened it to more friends.
I’m here for feedback and AMA—architecture critiques, multiplier design, failure modes, exchange abstractions, whatever’s useful.