All work

Algorithmic trading research engine (paper trading only)

Market Hunter

An independent, evidence-first research engine for testing intraday strategies against historical data and a paper-trading account, built to reject strategies that don't survive honest validation.

Context
Independent · Personal project
Role
Sole developer
Period
2026
Stack
Python, alpaca-py, Parquet, pandas, pytest

The problem

Most trading backtests look good because they quietly ignore costs, use information that wasn't available yet, or test one idea until it fits. The interesting engineering problem is building a system that makes those mistakes hard.

Architecture

Research engine · PythonPreflightread-only checksMarket dataincremental · ParquetValidationgaps · freshnessStrategy researchcosts · slippagePaper accountcapital-cappedGuard layer, enforced where requests are made· paper endpoint only· live-style keys refused· non-GET to unknown hosts raises· secrets redacted from logs· engine capital cappedPaper trading only. No live trading path exists; no returns are claimed.
System overview, simplifiedPython · alpaca-py · Parquet · scroll →

Approach

The engine is built in stages, starting read-only. A preflight verifies the account is a paper account, checks the market clock, buying power, positions and quote freshness, and writes a JSON report.

Historical data is downloaded incrementally to Parquet and validated before research uses it. Strategies such as opening-range breakout, momentum and VWAP pullbacks are tested with slippage and transaction costs modeled.

Safety is enforced in code: the endpoint is fixed to the paper API, live-style keys are refused, non-read requests to unexpected hosts raise before sending, secrets are redacted from logs and engine capital is capped.

What was built

  • 01Read-only preflight with machine-readable report
  • 02Incremental historical data pipeline
  • 03Strategy evaluation with costs and slippage
  • 04Risk and position limits
  • 05Hard guards against live trading
Pythonalpaca-pyParquetpandaspytestREST APIs

The hard parts

Honest evaluation

Most strategies are expected to fail validation, and the engine reports that plainly rather than tuning until something looks good.

Guardrails as code

Safety rules are enforced where requests are made, not in documentation, so a misconfiguration fails loudly before anything is sent.

Outcome

  • Staged engine with tests at each stage
  • No performance claims, by design