Data infrastructure for trading teams

Deployed on your infrastructure in about three weeks

• Multi-venue capture of order books, trades, funding, and options surfaces, running unattended on your box under your keys.
• Retry ladders that actually engage: the dominant silent failure in capture pipelines is the error class the retry logic never catches. Mine are pinned by tests that assert attempt counts.
• A daily completeness scorecard: rows captured versus rows expected, per venue, every miss classified as excused or not. You know what you have and what you lost, without asking.
• Alerting into your chat, a written runbook, and a full test suite. The handover is designed so you do not need me afterward.

Good fit teams burning quant time on data plumbing, or trading venues nobody has libraries for

One week, written report

• Gap analysis of your recorded data against venue truth: what you believe you captured versus what the venue says happened.
• Failure-mode review of retries, timeouts, and error handling. The bugs I hunt are the quiet ones: read timeouts that bypass retry ladders, partial responses recorded as complete, checks that report green whether or not they can see anything.
• Monitoring blind-spot review: what breaks silently today, and what it would take for you to find out the same day instead of at research time.
• Deliverable is a prioritized written report. Implementing the fixes is a separate, optional engagement.

Good fit teams with an existing pipeline and a nagging feeling about it

Monthly, cancel anytime

• Monitoring and incident response for your data stack: I watch the scorecards, chase the gaps, and keep the alerting honest.
• Small fixes, venue additions, and capacity widenings included within scope.
• Written incident notes on anything that fired: what happened, what the evidence was, what changed so it does not recur.

Good fit teams who want the capture stack maintained without hiring for it

The problem: trading research dies without clean historical data, and venue APIs eat it silently: read timeouts that skip retry logic, rate limits, partial books returned as full ones.

• Unattended capture service recording per-minute order books across 33 markets on three derivatives venues, plus hourly options surfaces from a fourth. Standard-library Python only: no dependency surface to rot.
• 78 API fetches per minute sustained on a 2-CPU box; a full capture tick completes in about 7 seconds against a 55 second budget.
• Publishes its own daily completeness scorecard, captured versus expected per venue, misses classified. Stable configurations run days at 99.9 to 100 percent per venue, and every gap below that is accounted for.
• Retry behavior pinned by 48 tests asserting attempt counts, written after finding a failure mode where read timeouts bypassed the retry ladder entirely and every timeout aborted on attempt one.
• Capacity widened three times in production at a cost of at most one lost capture tick per change.

Stack Python (stdlib only), SQLite, systemd, chat alerting

The problem: headline macro numbers hide where US consumer stress shows up first, and the underlying series publish months late, at different lags, in ways that silently break naive joins.

• Composite index over dozens of federal economic series and corporate regulatory filings, with publication-lag-aware windowing so a series that publishes seven months behind still lands in the right comparison window.
• Nearly 400 automated tests. Every scoring change ships with proof of whether the composite moved, byte-diffed against the live database before deploy.
• The test suite has caught real data pathologies: an aggregate series double-counting its scored components, tie-breaking drift in date matching, and silent row drops when one series publishes ahead of the series that anchors it.

Stack Python, Flask, SQLite, FRED and EDGAR APIs

The problem: live trading systems fail expensively and quietly: an order the API swears was rejected but actually filled, a config edit that never applies, a record priced off the wrong data window.

• Execution and monitoring systems in Rust and Python, run live in production. Every deploy is verified against the running process, not assumed from the install step.
• 225 tests on the execution engine, and every fix ships with a test proven to fail on the pre-fix code.
• Incidents are reconciled against venue truth rather than local logs, and record repairs are idempotent, backup-first, and refuse any record they cannot reconstruct from raw fills.
• Performance details stay private by design. What I sell is the reliability discipline, and it is documented in the runbooks and rollback scripts that accompany every change.

Stack Rust, Python, systemd, VPS operations

The problem: most backtested strategies are curve-fit, and the expensive failure is shipping one.

• Optimization pipeline built to kill strategies before they cost money: hyperparameter search, walk-forward validation, and multi-seed robustness testing baked in.
• Two strategy families across six pair and timeframe combinations: full-sample metrics said ship, five-seed walk-forward said noise. On the best-looking configuration the seed range ran from a Sharpe of -2.95 to +1.14 around a negative mean. Both families were correctly rejected.
• The pipeline is the durable asset. A framework that reliably says no is worth more than any single strategy that looked good once.

Stack Python, Optuna, pandas