Computer engineer · backend & automation · open to remote

Gean C. Perez Gil — backend systems, automation, and software you can verify.

Case studies with architecture diagrams, test counts, and screenshots—personal and academic work labeled honestly.

Projects GitHub Email

Projects

Three systems with evidence on this page. The trading automation case includes release engineering and CI as a layer of the same platform—not a separate product.

Project 01

Trading Automation Platform

A Python platform for researching, validating, deploying, and supervising automated trading strategies.

Sole engineer on a private repo: architecture, runners, supervisor, desk, and release pipeline.

Python · Linux · pytest · Make · GitHub Actions

Screenshots: quant desk, feed health panel, Telegram session journal

Case studyGitHub

Project 02

Andrä Eyewear — B2B wholesale

Personal B2B commerce system designed around a wholesale eyewear workflow—PDF catalogs and manual reconciliation replaced by one deployed stack.

Personal product-engineering project: I own the concept, codebase, and deployment—not a client engagement.

Rust · Axum · Postgres · Redis · Stripe · PayPal · Vite · Three.js

Live demo via Cloudflare tunnel (URL in Live demo button—rotates when tunnel restarts)

Case studyLive demoGitHub

Project 03

ContentCat — Academic Capstone (2022)

Academic capstone (2022): Flask app that fetches tweets and classifies political leaning with a multilingual BERT model.

Team capstone (UPR)—my focus was shipping an end-to-end demo, not production ML today.

Python · Flask · TensorFlow · BERT · Twitter API

Faculty poster and UI screenshots on this site

Case study

Case 01

Trading Automation Platform

A Python platform for researching, validating, deploying, and supervising automated trading strategies.

Python · Linux · pytest · Make · GitHub Actions

What it is

A Python platform for researching, validating, deploying, and supervising automated trading strategies.

Scope. Sole engineer on a private repo: architecture, runners, supervisor, desk, and release pipeline.

Architecture

One platform from research through supervised live sessions—not separate repos per layer.

Research / backtest
Validation gates
Deployment registry
Live runners
Risk / execution
Broker
Monitoring / journal

Problem

When several automated strategies run at market open, a crashed process, stale market data, or code that skipped validation can fail before a human notices.

What I built

Independent live runner processes, a supervisor that restarts them from a deploy registry, risk and feed guards, a read-only operator desk, and release checks (make ci) on the same repository.

Result / scope

Operators can see runner health, feed freshness, and a broker-aligned journal before treating the session as safe to run.

Engineering decisions

  • Separate research promotion from live arming—only registry entries that passed validation may run armed
  • Supervisor logic in testable Python without shelling to pgrep in unit tests
  • Operator UI is read-only so monitoring cannot place orders
  • CI ship gate (469 tests) is a subset of full regression (2133 tests)—see release engineering section below

Verification

  • 469 tests in the CI-critical suite (make ci / CI_TESTS): runner imports, on-bar guards, supervisor, feed monitor, sizing, and session rules—ship gate on every push.
  • 2,133 tests in the full validation suite (make test): adds research parity, lookahead, and promotion paths before strategy deploy—not run on every commit.
  • Backtest and historical metrics are evidence for arming decisions, not a promise of future PnL.

Ship path: make ci every push. Promotion/deploy: make test and make deploy when changing strategies or live config.

  • Runner import smoke, static on_bar guards, live loop unit tests (no live orders in tests)
  • Supervisor, feed monitor, sizing, Topstep session rules in CI slice
  • Lookahead / parity suites in full make test before research promotion

Reliability & controls

  • Feed freshness and BLIND state when runners are armed but tape is stale
  • Kill switch file and session risk gates shared across runners
  • Static tests on runner bar handlers after a production incident (stale bar / EOD window)
  • make ci identical locally and in GitHub Actions

Engineering deep dive — Release engineering

Same trading-bot repository as Case 01 — not a separate product.

One Make target runs locally and in GitHub Actions so live runner code cannot ship without lint, lockfile, CI_TESTS, and pip-audit.

Architecture

git push
pre-commit (secrets, ruff, sync checks)
pre-push → make ci
verify-lock → lint → test-fast (CI_TESTS) → pip-audit
GitHub Actions (same make ci target)

Reliability & controls

  • CI_TESTS file list in Makefile must match .github/workflows/ci.yml—documented drift failure
  • Hooks copied from scripts/hooks/ via make hooks
  • test-fast covers deploy imports, on-bar guards, supervisor, feed, guards/sizing—not full research catalog

Verification

Screenshots from local make ci; same trading-bot repo as Case 01.

  • verify-lock / pip-audit on requirements.in
  • ruff on scripts/, modelo_a/, modelo_b/
  • test-fast — 25 files, 469 tests
  • Excluded from slice: many test_orb_*_lookahead and verdict placebo tests (make test)
  • Local make ci output
  • Pytest summary for CI slice
Local CI green (make ci)
Gate run before code leaves my machine Open full size
Production test slice (pytest tail)
469 checks in CI_TESTS Open full size
Deep dive — modules, files, and sources (engineers)

Technical scope

Deep dive names: modelo_a/modelo_b (research), verdict_gate.py and TRUSTED ledger (promotion criteria), combine_deploy.json (what may run live), live_orb* / live_sb runners, no_hedge_gate.json, supervisor_core.py, dashboard_app.py. Historical backtest results are validation evidence for deployment decisions—not guarantees of future PnL.

Implementation (modules & files)

  1. verdict_gate → prereg JSON → combine_deploy.json arming rules
  2. scripts/live_* runners + live_guards + broker adapter
  3. supervisor.py / supervisor_core.py + dashboard_app.py (/quant)
  4. Makefile CI_TESTS + hooks; see embedded release engineering section

GitHub (trading-bot — private)

Case 02

