About

The name

Anlis is a contraction of Andrew Lishchuk — a nickname that eventually became a domain. The person behind it: a software architect and team lead who has spent the past nine years building systems that move money.

What I do

Trading and payment infrastructure: order-execution engines, exchange products, payment gateways — and the reconciliation layers that keep them honest. I’ve led teams doing this work, and I still design and build it myself.

The path

• Kalatori (2025– · open source) — architect and lead developer of an open-source payment gateway daemon: a Rust service that lets merchants accept crypto payments non-custodially. I designed its current architecture — a chain-agnostic core spanning Polkadot’s Asset Hub and EVM chains like Polygon, database-coordinated actors, an HMAC-signed merchant API, and invariants enforced at the database level. It grew from a single-chain prototype through a ground-up rewrite into a public-beta gateway.
• CoinLoan / Zent / Clapp (2020–2025) — full-stack developer, then trading team lead at a fintech. Built the Rust trading stack: a unified CEX-API library, a TWAP execution service with millisecond-level triggers, the CoinLoan Exchange product, and the Clapp exchanger engine. Python when it made sense, Rust when it mattered.
• NLK Agency (2017–2020) — full-stack developer and team lead of a small web agency. Django, aiohttp, client sites — and the early lesson that shipping is a team sport.

Side projects

Rust tools I built for myself and published:

• historia — event-driven, made simple: describe your events once, and the plumbing is free.
• avahi-helper — makes .local hostnames resolve across your network, discovered from your Caddyfile and Docker labels.

What I care about

• Invariants over vibes. If the database can enforce a state transition, don’t trust application code. (Kalatori’s invoice and payout lifecycles are SQLite triggers for a reason.)
• Docs and process that outlive the author. Release automation, changelog pipelines, task templates, spec frameworks — I’ve built these for my teams because good process scales better than memory.
• Boring decisions. The architecture that ages well usually looks unexciting in review.

These days I’m most interested in the space where engineering meets the business — how teams make technical decisions, how process scales (and where it breaks), and how hiring shapes what a team can build. Writing here is how I think it through.

Elsewhere

• LinkedIn — the full-CV version of this page
• Codeberg — where my own projects live
• GitHub — where Kalatori’s development happens
• andrew@anlis.dev — the direct line