// web3 · ai · backend automation
Everything fails.
Mine gets back up.
I design, build and operate production systems — on-chain trading platforms, automation bots, AI pipelines, and the backends and internal CRM behind them. They run unattended, so half the code is reconnects, retries and reconciliation.
Self-taught, production-tested.
I'm self-taught, and almost everything I know comes from building systems that had to work in production — then fixing the parts that only break once real users are hitting them. A fair share of those failures traced back to bugs I'd shipped myself; that's where the recovery habit comes from.
Trading platforms, bots, AI integrations, a CRM product — the range is wide, but the job is the same: software a business leans on daily, where somebody notices within minutes when it stops. I don't just ship these systems; I operate them, and that changes how you build them. It also has a side effect: bug reports don't enter a queue — when something breaks in production, the alert reaches me, not a backlog, and the fix usually ships the same day.
I'd be building this stuff anyway — the two open-source tools in the grid below started as weekend projects for my own use, before anyone asked for them.
The projects below are the short version — the code is the long one.
- rolefull-stack / systems engineer
- focusweb3 · ai · automation
- moderemote · B2B preferred
- codeTypeScript · Python · Swift
- status● available for work
Running in production
Systems I designed and shipped end to end. Where the code is private or client-owned, the card links to a sanitized architecture writeup; open-source projects link straight to the repo.
Multi-Protocol Prediction-Market Aggregator
A production trading terminal that unifies multiple on-chain outcome-market venues — including Myriad, Limitless and Hyperliquid — into one UI, with a Polymarket-driven copy-trading engine, cross-chain deposits and portfolio aggregation across protocols. Built end-to-end in Next.js 16 / React 19 across four signing models (EOA, Account Kit AA, EIP-1271, agent-wallet). Client code is under NDA; a sanitized architecture writeup is linked below.
EcomPilot CRM
Internal CRM + ops platform I designed, built and run for an e-commerce services business selling on Allegro and other marketplaces. FastAPI + React 19 over PostgreSQL — sales pipeline, tasks, calendar, finance and a WeasyPrint offer generator — fed by six integration sources (Meta Lead Ads, Fathom, Google Calendar, HubSpot, WhatsApp, email). A 30-tool MCP server exposes the live app to Claude for read and write. In production, login-gated, source private.
Crypto Trading Analytics Bot
Telegram bot for real-time crypto signal monitoring — per-user filters, multiplier tracking, subscriptions and Solana / NOWPayments billing. A 24/7 fintech system on a Redis hot path with async dual-write to PostgreSQL.
JobSniper — AI Job Monitor
Scans five job boards, parses your CV, and uses GPT-4o-mini to score each offer 0–100% with reasoning. High matches trigger an instant Telegram alert. Full observability with Prometheus + Grafana and a circuit breaker around the LLM.
Claude Monitor Bar
Native macOS menu-bar app that surfaces Claude Code API rate limits in real time — 5h / 7d / Sonnet windows — with a color-coded progress ring, usage-history charts, plan recommendations and self-installing auto-updates.
What I build with
pkg:fullstack
Type-safe apps end to end — App Router frontends and async services that handle thousands of operations in parallel without blocking.
pkg:web3
EVM smart wallets, account abstraction (EIP-7702), on-chain trading, cross-chain bridges and crypto payments.
pkg:data
Dual-write architecture — Redis for the hot path, PostgreSQL for persistence and analytics, typed migrations with Drizzle.
pkg:ai & infra
LLM integrations with circuit breakers, containerized deploys, monitoring, graceful shutdown and auto-recovery.
Engineering principles
Transparency before sales
If your idea doesn't make technical sense or there's a simpler path, I'll tell you. I'd rather lose a contract than watch a client burn budget on something that won't work.
Understand, then build
Before I write code I need to understand the problem — what can break and how to handle it before it becomes an incident.
Battle-tested
What happens when the server crashes? When the API errors? When data is incomplete? I ask these before deployment, not after a client call.
System, not script
A script needs you to run it. A system runs for you — with monitoring, logs, alerts and documentation. I build the latter.
Got a problem to solve?
You don't need a finished spec. Describe the problem — we'll talk about whether automation makes sense, what it might cost, and how long it would realistically take.
If it's outside what I do well, I'll say so on the first call and point you somewhere better.