Andrä Eyewear — B2B wholesale

Personal B2B commerce system designed around a wholesale eyewear workflow—PDF catalogs and manual reconciliation replaced by one deployed stack.

Rust · Axum · Postgres · Redis · Stripe · PayPal · Vite · Three.js

What it is

Personal B2B commerce system designed around a wholesale eyewear workflow—PDF catalogs and manual reconciliation replaced by one deployed stack.

Scope. Personal product-engineering project: I own the concept, codebase, and deployment—not a client engagement.

Live demo

Problem

In a wholesale eyewear workflow without integrated software, ordering still depends on PDF catalogs, manual payment reconciliation, and warehouse picks that do not match paid orders.

Architecture

Storefront Vite · Three.js vitrina
B2B portal /dashboard buyer UI
Orders Server-side cart · Postgres
Payments Stripe · PayPal webhooks
Inventory Reserve → sell on pay
Warehouse QR scan · FIFO lots
CRM / rep workflow Rep attribution

What I built

Logged-in B2B portal with server-side cart, Stripe/PayPal webhooks with deduplication, inventory reserve/commit, and QR-assisted FIFO picks—plus a 3D storefront as the public layer.

Result / scope

One software path from catalog to paid order to warehouse pick, without side spreadsheets.

Backend

  • Single Axum binary serves vitrina, /dashboard B2B, /ops, /rep CRM, and admin APIs
  • Domain-split routers: catalog, cart, payment, inventory, rep_crm

Commerce

  • Server-side cart and orders in Postgres
  • Stripe/PayPal checkout plus webhooks with deduplication before inventory commit

Inventory

  • Reserve → commit / release via inventory_ops.rs
  • Warehouse loop: POST /api/inventory/scan with signed QR payloads and FIFO lots

Security

  • Argon2 password hashing and CSRF on mutating routes
  • Redis-backed sessions required in production

Deployment

  • cargo build --release, npm run build:storefront, Nginx per docs/DEPLOY_ANDRA.md
  • Live demo exposed via Cloudflare tunnel (URL rotates when tunnel restarts)

Engineering decisions

  • Single Axum binary serves vitrina, portal, ops, and APIs—one deployment unit
  • Server-side cart and orders; 3D is presentation, not the source of truth
  • Webhook deduplication before inventory commit
  • Redis sessions required in production; Argon2 + CSRF on mutating routes

Verification

CI: cargo test, storefront build, verify-antra-ci.sh (health, security, order-flow smoke).

Reliability & controls

  • payment_deduplication.rs + inventory_ops.rs (reserve / commit / release)
  • inventory_scan_routes + signed QR payloads
  • Domain-split Axum routers (catalog, cart, payment, inventory, rep_crm)
  • verify-antra-ci.sh smoke after cargo test + storefront build

Personal B2B commerce system / prototype — engineered end-to-end by me

Live stack is exposed via Cloudflare tunnel (not antra.pages.dev static host). andraeyewear.pr is not wired yet. Legacy LaunchPath templates under templates/_legacy/ are not served.

Deep dive — modules, files, and sources (engineers)

Technical scope

Single antra binary serves vitrina, /dashboard B2B, /ops, /rep CRM, and admin APIs. 3D vitrina is presentation layer; commerce logic is server-side. Redis sessions in production; Argon2 + CSRF on mutating routes.

Implementation (modules & files)

  1. Axum mounts HTML shells and API routers per domain
  2. Storefront built to static assets; Rust serves templates
  3. Stripe/PayPal create + webhooks update paid state
  4. POST /api/inventory/scan for FIFO warehouse loop
  5. Deploy: cargo build --release, npm run build:storefront, Nginx—docs/DEPLOY_ANDRA.md

Live demo · GitHub (antra — private)

Case 03 · Academic

ContentCat — Academic Capstone (2022)

Academic capstone (2022): Flask app that fetches tweets and classifies political leaning with a multilingual BERT model.

Python · Flask · TensorFlow · BERT · Twitter API

Academic capstone — 2022 (expand for poster & UI)

What it is

Academic capstone (2022): Flask app that fetches tweets and classifies political leaning with a multilingual BERT model.

Scope. Team capstone (UPR)—my focus was shipping an end-to-end demo, not production ML today.

Problem

Faculty needed proof of end-to-end ML delivery beyond a training notebook.

Architecture

Web form
Tweepy fetch
Tokenizer + SavedModel inference
Result UI

What I built

Reviewer enters a Twitter handle and sees classified tweets in the browser, with poster and AWS deployment manual as deliverables.

Result / scope

Reviewer enters a Twitter handle and sees classified tweets in the browser, with poster and AWS deployment manual as deliverables.

Verification

No repo in workspace—screenshots and poster only.

Reliability & controls

  • Server-side inference path (not client-only ML)
  • Documented EC2 + Docker deploy in team manual
  • Archived poster and UI captures only—no maintained repo in this workspace

Academic capstone · 2022

Deep dive — modules, files, and sources (engineers)

Implementation (modules & files)

  1. Flask: form → Tweepy → Hugging Face tokenizer → TensorFlow inference → template
  2. Team poster, SRS, AWS manual pages preserved as images
  3. Dated assumptions (Twitter API 2022)—academic history only

About

Gean C. Perez Gil

I’m a Computer Engineer focused on backend systems, automation, and software engineering.

I like building systems around real problems and understanding how they work end to end — from business logic and data to testing, deployment, reliability, and failure handling.

My recent work includes a trading automation platform, a personal B2B commerce system built with Rust and PostgreSQL, and an academic ML/NLP project.

This portfolio documents the architecture, engineering decisions, and technical evidence behind each system.

Contact

Hiring for backend, automation, or software engineering?

Email with the role and stack. Repo access where applicable, and live walkthroughs on request.