Independent engineer · building since 2016

Mohammad Saeedi

I design, build and run web products end to end, from polished interfaces to low-latency trading engines on Solana, Sui, EVM chains and Zcash. Speed-ups are measured, not guessed, and money paths are built to fail closed.

Explore the work Message me on Telegram (opens in a new tab)

Currently focused on: Web3 and trading systems

stack
JS · Node.js · Python · React · Kotlin
chains
SOL · SUI · EVM · ZEC
since
2016
mode
measure → build → verify
Scroll for the work

Highlights

10 years

Independent development

Building since 2016, end to end: design, code, deploy, operate.

81 ms

Median new-listing detection

Down from 320 ms: one drift-free scheduler at a 5× poll rate over warm HTTP/2.

0.35 ms

Median server-side feed-to-browser dispatch

Down from 101.5 ms in a real-time trading terminal.

28

EVM networks, one mint engine

Pre-armed 20 s early; 12 of 12 dry-run windows sent within 1 ms.

414

Automated tests in one service

The largest suite; most services also ship through SHA-256-verified staged deploys with rollback.

230,000+

Symbol-days backtested

15+ studies; out-of-sample AUC 0.61–0.67.

01About

Engineer, trader, operator

I've been building software independently since 2016, starting with web applications and browser automation. Today I design, build, deploy and run my own products end to end, owning architecture, security and 24/7 operations on self-managed Linux and Windows servers.

Most of that work sits where the web meets markets: real-time dashboards, low-latency trading engines and idempotent payment flows on Solana, Sui, EVM chains and Zcash, plus LLM-assisted trading and research tools. I trade equities, crypto, prediction markets, NFTs and collectible Telegram numbers, and since 2022 I've run @drop_radar on X (opens in a new tab) on X as a Web3 collab manager and ambassador.

Independent since
2016
On X
@drop_radar, Web3 collab manager & ambassador since 2022
Terminal-style summary: Mohammad Saeedi, independent engineer since 2016; web developer, financial trader, AI specialist, Web3 and collectibles; trades equities, crypto, prediction markets, NFTs and Telegram numbers.

How I work

  1. Measure before building

    Latency, rate limits and cost are measured first, then designed for. One host move took p50 feed latency from ~150–170 ms to 58 ms; rate-limit and cost studies, not guesses, set concurrency and caching.

  2. Fail closed with money

    If a check can't pass, nothing is signed. Pre-sign validators, simulated debit ceilings, stale-read rejection and amount and deadline caps guard the money paths in my trading systems.

  3. Exactly-once payments

    Idempotent request IDs, the payment journaled before broadcast, and an uncertain send reconciled on chain, never resent.

  4. Own it end to end

    Interface, backend, deploys, monitoring and incidents are one job: SHA-256-verified staged releases with rollback, self-healing watchdogs, runbooks and postmortems.

  5. AI-directed development

    I direct AI coding agents (e.g., Claude Code) through multi-agent build and review workflows, and keep the architecture, verification and accountability.

  6. Honest numbers

    Results are published with their qualifiers. A backtest stays a backtest, an estimate stays an estimate, and a demo account is called a demo account.

02What I do

Four disciplines, one standard

Web Developer

Interfaces that feel instant, backends that never pay twice.

Full-stack JavaScript and Node.js, from real-time trading terminals and operator consoles to OAuth-secured community apps. I care about the milliseconds between an event and the pixel that shows it, and about the correctness of everything behind it.

  • Real-time UIs over Server-Sent Events and WebSocket: median server-side feed-to-browser dispatch cut from 101.5 to 0.35 ms
  • React, vanilla JavaScript and dependency-free front ends, including a 9-tab right-to-left (Persian) dashboard
  • Node.js APIs on Express 5 and Fastify: a 70-endpoint dashboard backed by ~390 tests
  • Auth done properly: X OAuth 2.0 PKCE, hand-written OAuth 1.0a signing, exact-origin and CSRF checks on writes
  • Production delivery: nginx and Caddy TLS, sandboxed systemd services, SHA-256-verified releases with rollback
  • Dependency-free engines, down to hand-rolled PNG and LZW GIF encoders

RelatedPrediction-market terminalMessaging dashboard & AndroidAllowlist app & art engineZcash trading system

Financial Trader

Trading with instruments I build myself.

