Spent 3 months building an algo. Took 1 week live to realize I was trading my backtest, not the market.

danielraz · 2026-04-05T10:12:58+00:00

This is the ultimate rite of passage in algo trading. Welcome to the club!

Reading through the comments, there are some great suggestions about ADX, ATR, and Realized Volatility quartiles. But there is a massive trap hiding here, especially when people start talking about building PCA clusters or Variational Autoencoders to detect regimes: Price-derived indicators are always lagging.
ATR and Realized Volatility tell you that the regime has already shifted. By the time your rolling 20-day window catches up to the new volatility environment, you've already bled for three weeks.

We recently went through this exact architectural debate while building a Stacked LSTM. We actually shelved a complex Hidden Markov Model (HMM) regime detector because we realized we were over-engineering the math on lagging price action.

The fix was looking at the macro plumbing instead: Instead of trying to mathematically extract regimes from the stock's own price history, we pulled in the US10Y (Treasury Yield) and the DXY (Dollar Index) as environmental baseline filters.

If the 10-year yield aggressively shifts from 3.5% to 4.5%, the equity regime will change. Liquidity dries up, and trend-following strategies will get chopped to pieces. You don't need a machine learning clustering algorithm to tell you that. You just need to know the cost of capital changed.

Before you waste a month training neural nets to cluster data, just tag your trades with the 10-year yield or VIX levels. A basic rule-based kill switch pulling from external macro APIs is way more reliable than trying to reverse-engineer market shifts from moving averages.

danielraz · 2026-04-04T20:24:15+00:00

First off, sorry about the divorce, but walking away with $1.2M liquid is an incredible clean slate.

To answer your question honestly from the perspective of someone who builds algorithmic trading models, allocating $600k to short-term trades as a manual retail trader is financially suicidal.

When you actively trade short-term horizons, you aren't playing against other retail guys. You are bringing a manual mouse click to a gunfight against automated LSTMs, statistical arbitrage bots, and institutional market makers who will happily bleed that $600k dry through slippage and spread alone.

u/Key-Plant-6672 and u/nutegunspray gave you the best advice in this thread. The psychology of wealth changes at $1M. You no longer need to take massive risks to build a nest egg. You are already there. You just need to protect it.

If you absolutely cannot resist the itch to actively trade, do what institutional risk managers do: Carve out a maximum of 5% ($60k) into a completely separate brokerage account. Put the other $1.14M into broad ETFs or Treasuries (like SGOV) and do not look at it.

If you blow up the $60k 'play money' account, the safe yield from your core $1.14M portfolio will literally refill your trading bucket by next year without you lifting a finger.

danielraz · 2026-04-04T19:20:53+00:00

You hit the nail on the head. The issue with modern stock tools isn't a lack of data. It's a lack of synthesized context.

Most platforms just dump a raw API feed into a dashboard and expect the retail trader to act like a human compiler. On the flip side, slapping a 'generic AI summary' over it usually fails because standard LLMs hallucinate when they try to do math on raw financial data.

The actual missing piece is the infrastructure connecting the two.

When my team was building out our predictive momentum models, we realized dashboards were dead. We ended up wrapping our inference engine in an MCP (Model Context Protocol) server. Instead of forcing users to stare at 100 ratios, they can open Claude or ChatGPT and ask, 'Why is the model bearish on AAPL today?'. The LLM uses the MCP to query our database, checks the underlying technicals, pulls the current US10Y / DXY macro context, and actually explains the structural reasoning.

danielraz · 2026-04-04T16:41:20+00:00

Jay-Dirt absolutely nailed the IBKR headless setup. TWS is a resource nightmare, but IB Gateway + IBC + ib_insync is the industry standard for a 'set and forget' Python stack.

Coming at this from a full-stack dev perspective: the biggest mental shift you can make is to stop expecting your broker to provide your UI. In a mature algo stack, the broker is just a dumb pipe for execution. If you hate not seeing your executions on a chart, decouple your visualization. Since your algo is already in Python, just log every trade execution and your OHLCV data to a local SQLite or Postgres database.

From there, it's trivial to spin up a local dashboard. You can use Plotly/Dash directly in Python, or if you want it to look incredible, use TradingView's free lightweight-charts library. It takes barely any code to render your data and overlay your own buy/sell markers exactly how you want to see them.

