DEV Community: Bot and Bull

Wide Net, Fine Mesh: Why a Bigger Watchlist Didn't Make My Trading Bot Trade More

Bot and Bull — Tue, 27 Oct 2026 16:00:00 +0000

My trading bot started with a short, hand-picked watchlist: stocks I knew and liked. When I widened it to scan a much bigger slice of the market, I braced for the bot to start trading constantly.

It didn't. Trade count barely moved. What changed was the quality of what it picked, and the reason is in how the shortlist gets built:

def shortlist(universe, rules, max_picks):
    """Wide net, fine mesh: check everything, keep only what clears every rule."""
    passed = []
    for symbol in universe:
        bars = get_daily_bars(symbol)
        if bars is None:
            continue  # missing data is a skip, not a guess
        if all(rule(bars) for rule in rules):
            passed.append((score(bars), symbol))
    passed.sort(reverse=True)
    return [symbol for _, symbol in passed[:max_picks]]  # an empty list is a valid answer

Three things this shape gets right:

The universe grows, max_picks doesn't. A bigger list means more candidates competing for the same few slots, so the bar effectively goes up, not down.
Every symbol gets the same rules. The thousandth stock is judged exactly like the first. No fatigue, no favorites.
Empty is allowed. On a weak day, nothing clears every rule and the bot does nothing. That's the feature, not a bug.

The trap is the opposite move: loosening the rules so a bigger list produces more trades. That's how you turn a wide net into a lot of mediocre positions.

The full story, including the day the bot flagged a company I'd never heard of, is here: How I expanded my trading bot's watchlist.

If you're earlier in the journey, Part 1 is how I built a trading bot with no coding background.

Educational only, not financial advice.

The Hidden Assumption My Trading Bot Made About Market Hours

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

My trading bot worked fine on stocks. Then I pointed it at crypto and found an assumption I didn't know I'd written: that the market closes.

A lot of stock logic quietly depends on that. Daily opens and closes, overnight gaps, "run this after the bell." None of it exists in a market that trades all day, every day.

The first fix was making the assumption explicit instead of buried:

from datetime import datetime, time
from zoneinfo import ZoneInfo

ET = ZoneInfo("America/New_York")
OPEN, CLOSE = time(9, 30), time(16, 0)

def market_is_open(asset_class: str, now: datetime | None = None) -> bool:
    if asset_class == "crypto":
        return True  # no bell, no weekends off
    now = now or datetime.now(ET)
    if now.weekday() >= 5:  # Saturday, Sunday
        return False
    return OPEN <= now.time() < CLOSE  # holidays need their own check

Small function, big consequences:

Every scheduled job asks this first, so stock-only logic can't accidentally run against a 24/7 market.
It forced a harder question: if crypto never closes, who's watching at 3 AM? The answer had to be the bot itself, so every protective rule became automatic.
Testing changed too. A crypto change isn't tested until it has run on paper through a full weekend, because weekends are where the differences show up.

The rest of what changed (the safety net, the signals, position sizing) is in the full write-up: How I added crypto to my trading bot.

If you're setting up your first bot, the step-by-step setup is in Part 2 of the build.

Educational only, not financial advice.

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.