I trade equities, crypto, prediction markets, NFTs and collectible Telegram numbers, and build the screening, backtesting and pricing tools I use on most of those markets. A strategy has to survive fills, fees and an honest benchmark before I trust it.

  • Market-wide screening: ~750–1,150 symbols with 5-level order books recorded every 75–90 s
  • Backtesting at scale: 15+ studies over 230,000 symbol-days, plus order-book replay
  • Bias hunting: caught unfillable signals (~47%) and a skewed benchmark that erased an earlier +3.3% edge
  • Prediction-market modeling: settlement rule measured on 1,400 settled rounds; advisory model, log loss 0.27 on the check set
  • Risk management: deterministic risk gates, reward/risk of at least 1.8 after costs, fail-closed execution
  • Pricing ceilings with exact integer fee and royalty math

RelatedEquity screenerPrediction-market terminalLLM-assisted tradingSolana & Sui engines

AI Specialist

LLMs in the loop, deterministic code in charge.

I put language models where they are strong, reading dense multi-timeframe context, and keep hard rules wherever money is at stake. I also build with AI: I direct coding agents through multi-agent build and review workflows and own the design and verification.

  • LLM integration through strict-JSON contracts, schema-reminder retries and typed failure codes
  • Prompt engineering: ~30,000-character multi-timeframe market prompts, one decision every 15 minutes
  • Deterministic risk gates with the final say over any model output
  • A self-hosted, self-healing LLM gateway: ~10 s recovery after a forced browser crash (fault-injected)
  • Scored confidence: a value pinned at 0.90 in 16 of 33 cycles became a scored probability with 7 distinct values in 13 cycles
  • Multi-agent AI coding (e.g., Claude Code) with independent review passes

RelatedLLM-assisted tradingPrediction-market terminal

Web3 & Collectibles

On-chain engineering, with a trader's read of the market.

I build on Solana, Sui, EVM chains and Zcash: trading engines, mint automation and payment services. I also work the other side of the market, as a collab manager and ambassador on X and as a trader of NFTs and collectible Telegram numbers.

  • Low-latency NFT trading engines on Solana, Sui and Zcash
  • 28-network EVM mint automation with pre-signed, SNTP-timed sends (dry-run tested)
  • Smart-contract integration: Move calls on Sui, Anchor/Borsh instructions on Solana, ethers v6 on EVM
  • Exact on-chain payment math: matched the marketplace on 40 of 40 audited live listings
  • Isolated signing: a Unix-socket wallet service and AES-256-GCM key vaults
  • Collabs, allowlists and mint promotion as @drop_radar on X

RelatedZcash trading systemSolana & Sui engines28-network mint engineAllowlist app & art engine

03Demos

Two demos, built from scratch for this page

Plain JavaScript and CSS, no libraries. The first is a simulated market terminal; the second explains how a mint is prepared before it opens. Both pause for reduced-motion settings.

Simulated market terminal demo with a price chart, an order book, a trades tape and a latency readout. All data is randomly generated in the browser and is not real market data.

Market terminal

SIM-BTC / USD

Simulated data — UI demo

Paused

A browser-side simulation of the interface pattern behind my real prediction-market terminal.

Every price, order and latency figure in this panel is generated in your browser; nothing connects to a market. What is real is the pattern: updates are dispatched on the event loop instead of a fixed repaint timer, and chart history lives in a bounded ring buffer.

The real terminal, measured

  • Median server-side feed-to-browser dispatch: 101.5 → 0.35 ms
  • p95 dispatch: 103.6 → 1.3 ms
  • Chart work cut 6.5× with a ring buffer
Read the case study

Animated explainer of the mint engine timeline, from pre-arm at T−20 seconds to sending signed bytes at T−0. It shows process steps, not live data.

T-minus: the work happens before the mint opens

How the 28-network mint engine turns the opening moment into a single send.

Animated explainer — timings from dry runs, not live data

  1. T−20 sPre-arm

    State reads

    Read supply, wallet limit, price, balance and nonce in one batch.

  2. T−20 sPre-arm

    Simulation

    Simulate the mint at the opening block, so a transaction that would fail is never sent.

  3. T−20 sPre-arm

    Gas pricing

    Price gas ahead of time, with a cap relative to the mint's value.

  4. T−20 sPre-arm

    Signing

    Signing happens in an isolated signer process; the output is ready-to-send bytes.

  5. T−100 msHold

    Spin, don't sleep

    Spin the last 100 ms on SNTP-corrected time. Two time services must agree within 1.5 ms. Sleeping had left 2 of 6 windows 5–10 ms late.

  6. T−0Fire

    Transmit signed bytes

    Race the signed bytes to every sequencer address over warm HTTP/2.