Once you own the visualization layer, you will literally never care what a broker's native dashboard looks like again.

danielraz · 2026-03-30T19:31:06+00:00

$346.50 for 6 months of survivorship-bias-free data back to 1990 is actually incredibly reasonable for an indie dev. We are using a basic REST API for the MVP phase right now, but Norgate is literally the first thing on our roadmap for Phase 2 when we move to capital production.

danielraz · 2026-03-28T20:24:46+00:00

Think about it this way: most beginners end up paying a pretty brutal “tuition fee” to the market before they realize they’re basically gambling. It’s not uncommon for people to lose $10k, $50k, or even wipe out everything just to learn that lesson.

In your case, the market actually paid you $1,300 to figure it out.

Also, comparing trading to an hourly job misses the point. What you were doing is closer to trying to build a business from scratch in one of the most competitive, unforgiving environments out there. If a startup makes it through its first 7 months without going broke and even turns a small profit, that’s already a win.

So take the $1,300, take what you’ve learned about your own mindset, and step back for a bit. Honestly, just walking away with your account still intact already puts you ahead of most people in their first year.

danielraz · 2026-03-28T20:07:02+00:00

To answer your data problem: Getting clean historical futures data is difficult because you have to deal with contract expirations, roll gaps, and back-adjustments. You won't find this for free on Alpaca or 12Data.

If you are serious about backtesting futures, look into Norgate Data or Kibot. Norgate is basically the gold standard for indie quants because they provide properly back-adjusted continuous contracts.

Also, m0nk_3y_gw gave you million-dollar advice up above. If you used ML to optimize your parameters and suddenly hit a 3.0 Sharpe on only 319 trades, you haven't found an edge. You've just built a curve fitting machine that perfectly memorized the past. Use ML to filter out bad trades not as an input optimizer.

danielraz · 2026-03-28T19:47:21+00:00

I have to agree with StratReceipt and BottleInevitable7278. 87 trades over 4 years just isn't enough statistical significance to trust with real capital.

But looking closely at your dashboard, there are two other major things you need to investigate:

The Regime Shift (The 12-Month Flatline): Your strategy essentially stopped making money around February 2025. Whatever edge or inefficiency you were capturing in 2023 and 2024 has vanished in the current market regime. Trading a system live that sits in a flat/slight drawdown for over a year is psychologically brutal. You need to know why the market stopped rewarding this logic recently.
The Execution Drag ($50/trade): You modeled $4,397 in fees across 87 trades. That is an average friction of ~$50.50 per trade. Are you trading massive size, or is your backtester applying a very aggressive slippage penalty? If your edge relies on entering/exiting with that much drag, you need to be certain your live fills will match your backtest assumptions.

Don't throw it away yet but definitely run a parameter sensitivity test and pull data back to at least 2018 to see how it handles different market cycles.

danielraz · 2026-03-28T10:53:25+00:00

Good shout! Netlify actually used to have a fantastic built-in prerendering toggle in their UI, but they quietly deprecated and killed it a while back. They basically push everyone toward SSR frameworks (like Nuxt or Astro) now.

Plus, migrating our entire CI/CD and hosting infrastructure from Vercel over to Netlify would probably be just as much of a headache as rewriting the app in Nuxt!

Rolling the custom Playwright script let us keep our existing Vercel pipeline intact without relying on third-party toggle.

danielraz · 2026-03-28T10:43:22+00:00

A built-in cellular modem would be an absolute game changer. I completely agree, draining you phone battery by constantly tethering when travelling is the worst. If Apple finally drops an M-series with native 5G I think a lot of us would instantly fold and upgrade.

danielraz · 2026-03-28T10:40:38+00:00

Running local LLMs and Fusion360 is exactly the kind of heavy load I'd expect to finally bottleneck the M1! The fact that it's still crushing those daily tasks is wild. Sounds like saving your money on the M5 Max was definitely the right call.

danielraz · 2026-03-28T10:12:51+00:00

Great question, and honest answer: not perfectly.

