‹ Back to the archive
// Live Project still in progress. Last updated June 2026.
June 2026

Stock Trading Bot

A self hosted trading system that runs two strategies against the live market on a paper account, with its own dashboard, risk limits, and a model that decides which strategy to trust.

pythonautomationfinancebacktestingapisself-hosted
Hero image for Stock Trading Bot

// Challenges

Building risk controls I actually trust, and figuring out how much to believe a strategy that did well last month. A backtest can look great and still lose money live, so most of the work is making the system honest with itself.

// Skills Used

Python Financial APIs Backtesting Risk management logic Databases and migrations

// Current Status

Running on a paper account with real market data. No real money is at risk. Latest work is a market regime gate and a model that shifts weight toward whichever strategy is working.

Brief

A Python trading system that runs two strategies on the US market through the Alpaca brokerage API. It runs on a paper account, so it uses real live market data and places real orders in a simulator, but no real money is at risk. That was always the point. I wanted to find out whether the thing works before it could cost me anything.

What it actually does

Two strategies at once. They look for different things, so they tend to do well at different times. Running both means the system is not betting everything on one idea being right.

A regime gate. Before it acts, the system decides whether the market is in a bull, neutral, or bear state, and that changes what it is allowed to do. A strategy that prints money in a rising market can bleed in a falling one, so it does not get to run the same way in both. This one change fixed more bad behavior than anything else I added.

A model that picks who to trust. Instead of me deciding how much weight each strategy gets, the system watches how they actually perform and shifts weight toward whichever is working. It is a bandit algorithm, the same family of math used to decide which version of a web page to show more often. It has to balance sticking with what is working against still trying the other one enough to notice when things change.

Risk limits. Position sizing, stop losses, a cap on how much can be lost in one day, and a cap on how big any single position can get. This is the layer I am most careful with, because it is the difference between a bad day and a disaster.

A dashboard. A small web interface where I can see what it holds, what it did, and why. Built with HTMX and Tailwind, so it is server rendered and there is no heavy frontend to maintain.

Its own database. Postgres with proper migrations, so I can change the schema without losing history.

Why paper trading

Because a backtest is not proof. A strategy can look excellent against past data and still fall apart live, usually because the backtest was accidentally allowed to see something it would not have known at the time. Running on paper with live data catches that. It also catches the boring failures that matter just as much, like an order that never fills, a rate limit, or a scheduled job that quietly did not run.

What I learned

Being suspicious of good results. The moment a backtest looks amazing, my first assumption now is that I made a mistake somewhere.

Bugs that hide. A trade that silently never happened does not throw an error, it just makes the numbers slightly wrong. Several of my worst bugs were missing behavior, not crashes.

Scheduling is part of the system. A trading system is a set of things that must happen at specific times, like checking the market state before the open. If the schedule is wrong the strategy does not matter.

Writing software instead of scripts. Separate pieces for signals, strategy, risk, execution, and notification, so I can change one without breaking the rest.