12/12dry-run windows sent within 1 ms of target

Step 1 / 6

Everything slow is done 20 seconds early. At the opening, the engine only has to send bytes it has already signed. Dry runs: sends were recorded, not broadcast. No competitive mint win is claimed. Mint engine case study

04Selected work

Eight systems. Real numbers, honest labels

Trading engines, real-time terminals, AI tooling and web apps I designed, shipped and ran. Figures come from each project's own measurements, and labels such as backtest, estimate, dry run and demo account mean exactly that. Marketplaces and collections are not named.

  • Web3
  • Trading
  • Web

2026 · Ran in production

Low-Latency NFT & Collectibles Trading System (Zcash)

Sees a new listing in ~100 ms and pays at most once, even through a crash.

true detection lag (median)
3.5–17.5 s → ~100 ms
clean responses at 40 req/s
5,952/5,952
payment proof time, warm wallet session
17.8 → ~3.4–3.6 s
Read the case study
median new-listing detection
320 → 81 ms
true detection lag (median)
3.5–17.5 s → ~100 ms
clean responses at 40 req/s
5,952/5,952
payment proof time, warm wallet session
17.8 → ~3.4–3.6 s
bot and wallet tests
308 + 97

Problem

On a thin NFT and collectibles market, the first buyer to see an underpriced listing wins. The bot's poll loops drifted into lockstep, a CDN edge cache was quietly serving listings seconds old, and a payment path that moves real money had to survive a crash at any point without ever paying twice.

Approach

  • Replaced drifting per-connection poll loops with one drift-free scheduler at a 5× poll rate over warm HTTP/2.
  • Traced stale listings to a CDN edge cache and added per-request cache busting on every decision read.
  • Load-tested the feed instead of guessing a safe rate, then ran at a sustained 40 req/s.
  • Moved all signing behind a Unix-socket wallet service that serializes every spend: the payment is journaled before broadcast, and an uncertain send is never resent.
  • Kept the proving key warm in a persistent wallet session, and operated everything from a token-gated real-time console over SSE.

Results

  • Median detection 320 → 81 ms (p90 787 → 145 ms).
  • True detection lag 3.5–17.5 s → ~100 ms median, verified over 12,000+ polls with zero cache hits.
  • 5,952 of 5,952 clean responses at 40 req/s; one host move then cut p50 feed request latency from ~150–170 ms to 58 ms.
  • Payment proof time 17.8 s → ~3.4–3.6 s, with the wallet ledger reconciled to the zatoshi.
  • 308 bot tests and 97 wallet tests.

Caveat

These are latency and correctness measurements, not trading returns. The marketplace and collections are not named.

Data flow of the Zcash trading system: a drift-free scheduler polls the listing feed over warm HTTP/2, the pricing engine decides, and a separate Unix-socket wallet service journals and signs each payment exactly once.
Open the full-size diagram (opens in a new tab)

TechNode.js · HTTP/2 · Zcash light client · Unix-socket wallet service · PM2 · Server-Sent Events

  • Web
  • Trading
  • Web3

2026 · Private web terminal

Real-Time Crypto Prediction-Market Trading Terminal

A private terminal for 5- and 15-minute BTC prediction markets: server-side signing, no wallet pop-ups.

p95 dispatch
103.6 → 1.3 ms
less chart work with a ring buffer
6.5×
advisory model log loss (coin flip: 0.69)
0.48–0.49 → 0.27
Read the case study
median feed-to-browser dispatch (server-side)
101.5 → 0.35 ms
p95 dispatch
103.6 → 1.3 ms
less chart work with a ring buffer
6.5×
advisory model log loss (coin flip: 0.69)
0.48–0.49 → 0.27
automated tests
154

Problem

Five-minute markets move in seconds, but a wallet pop-up on every order and a UI that repainted on a fixed 100 ms timer added delay before a trader could even act. The advisory model also assumed the wrong settlement rule.

