Some years ago I wrote a small script for checking how DCA would look on historical data. Then I wrote a follow-up about doing crypto DCA with Ruby, Binance and Kraken. At the time it was more like a personal automation idea: a script, a scheduler, an exchange API and a small reminder that I should keep the account funded.

The new version of that idea is DCAloop. It is still the same boring core idea, but now it is a real Rails application instead of a half-private script. You connect Binance, choose how much and how often you want to buy Bitcoin, and the app runs the plan for you.

The simple version

DCAloop connects to Binance with a restricted API key. The key should be able to read the account and create spot orders. It should not have withdrawal permission and the funds stay on Binance. This is the main trust model of the app and I wanted it to be very clear from the beginning.

After the account is verified, you can create a plan. Right now the interesting path is Bitcoin DCA on BTC/EUR or BTC/USDC. You pick the amount, the schedule and optionally a take-profit target. When a run is due, the app creates the buy order, stores the fills, fees and execution events, and if the plan has auto-sell enabled it creates the corresponding limit sell.

I don't want to present it as a magic trading system. It is not predicting price and it is not promising profit. It is closer to a disciplined ledger with a scheduler attached to it. The goal is to remove the manual work from a boring recurring strategy and keep enough data around so that you can understand what actually happened.

Why I wanted this

Manual DCA is easy until it isn't. You forget a day, you change the amount randomly, you panic when the market is red, or you start checking the chart too much. The whole point of DCA is to reduce decision-making noise, but if the execution still depends on your mood, then the habit is weaker than it looks.

The other reason is measurement. A simple exchange history is not enough for how I wanted to think about it. I wanted to know which buy created which sell, what fees were paid, how long positions stayed open, how much capital was actually deployed, and what the open sells look like. You can do this in spreadsheets, but after a while the spreadsheet becomes the app.

The engineering parts I enjoyed

This is a small app, but it has many details that punish hand-wavy code. A plan like "buy 50 EUR every 6 hours and sell at +3%" sounds tiny. Then you have exchange filters, minimum notional values, rounding rules, fee assets, partial fills, missing balances, duplicate retries, order reconciliation and the difference between a failed run and a skipped run.

The parts I cared about most:
  • Restricted API verification. The app verifies that the Binance key can read and spot trade before treating the account as ready.
  • Execution history. A run is not just one row. It has events, order ids, fill details, fees, buy state, sell state and skip/failure reasons.
  • Idempotency. Exchange automation needs deterministic client order ids and reconciliation, otherwise retries can become dangerous.
  • Simulations. Historical simulations are useful only if you separate closed sells, open positions, capital usage and fees. Otherwise it is very easy to overread the result.
  • Boring operations. Rails, PostgreSQL, GoodJob and Kamal are enough for this stage. I prefer fewer moving pieces while the domain is still moving.

Calculator and simulations

I also added a public Bitcoin DCA calculator. It uses historical BTC/EUR data and lets someone quickly see what a simple scenario would have done. This is useful for intuition, but it has to be treated carefully. Historical data is not a forecast and a nice backtest can become a very bad idea if you ignore fees, capital needs or the open positions that did not close yet.

Inside the authenticated app there are more detailed tools for plans. The simulator and optimizer parts are there because I want to reason about strategy with numbers, not just vibes. But I still want the language to stay conservative. A tool can help you understand risk better without pretending that it removed risk.

What it is not

It is not investment advice. It is not a custody service. It is not a trading bot that tries to outsmart the market. It is a small automation tool for people who already decided that they want a recurring Bitcoin buying habit and prefer the execution to be consistent.

This distinction matters to me. In crypto especially, it is very easy to make everything sound bigger, smarter and more profitable than it is. I don't want that. I want the app to be useful, honest and boring in the places where boring is the feature.

Small operational note

If you try DCAloop with Binance, enable Binance’s option to pay trading fees with BNB and keep a small BNB balance in the account. That keeps spot fees out of the asset being bought, which makes fills, balances and later sells easier to reason about.

What is next

The first version is mostly about getting the core loop right: connect Binance, verify the key, create a plan, execute buys, optionally place sells, and show the history. After that I want to keep improving the simulations, the open sell management, the public guides and the alerts around things that need attention.

This is one of those projects that started as a personal script and slowly became a proper app because the details kept asking for a proper interface. Let's see where it goes.

What are your thoughts?

DCAloop is free while I am shaping the first version. If you try it, send me an email at [email protected] with what felt useful, confusing, risky, or missing. I am more interested in honest product feedback than in making the app sound more finished than it is.

Generated illustration of an automated DCA dashboard on a laptop