Algodesks — Algorithmic Trading Optimization Platform

The problem

Algorithmic trading work usually fragments into separate tools: research scripts, local backtests, parameter notebooks, exchange runners, and operational dashboards. That creates a dangerous gap: the strategy that looked acceptable in research is not always the same thing that runs against a real exchange.

Algodesks closes that gap for crypto futures strategies. The public product promise is direct: build, backtest, and run trading strategies with walk-forward validation and Bybit execution, using the same engine in research and production.

What the product does

Algodesks lets a user define a strategy, run it against historical Bybit market data, optimize its parameters, assemble a portfolio, and then run the result in paper trading mode. The system is currently being tested against Bybit in paper trading before real-money execution is opened up.

This is not an ML system today. The core is parameter optimization: sweep candidate settings, run backtests, reject weak configurations, compare objective metrics, and apply the best candidate back to the strategy or portfolio.

A look at the product

• 

  The public pitch: adaptive crypto-futures trading on autopilot — build, backtest, and run strategies with walk-forward validation and Bybit execution, the same engine in research and production.

• 

  The live dashboard, aggregating every session — paper, testnet, and live — into one view: equity, realized and unrealized PnL, win rate, profit factor, and the equity curve, with each running session broken out below.

• 

  The AutoBuild wizard that assembles a portfolio: pick the universe, exchange (here Bybit testnet), contract type, quote currency, timeframe, and how many instruments — the optimizer sweeps each one from there.

• 

  Backtests — validate strategies on historical data before going live. Every AutoBuild candidate gets a run per instrument with its PnL, trade count, win rate, and profit factor, so weak configurations are rejected on evidence.

• 

  Parameter optimization for one instrument: a sweep of candidate settings scored side by side, with the winning parameters ready to apply back to the portfolio or spin out a new one. This is the core — optimization and backtesting, not ML.

• 

  A running session up close: the live NEAR-USDT chart with entries and exits marked, plus the leg's deposit, leverage, risk-per-trade, and fee gate — the same rules from the backtest driving live (paper) execution.

• 

  Self-serve pricing — Free, Pro, and Premium — with the feature comparison underneath: backtests per month, AutoBuild jobs, optimization runs, max legs, history window, and the real-money trading that stays gated until after paper validation.

What I built

Backtesting as the contract. The same trading rules that are tested on historical data are used by the runtime path. Fees, slippage assumptions, trailing stops, trend gates, and acceptance rules are treated as first-class inputs rather than spreadsheet notes outside the system.

Parameter optimization on Fly.io. Optimization is compute-heavy, so runs are pushed onto Fly.io servers instead of blocking the web app. A job sweeps parameter grids for selected instruments, runs backtests for each candidate, and reports progress back to the product.

Walk-forward validation. The system separates fitting from testing so a parameter set has to survive a later window before it is treated as useful. The point is to reduce overfit, not to pretend the optimizer can predict the market.

Bybit paper trading. The current validation stage is paper trading on Bybit. That gives the system realistic exchange interaction, live market timing, and operational failure modes without turning on real-money risk too early.

Product surface. The public app includes the research loop, pricing tiers, Google sign-in, portfolio/backtest flows, and the operational path from optimization to a paper-trading session.

Architectural choices

No ML until the system earns it. It would be easy to market this as AI/ML. That would be wrong for the current product. The system uses optimization and backtesting; ML can be added later only if it beats the simpler approach under the same validation discipline.

Same concepts across research and runtime. Strategy parameters, trend filters, trailing stops, fee gates, and portfolio legs are domain objects, not UI-only form fields. That keeps the backtest, optimizer, and runner aligned.

Asynchronous jobs by default. Backtests and optimization runs are long-running work. They need job state, cancellation, progress events, retries, and clear failure modes. Treating them as normal HTTP request/response work would make the product brittle.

Paper trading before real money. The product is deliberately going through a paper-trade phase on Bybit. That is where exchange credentials, order placement, live timing, and session recovery can be tested before real capital is at risk.

Current status

Algodesks is live at algodesks.com. The public site positions the product around adaptive crypto futures trading, backtesting, optimization, and Bybit execution. The paid tiers are designed around research capacity, optimization runs, paper trading, and eventually real-money trading.

The platform is currently in paper-trade validation on Bybit. The next important milestone is not "add ML"; it is proving that the optimizer, backtests, portfolio configuration, and live execution path behave consistently under real exchange conditions.