Approach

  • Moved signing and pre-quoting to the server, so orders execute from any browser with no wallet pop-up; a warm quote is reused only while it is under 500 ms old.
  • Replaced the fixed 100 ms UI timer with event-loop dispatch, serialized once for all viewers, and bounded chart history in a ring buffer.
  • Made every order money-safe: request IDs bound to the full order, the signature journaled before broadcast, and uncertain sends reconciled from wallet history, never re-signed.
  • Measured that settlement uses a trailing 60-second average and rebuilt the advisory model around it.
  • Shipped through SHA-256-verified releases that restore the previous version automatically if a health check fails.

Results

  • Median server-side feed-to-browser dispatch 101.5 → 0.35 ms; p95 103.6 → 1.3 ms.
  • Chart work cut 6.5×; bytes per client 11,630 → ~7,850.
  • On the newer half of 1,400 settled rounds, log loss fell from 0.48–0.49 to 0.27 (coin flip: 0.69).
  • 154 automated tests; the service runs in ~39 MiB of memory.

Caveat

The probability model is advisory. Live, over 13 rounds, it matched the market's own prices (log loss 0.521 vs 0.523) but did not beat them, and no profit is claimed. Dispatch figures are local server-side overhead, not network latency.

Data flow of the prediction-market terminal: market, oracle and exchange WebSocket feeds enter a Fastify server, which dispatches updates to the React client over Server-Sent Events and signs, journals and broadcasts orders server-side.
Open the full-size diagram (opens in a new tab)

TechNode.js (Fastify) · React · Server-Sent Events · WebSocket · Solana · nginx

  • AI
  • Trading

2026 · Demo account

LLM-Assisted Position-Trading System (Crypto)

The model proposes; a deterministic risk engine decides. Run on a demo account.

characters per prompt
~30,000
stalled cycles traced to a supervisor deadlock, then fixed
69 of 97
tests passing on dev and server
212
Read the case study
one multi-timeframe decision per cycle
15 min
characters per prompt
~30,000
stalled cycles traced to a supervisor deadlock, then fixed
69 of 97
tests passing on dev and server
212
one-hour windows reaching the minimum target (postmortem)
0 of 63

Problem

A language model can read multi-timeframe market context well, but it can also be wrong, slow, malformed or silent. Letting it place orders directly was never an option, even on a demo account.

Approach

  • Every 15 minutes the model receives a ~30,000-character prompt built from completed M30, H1, H4 and D1 candles and returns one position decision as strict JSON.
  • A deterministic risk engine has the final say: horizon limits, structural invalidation, reward/risk of at least 1.8 after costs, spread and quote-freshness checks. An AI failure produces no trade.
  • Fail-closed execution: two-key arming, an OS-level single-instance lock, send-time quote revalidation and no blind resubmission of ambiguous sends.
  • Built the self-hosted, browser-automated LLM gateway it calls: strict-JSON extraction with a schema-reminder retry, typed failure codes and a self-healing supervisor.

Results

  • Found and fixed a supervisor deadlock that had stalled 69 of 97 cycles while health checks still read OK.
  • Gateway recovery in ~10 s after a forced browser crash (fault-injected in production); answer extraction identical in 6 of 6 runs.
  • Turned a confidence score pinned at 0.90 (16 of 33 cycles) into a scored probability with 7 distinct values in 13 cycles.
  • A quantitative postmortem showed why it kept holding: the minimum 60-pip target was reached in 0 of 63 one-hour windows.
  • 212 tests passing on both the development machine and the production server.

Caveat

Demo account only. The system executed no trades (every decision was HOLD except one SELL), so no performance is claimed.

The LLM-assisted trading loop: a prompt builder sends multi-timeframe context to the LLM gateway, the model returns a strict-JSON decision, and a deterministic risk gate approves or blocks it before any order is sent to the demo account.
Open the full-size diagram (opens in a new tab)

TechPython · MetaTrader 5 · pytest · Windows Server · Node.js/Puppeteer LLM gateway

  • Web3
  • Web

2026 · Dry-run tested

Multi-Chain NFT Mint-Automation Engine (28 EVM Networks)

Everything is done 20 seconds early, so the opening moment only transmits signed bytes.

EVM networks
28
pre-arm: state reads, simulation, gas pricing, signing
T−20 s
automated tests
68
Read the case study
EVM networks
28
pre-arm: state reads, simulation, gas pricing, signing
T−20 s
dry-run windows sent within 1 ms of target
12/12
maximum disagreement allowed between two SNTP time sources
1.5 ms
automated tests
68

Problem