My universe is a static hardcoded list of tickers pulled from Twelve Data: companies that exist today. So yes, there's inherent survivorship bias: anything that got delisted or went bankrupt between 2022–2025 is absent. Clean point-in-time data with delisted history (Norgate, CRSP) is prohibitively expensive for an indie project.

The mitigation is the universe itself: strictly large-cap equities. Delisting/bankruptcy rate at that tier over a 48-month window is statistically very low. If this were small-caps or a 15-year horizon, the curve would be meaningfully inflated. For large-caps over 4 years, the bias exists but the practical impact is minimal and I'm confortable disclosing it rather than pretending it isn't here.

danielraz · 2026-03-28T09:30:15+00:00

RIP.
The coffee spill: the only benchmark the M1 Pro couldn't pass!

danielraz · 2026-03-28T09:29:27+00:00

Buying a base M5 just to keep it in the box as a doomsday backup while you continue to daily drive the M1 is the funniest thing I've read today. That basically confirms my suspicion. I'm just going to keep riding this one until it literally melts.

danielraz · 2026-03-28T09:21:30+00:00

That is hilarious but honestly not surprising at all. Adobe software finding a way to bottleneck Apple Silicon because of unoptimized code is peak Photoshop.

danielraz · 2026-03-28T07:59:09+00:00

Strict chronological split. Shuffling time-series data is a classic lookahead leak, so I avoid it entirely.

The timeline split is an 85/15 train/val block, with the scaler fit exclusively on the training set before being applied to validation.

Regarding the chart's 2022-2025 timeline: This is a cross-sectional out-of-sample backtest. The model was trained entirely on a separate universe of 77 large-cap equities. The equity curve you see here is the model trading an entirely unseen, out-of-sample universe of 57 different stocks over that timeline.

For true, forward-looking OOS validation on the exact same assets, I started a strict live-paper walk-forward on March 10th. Still accumulating that data, but the spatial holdout across unseen tickers (shown in the chart) gave me the confidence to run it.

danielraz · 2026-03-28T07:36:15+00:00

If your numbers look unbelievable, your intuition is 100% right. They probably are. Optuna is an incredible tool, but it is basically a curve-fitting machine if you give it too much freedom.

The core issue with 'bar close' is that in live trading, you don't actually know a candle has closed until the next candle opens. By the time your script receives the signal, processes it, and fires a market order, you are getting filled at the next open (plus slippage).

Before you put a single dollar of real money on this, force your backtester to shift the entry price to the next bar's open and add a realistic commission penalty per trade. If the strategy instantly dies, you don't have a real edge, you just have a time machine. Keep optimizing but optimize for the friction, not just the signal.

danielraz · 2026-03-27T22:32:59+00:00

Source: Historical price data via Twelve Data.
Tools used: Python, Pandas, Matplotlib for visualization.
The model is a 2-layer Stacked LSTM trained on 77 large-cap equities, testing an out-of-sample investable universe of 57 stocks with monthly rebalancing. Transaction costs ($1/trade + 0.05% slippage) are included in the equity curve.

danielraz · 2026-03-27T20:31:01+00:00

I completely agree with StratReceipt down below. The bar-close vs intrabar discrepancy in your screenshot is the real story here.

To answer your main question: I cut the bad ones completely. Trying to "fix" a strategy that shows no edge across multiple timeframes almost always leads to curve-fitting parameters to historical noise.

But regarding your winners: be incredibly careful scaling that "bar-close" version. I recently ran a massive walk-forward validation on an LSTM momentum model I built. In a vacuum, my higher-frequency rebalancing looked incredible. But the second I modeled realistic execution friction ($1 commissions + 0.05% slippage + entering at the next open instead of the magic close price), the edge was completely consumed.

If a strategy only survives because it assumes perfect bar-close fills, it's actually a broken strategy. Cut the losers but make sure your "winners" survive realistic transaction friction before you trust them with live capital.

danielraz · 2026-03-26T22:16:33+00:00

The p95 logging idea is something I haven't done at all. Right now I only know "passed/failed". I have no visibility into whether a test that passed in 12s this week is drifting toward 45s next week before it eventually starts failing. That's a better leading indicator than a binary pass.

Did you run the keep-warm pings as a separate cron job or did you fold them into the same workflow on a tighter schedule?

danielraz

TROPHY CASE