Krzysztof Rzepka

Platform Engineering
Container-to-Serverless Migration — retired App Runner and ECR; the entire runtime is now Lambda + DynamoDB + EventBridge inside the AWS free tier.
Event-Driven Execution — EventBridge Scheduler invokes the trading Lambda once per daily bar rather than holding a polling loop open, so compute is billed in seconds per day.
Idempotent by Bar — each run is keyed to the market bar it processes, so a retry, duplicate schedule fire or manual invoke cannot double-trade.
Silence Is Alarmed, Not Just Failure — a scheduled function that stops being scheduled produces no error to catch, so each of the three bots carries a no-invocation alarm alongside its error and dead-letter alarms: nine in total.
Blast Radius Drawn Per Bot — three schedules, three functions, three IAM roles, three dead-letter queues. They share a table and an SNS topic; everything else is separate, down to the deployment artefact.
Execution Heartbeat — the live strategy trades ~1.7 round-trips a year, so a shadow Lambda runs a full round-trip against a demo matching engine daily. The first real order is never the first test.
Public Read-Only Status — a separate status Lambda behind CloudFront serves the live ledger as HTML or JSON, cached 30s at the edge.
Auditable State — one on-demand DynamoDB table holds portfolio state plus an append-only decision ledger, partitioned per channel.
Backtest = Live Parity — the live bot imports the same signal and cost code the backtester runs, so validated behaviour cannot silently drift.

Tech Stack
AWS: Lambda (Function URLs), EventBridge Scheduler, DynamoDB (on-demand), CloudFront, SQS (DLQ), SNS, CloudWatch (logs, alarms), Route 53, ACM
IaC / CI: Terraform, GitHub Actions (OIDC → AWS), gitleaks secret scanning
Backend: Python 3.11, pandas/numpy, boto3; TensorFlow and LightGBM in the offline research pipeline
Validation: event-driven backtester with next-bar-open execution, fees and slippage, plus walk-forward out-of-sample testing

Engineering
Publishes Its Own Negative Result — every method is scored out of sample against the no-skill baseline with Monte-Carlo p-values and bootstrap intervals. None beats random picks, and the dashboard says so on its face.
Corrects Itself in Public — an earlier headline claimed 96% of roll-down draws were profitable. Re-priced against each draw's own measured ticket sales it became 27 of 65, median EV −£0.14 — and the correction stayed in the README.
Exact Probabilities, Asserted — hypergeometric odds for every tier (jackpot 1 in 45,057,474) are pinned by tests rather than assumed, and fixed prizes are re-derived from official data on each run.
Stresses the Fragile Input — ticket sales dominate expected value on a roll-down, so the verdict is reported across the sales range; a draw that only clears on the central estimate is not treated as an opportunity.
Absence Is the Failure Mode — a collector that stops collecting raises no error, so a separate watchdog workflow checks that each draw actually arrived.
The Clock, Not the Calendar — sales close 19:30 UK time while the collector runs on UTC, so the target draw is resolved with an explicit timezone and both the evening run and morning retry agree.
Deterministic Recommendations — suggested lines are seeded from the draw date, so a retry proposes the same portfolio rather than a second, different one.
No Infrastructure for Its Own Sake — two draws a week needs no server, queue or database. A scheduled workflow fetches, recalculates and commits; git provides history, durability and audit for free.

Tech Stack
Core: Python 3.11, NumPy, pandas, exact hypergeometric EV model, greedy portfolio selection with diversity constraints
Automation: GitHub Actions (scheduled collection, retry and watchdog), launchd for the post-draw routine, SMTP alerts only on a positive-EV verdict
Validation: walk-forward backtest with significance testing, plus a settled real-money ROI ledger
Data: full UK Lotto history since 1994, per-draw sales, popularity weights calibrated on 1,126 draws

Platform Engineering
Remote State, Locked — Terraform keeps state in S3 with a DynamoDB lock table, so two applies cannot run over each other and the state does not live on one machine.
Two Markets Separated at the Root — each domain has its own hosted zone, certificate, bucket and CloudFront distribution; they share the waitlist API and nothing else.
Waitlist Keyed on the Address — signing up twice updates the same item rather than writing a second, so a retried submission is a no-op.
On-Demand by Default — DynamoDB is billed per request, because a pre-launch list has no idle traffic and no predictable peak to provision for.
Explicit CORS — the API names five permitted origins across the two domains rather than allowing any.
Email Without a Mail Server — SES receipt rules match three addresses across both domains and write each message to S3, so the brand has working contact addresses with no mailbox to run or patch.
Right-Sized Compute — the waitlist function is Python 3.12 at 128 MB, the smallest Lambda available, because validating an address needs nothing more.
Status on Someone Else's Infrastructure — uptime is published from a separate Upptime repository driven by GitHub Actions, so the status page cannot go down with the thing it reports on.

Tech Stack
AWS: CloudFront, S3 (private, OAC), API Gateway (HTTP API), Lambda (Python 3.12), DynamoDB (on-demand), SES (inbound receipt rules), Route 53, ACM
IaC: Terraform with S3 remote state and DynamoDB state locking
Product: TypeScript, built on the open-source Postiz engine under AGPL-3.0, plus a separate mobile client
Observability: Upptime status page running on GitHub Actions