DEV Community: Bot and Bull

The One Flag That Kept My Trading Bot From Spending Real Money Too Early

Bot and Bull — Wed, 14 Oct 2026 14:00:00 +0000

When I set up my first trading bot, the scariest moment wasn't the code. It was the first time the code could place a real order.

So before any buying logic existed, every order went through one function with one switch in front of it:

import os

DRY_RUN = os.environ.get("DRY_RUN", "true").lower() == "true"

def place_order(client, symbol, qty, side):
    if DRY_RUN:
        print(f"[DRY RUN] would {side} {qty} {symbol}")
        return None
    return client.submit_order(symbol=symbol, qty=qty, side=side)

Three things I like about this:

It defaults to safe. If I forget to set the variable, nothing real happens.
There's one door. No other part of the bot talks to the broker's order endpoint directly, so there's one place to check.
Keys and switches live in the environment, not the code. Nothing sensitive ends up in a repo.

I ran in dry-run mode, then on a paper account, for weeks before flipping it. Boring was the goal.

That's one step of nine. I wrote up the full setup, from an empty account to a bot that runs on a schedule, here: How to set up a trading bot from scratch, step by step.

If you're starting from zero like I did, the story of how it began is in Part 1 of the build.

Educational only, not financial advice.

I Couldn't Code, So I Made AI My Pair Programmer and Built a Trading Bot

Bot and Bull — Wed, 07 Oct 2026 18:15:35 +0000

A couple of years ago I could not have told you what an API was. Today a bot I built runs on a small cloud server every evening, checks the market against rules I wrote, and flags what's worth a look. I still don't have a coding background. What I have is a workflow.

Plain English in, working code out

I never sat down to "learn to code" first. I described what I wanted in plain English, got code back from an AI, ran it, watched it break, and pasted the error back in. Repeat until it works. Then make it explain every line until I understand why it works.

The first real version looked roughly like this:

# What I asked for, in plain English:
# "Every evening, check my watchlist. If a stock fits my rules,
#  flag it. Never buy anything without asking me first."

def evening_run(watchlist):
    for symbol in watchlist:
        bars = get_daily_bars(symbol)
        if fits_my_rules(bars):
            flag_for_review(symbol)  # a human makes the final call

Nothing clever. Watch, decide with rules, act. That's the whole shape of a trading bot. Everything else is detail on top of those three moves.

What the AI didn't do for me

It wrote code fast. It did not tell me what to build, which assumptions were wrong, or when "it runs" wasn't the same as "it's right." That part was on me, and it's where most of the real lessons came from.

What I'd tell another beginner

Build the guardrails before the exciting parts.
Make the AI explain its code. If you can't read it, you can't debug it.
Keep the stack lean: a broker with an API, a small server, Python.
Start before you feel ready. The mental block is harder than the building.

I wrote the full story, including the fears that almost stopped me and the mistakes I'd skip, in How I Built an Automated Trading Bot With No Coding Background. If you want the actual stack, the trading bot tools I recommend page has it.

This is education, not financial advice.

The Bug That Passed Every Test and Still Lost Me Money

Bot and Bull — Sun, 20 Sep 2026 04:46:31 +0000

I am building an automated stock trading bot in public. I am not a developer by trade, so I lean hard on tests to feel safe shipping. Which is exactly why this one stung: a bug that passed every single test I had, and still lost me money the moment it touched the real market.

The suite was green, so I trusted it

Every test passed. I deployed. That green checkmark felt like permission.

The problem was hiding in plain sight: my tests fed the bot clean, well behaved data that I made up myself. The code did exactly what I told it to do. My tests just never told it to handle the real world.

What actually happened

The bot runs a routine at the end of the trading day. My tests used fixed timestamps, so timing itself was never really under test.

Live, the server ran on UTC while the market runs on Eastern time. The end of day routine fired before the session's data was actually final, so the bot made decisions on half baked numbers.

# what I had (naive)
now = datetime.now()          # server's timezone, not the market's
if now.hour >= 16:            # "after close"... in the wrong timezone
    run_end_of_day()

It looked correct. It passed. It was wrong about the one thing that mattered: which clock the market actually runs on.

Why the tests missed it

Unit tests prove your code does what you told it to do. They do not prove your assumptions about the outside world are right.

I had tested the logic and skipped the environment. Market hours, timezones, holidays, missing data, none of it was in my tests, because I was hand feeding the inputs. A green suite told me my code was consistent. It said nothing about whether it was correct.

What I changed

Tests now use messy, realistic data: wrong timezones, missing bars, holidays, odd prices.
Anything time related is explicit and timezone aware. No more datetime.now() and a hopeful guess.
New rule: nothing goes live until it has survived small, real stakes, not just the test suite.

The takeaway

A green test suite means your code is consistent, not that it is correct. For anything that touches the real world, and money most of all, test the world, not just the function.

I am documenting this whole build in public, including the tools I recommend to run it and the bruises like this one. If you want to follow along, everything lives at Bot and Bull.

This is education, not financial advice.