On a 100 ms-block L2, a mint that opens at a known second is decided in milliseconds. Reading state, simulating, pricing gas and signing at the opening is already too late, and a server's own clock can't be trusted.

Approach

  • Pre-arms each drop 20 s before opening: state reads, a simulation of the mint at the opening block, gas pricing and signing.
  • Aims at true time: SNTP readings from two time services must agree within 1.5 ms, which corrected a measured 1–3 ms server clock lag.
  • Spins the last 100 ms on SNTP-corrected time instead of sleeping, then races the signed bytes to every sequencer address over warm HTTP/2.
  • Calibrated block-boundary timing with 86 zero-value self-transfers, about $0.17 in total.
  • Isolated signing in a child process killed on lock; a calldata validator refuses any transaction with the wrong contract, recipient, quantity or price.

Results

  • Every transaction sent within 1 ms of target in 12 of 12 dry-run windows; sleeping had left 2 of 6 windows 5–10 ms late.
  • One engine covers 28 EVM networks, each with RPC failover.
  • Building all four hedged send requests (every sequencer address plus the public RPC) takes 1.5–3 ms.
  • 68 automated tests and a one-command deploy that checks SHA-256 parity of every shipped file.

Caveat

Timing results come from dry runs (sends recorded, not broadcast). No competitive mint win is claimed.

T-minus timeline of the mint engine: at T−20 s it reads state, simulates, prices gas and signs; in the last 100 ms it spins on SNTP-corrected time; at T−0 it transmits signed bytes to every sequencer over HTTP/2.
Open the full-size diagram (opens in a new tab)

TechNode.js · ethers v6 · SQLite · HTTP/2 · AES-256-GCM key vault · systemd

  • Web3
  • Trading

2026 · Retired Sep 2026

NFT Trading Engines on Solana and Sui

Two chains, one rule: price it exactly, validate before signing, fail closed.

Solana buy path (estimated)
1.17 s → ~370–400 ms
audited live listings, payment exact
40/40
live-wallet simulations passed, nothing signed
7/7
Read the case study
Solana buy path (estimated)
1.17 s → ~370–400 ms
Sui purchase build, 5 → 0 RPC calls
~1,050 → < 3 ms
captured transactions rebuilt byte-identically
12/12
audited live listings, payment exact
40/40
live-wallet simulations passed, nothing signed
7/7

Problem

On Solana, the buy path waited on a hosted API and confirmed logs, so a measured attempt started 1.17 s after the listing. On Sui, every purchase needed five RPC calls to build, and in four collections every buy aborted on payment math.

Approach

  • Solana: subscribed to on-chain listing state and built purchases locally, with a transaction builder byte-identical to 12 captured marketplace transactions.
  • Solana: a pre-sign transaction validator, a simulated wallet-debit ceiling and stale-read rejection, so any doubt means nothing is signed.
  • Sui: carried on-chain object references forward from each transaction's effects and prewarmed function signatures, taking RPC off the hot path.
  • Sui: re-implemented fee and royalty rules in exact integer arithmetic, down to the smallest unit.
  • Measured instead of guessed: benchmarked 6 RPC providers over 5,770 signatures and sized concurrency from real bursts across 343,587 listings.

Results

  • Solana reaction redesigned from a measured 1.17 s to an estimated ~370–400 ms.
  • Sui purchase build ~1,050 ms (5 RPC calls) → under 3 ms (no RPC calls).
  • Payment math matched the marketplace on all 40 audited live listings, correcting aborted buys in 4 collections.
  • 7 of 7 live-wallet simulations passed with nothing signed; the Solana buyer carried 414 automated tests.
  • A package-lineage registry ended a 5-day listing blind spot after an in-place contract upgrade.

Caveat

The ~370–400 ms figure is an estimate summed from measured stages; no purchase was broadcast after that change. The Solana engine never completed a purchase (measured market conditions never offered a listing under its safe price ceiling), the Sui payment fix was verified by simulation and comparison, and both engines were retired in September 2026.

TechNode.js · Solana web3.js · Anchor/Borsh · WebSocket · Sui/Move · gRPC checkpoint stream

  • Trading
  • Web

2026 · Personal research tool

Equity-Market Screener & Backtesting Suite

Records the whole market board, then works hard to prove its own signals wrong.

