Project 5 of 5
Stock Screener
Rules-driven automated decisions, and what it took to prove one of the rules actually worked.
Why this matters to a client
Why this matters to a client
Any system that acts on rules — approve or deny, escalate or hold, buy or sell — is only as good as its ability to prove the rule actually fired when it should have. A rule that's coded correctly but silently unreachable is worse than no rule at all, because everyone believes it's working. I run a real automated decision pipeline against live market data specifically because it forces that question constantly: not "did I write the rule," but "can I prove it fired."
What it does
What it does
An automated pipeline screens candidates against defined criteria, classifies them into risk tiers with different rules for each, and executes entry and exit decisions against those rules without a human in the loop. Every position is governed by explicit constraints — stop-loss thresholds, maximum hold periods, a rule against re-entering and exiting the same position on the same day.
Product screenshots
Placeholder — not a real screenshot. Stock Screener product imagery to be added before launch.
How it's built
How it's built
Technical detailFor readers who want the engineering — skip ahead if you just want the outcome.
Node.js/TypeScript backend on Railway, running on a cron schedule during market hours; PostgreSQL for state; a SvelteKit dashboard on Vercel. Market data and order execution flow through a brokerage API, configurable for paper or live trading; classification draws on external data and news sources. Trade-restriction logic — the stop-loss, hold-period, and same-day rules — lives in its own module with a dedicated test suite, separate from the decision pipeline that calls it.
The interesting decision
The interesting decision
A rule existed to block same-day round-trip trades. It shipped, and it never once blocked a trade. The bug took three passes to fully close, each one found by replaying the system's own trade history rather than trusting the code on paper. First: a timestamp was being stored as calendar-date-only in a timezone-aware column, so every position looked like it had opened the day before — the rule was structurally unreachable. Fixing that cut the violations by most of the way, not to zero. Second pass: a stale read of position state meant a same-day re-entry could inherit an old entry date from a previous, already-closed position. Fixing that closed nearly all of the rest. A third, narrower pass added an opt-in exception for orders placed one evening and filled the next morning, which look like a same-day round trip but aren't one.
None of the three fixes were declared done on the strength of the code. Each was checked against what the system had actually done in production before being called closed.
Status
Status
Running as an automated pipeline against defined rules, for my own use, not a commercial product. No user base, no track record being marketed here, and nothing on this page should be read as investment guidance — it's an example of building and hardening a rules engine, not a claim about what the rules produce.