symbols per snapshot, 5-level order books
~750–1,150
out-of-sample AUC
0.61–0.67
net 10-session ETF edge, backtest (t=7.6)
+2.16%
Read the case study
symbols per snapshot, 5-level order books
~750–1,150
snapshot cadence
75–90 s
symbol-days backtested
230,000+
out-of-sample AUC
0.61–0.67
net 10-session ETF edge, backtest (t=7.6)
+2.16%

Problem

Trading ideas that look great on daily closes often fail on fills, fees and the benchmark they are measured against. The goal was a screener that records the whole market and tests every idea against all three before it is trusted.

Approach

  • Recorded the whole market board (~750–1,150 symbols, 5-level order books) every 75–90 s into compressed snapshots.
  • Ran 15+ backtesting studies over 230,000 symbol-days, plus order-book replay for intraday signals.
  • Wrote a logistic regression from scratch in NumPy, trained on the older two-thirds and scored on the newest third of 101,000+ observations.
  • Served it through a dependency-free Python server and a 9-tab right-to-left (Persian) dashboard in vanilla JavaScript.

Results

  • Out-of-sample AUC of 0.61–0.67.
  • Caught two backtest biases (~47% of signals unfillable; a skewed benchmark) that erased an earlier +3.3% stock edge.
  • The same signal on ETFs kept a +2.16% net 10-session backtest edge (t=7.6).
  • Tested 128,324 symbol-days of same-day trading rules: every one lost after fees.

Caveat

Backtest results, not realized returns. About 89% of the ETF sample comes from 2025–26 and the prior year did not confirm the edge, so it remains under live review. Decision support only: there is no order-submission path.

TechPython · NumPy · threaded HTTP server · vanilla JavaScript RTL (Persian) dashboard

  • Web
  • Web3

2026 · Pre-launch

Community Allowlist Web App & Generative Art Engine

A deployed community allowlist app and a pixel-art engine with zero dependencies.

automated tests
39
SVG per character
~5 KB
X API spend, by design
$0
Read the case study
automated tests
39
dependencies in the art engine
0
SVG per character
~5 KB
animated character GIFs generated
8
X API spend, by design
$0

Problem

A new NFT collection needed an allowlist campaign that verifies real X accounts and wallet addresses without a paid API tier, plus a full set of animated art and social assets.

Approach

  • X OAuth 2.0 PKCE login with the narrowest scopes and the token revoked right after identifying the user, plus hand-written OAuth 1.0a signing.
  • EIP-55 address validation on a self-implemented Keccak-256, checked against Ethereum test vectors.
  • Referrals that pay once, a live points leaderboard, per-IP rate limits and Origin checks on every write.
  • A dependency-free pixel-art engine with hand-rolled PNG and LZW GIF encoders and compact SVG export.
  • Deployed behind Caddy with automatic TLS as a sandboxed systemd service, with atomic releases and the last 5 kept for rollback.

Results

  • Built and deployed with 39 automated tests.
  • Generated the collection's animated characters and full social-media brand kit: avatar, banner, social card and wordmark.
  • Zero X API spend: probing a zero-credit developer app showed which endpoints were free, and the app was designed around them.
  • Mobile-first join flow with 44 px touch targets and no overflow at 375 px.

Caveat

Pre-launch: the smart contract and full collection were not built, and there is no member traction to report.

TechNode.js · SQLite · vanilla JS/CSS · OAuth 2.0 PKCE · Caddy · systemd

  • Web

2026 · In production

Multi-Account Messaging Dashboard & Android Alert Client

One dashboard for several accounts, and bot alerts that reach the phone exactly once.

REST endpoints
70
automated tests
~390
Android dependencies SHA-256-verified
466
Read the case study
REST endpoints
70
automated tests
~390
repeat feed scan (~50× faster)
1,346 → 26 ms
Android dependencies SHA-256-verified
466
Android lint errors / warnings
0 / 0

Problem

Managing several messaging accounts meant juggling apps, and a fleet of trading bots needed a way to reach the phone that survives dropped connections without ringing twice.

Approach

  • A self-hosted dashboard over TDLib for multi-account community and channel management: 70 REST endpoints plus live WebSocket updates.
  • An in-memory mirror fed by push updates, so repeat feed scans skip the slow path.
  • Crash-safe atomic writes (temp file, fsync, rename) for every store.
  • A native Android client on a certificate-pinned SSE stream with Last-Event-ID replay, and a deduplicated Firebase Cloud Messaging fallback.
  • Every alert stored under a stable ID: the first copy from either path wins, and a 50,000-ID window stops replays from ringing again.

Results

  • Repeat feed scans ~50× faster: 1,346 ms cold vs 26 ms warm, measured in production.
  • ~390 tests, and a lossless schema migration (1,543 of 1,543 and 454 of 454 records).
  • Three live accounts at ~155 MB of memory on a 1 vCPU server.
  • All 466 Android dependencies SHA-256-verified; lint reports 0 errors and 0 warnings.

Caveat

Personal tools: the Android app is sideloaded, not a Play Store product.

TechNode.js · Express 5 · TDLib · WebSocket · Kotlin · Jetpack Compose · Server-Sent Events · FCM

05Web3 & collectibles

Both sides of the market

On X since 2022

Web3 collab manager & ambassador

@drop_radar

Since 2022 I've run @drop_radar on X, tracking crypto and NFT drops, mints, airdrops and early-access campaigns, and partnering with NFT and crypto projects that are worth an audience's attention.

  • Collabs and ambassador campaigns with NFT and crypto projects.
  • Allowlist partnerships and mint promotion for upcoming drops.
  • Vetting before promoting: mint mechanics, supply and demand, checked with my own on-chain tools.
  • An engineer's view of launches: I have built allowlist, mint-automation and trading systems myself.
Follow @drop_radar on X (opens in a new tab)

Project teams: send collab inquiries by DM on X or Telegram.

Digital collectibles

Collectibles I trade

I trade NFTs and collectible Telegram numbers as markets in their own right.

  • Collectible Telegram numbers: traded by hand. I have built no bots or custom software for this market.
  • NFTs: priced with the same floor- and rarity-aware models that run inside my trading engines.
  • Exit first: my NFT engines cap every buy below what the market's bids would realistically pay for it.
Talk collectibles on Telegram (opens in a new tab)

06Skills

The toolkit behind the numbers

Programming & Web

  • JavaScript
  • Node.js
  • Python
  • C#/.NET
  • HTML/CSS
  • React
  • Express
  • Fastify

APIs & Data

  • REST APIs
  • WebSocket
  • Server-Sent Events (SSE)
  • GraphQL
  • gRPC
  • SQL/SQLite

Blockchain

  • Solana
  • Sui/Move
  • Ethereum/EVM (ethers.js)
  • TRON
  • Zcash
  • Smart-contract integration

AI & LLMs

  • LLM integration
  • Prompt engineering
  • Structured JSON output
  • Multi-agent AI coding

Trading & Collectibles

  • Algorithmic trading
  • Backtesting
  • Risk management
  • NFTs
  • Telegram numbers

Reliability & Performance

  • Idempotent payments
  • Write-ahead journaling
  • HTTP/2
  • Profiling

DevOps & Testing

  • Linux
  • Windows Server
  • Docker
  • nginx
  • systemd
  • PM2
  • node:test
  • pytest

Mobile & Automation

  • Android
  • Kotlin
  • Jetpack Compose
  • FCM
  • Puppeteer
  • Playwright
  • TDLib

07Timeline

From web apps to multi-chain trading systems

  1. 2016

    First builds

    Started building independently: web applications and browser automation.

  2. 2022

    Into Web3 markets

    Marketplace-monitoring bots for NFT and play-to-earn game markets. Started @drop_radar on X, working with NFT and crypto projects on collabs and allowlists.

  3. 2024

    Telegram automation and a first Android app

    Multi-account Telegram automation on TDLib, marketplace alert bots, and a first Android alert app.

  4. Feb–Sep 2026

    Multi-chain trading engines

    NFT trading engines on Solana and Sui: on-chain listing feeds, local transaction builders, exact payment math and fail-closed buy paths.

    Solana & Sui engines

  5. Mid-2026

    LLMs in the loop, AI-directed engineering

    An LLM-assisted position-trading system on a demo account with a deterministic risk gate, a self-hosted LLM gateway, a multi-account messaging dashboard, and multi-agent AI build and review workflows.

    LLM-assisted tradingMessaging dashboard & Android

  6. Sep 2026

    Terminal, mint engine, Zcash system

    A prediction-market trading terminal, a 28-network mint engine, a low-latency Zcash trading system, an equity screener, and this site.

    Prediction-market terminal28-network mint engineZcash trading systemEquity screener

08Contact

Let's build something fast and correct

Web builds, trading and data tools, or a Web3 collab: message me directly.

Case study
Esc