ilya
doronkin.
AI Automation Engineer. I design agent-driven AI systems that cover the work of a whole team on their own: finance, analytics, CRM, websites and content production for one non-profit.
The problem I solve
«Our data and processes are spread across a dozen systems, and there is no headcount or budget for a team. We need all of it to work, to run by itself, and to be visible in one place.»
Most of this work I do together with AI agents (Claude Code, Pi, and Hermes, my own harness). What I bring is designing the system, wiring unrelated services together, setting the task and checking the result. Every number in this portfolio is verified against a real artefact.
A note for an English-speaking reader. The client is a Moscow foundation that helps people living with HIV and runs prevention programmes, so every interface, document and screenshot here is in Russian; the captions explain what you are looking at. A few local terms that come up below: an information line is the foundation's helpline, the pharmacy is a programme that hands out medication, outreach means testing done off-site rather than in the office, and clients are identified by a pseudonymous code, not by name, which is why questionnaire data can be analysed at all.
All of the money
on one screen
The foundation's money lived in eight systems: two banks, a payment provider, the CRM, web analytics. Management could not answer the two questions that matter, how much money is there right now and how long will it last.
I designed a single data layer and pulled everything into a live dashboard: turnover, balance, runway (how many months the money covers), a 30, 60 and 90 day forecast, and risk flags. Strictly read-only.
python · rest api · alfa-bank · t-bank · cloudpayments · yandex metrica · google search console
the dashboard answers both «where did the money come from» and «what did it do»
Day-to-day operations
moved into Telegram
Tasks, volunteer shifts and the weekly helpline rota lived in group chats and Google Sheets. I built a bot that became the single entry point: a forwarded message turns into a task, shifts are booked with buttons, and the rota is calculated automatically.
The bot writes into the same database as the web board, so there is one source of truth. Onboarding is invite-only, with three cohorts of volunteers and staff.
Privacy: nothing about the people the foundation helps, and no HIV status, ever reaches the bot. That data stays in the CRM.
- 01One inbox for tasks — forward a message, get a card with an assignee and a due date
- 02Shifts and swaps — «I can't make it» sends a request to colleagues and waits for someone to confirm
- 03Helpline rota — a weekly rotation of counsellors from Saturday to Friday, with a search for cover
- 04Cron reminders — deadlines, overdue items, a weekly digest for the coordinator
node.js · telegram bot api · long-poll · sequelize · no third-party libraries
The whole organisation
as one graph
The website's code, the documents and the services are collected into a navigable knowledge graph: communities are detected automatically, links between documents and code are visible, and the graph can be queried in plain language.
The graph is a working tool: the site audit and the redesign planning were both built on it. A second graph indexes the archive itself, 4.6 GB of documents, so an agent finds the right file through the graph instead of walking folders. It is rebuilt every night; over the summer it grew from 1,303 nodes to 1,681.
● real screenshot · interactive graphify viewer · 2026-07-21
I sorted the CRM
into what lives
and what is dead
The CRM had grown: testing, the helpline, support groups, medication. There were many variants of the intake questionnaire, but only one was alive. Since March 2024 counsellors had been filling in a single form of 27 questions; the other forty fields had been empty since April of that year, while the documentation still described them as current.
I checked the questionnaire against production data, removed four dead form variants and 25 dead questions from the reference table, fixed a duplicated question about education, and reworked the live form on the counsellors' notes. Then I split the scenarios by where the work happens: off-site testing got its own short questionnaire, its own table and its own report. The form that is called «universal» stayed what it actually is, the office one, even though its name does not say so.
Along the way I closed holes in access control: six routes accepted requests without authentication, and one of them handed the logins and names of every staff member to anyone who knew the address. I merged the medication programme into a single dispensing table, made permission changes apply without re-login, and made it possible to assign a staff member to several locations at once.
privacy: real questionnaires and HIV data never appear in a portfolio. That is deliberate, not luck
Website redesign:
from prototype
to preview
The foundation's website had aged. I went the whole way: first a UX prototype of the home page built on one idea, one page and three routes (someone who needs help / a donor / a reader), then the design system, then a working build on Astro that lives on the closed preview at redesign.spid.center.
The donation page is designed around the question a donor actually asks, «where does my money go». Articles are carried over from the old CMS by a script.
astro · design system · figma · the «three routes» prototype, then a production preview behind a password
A school website
and its own CMS
instead of 2020 code
The site of the foundation's medical school for young doctors ran on Rails 6.0, unsupported since 2023, with a dependency lock from 2018 and a database schema untouched since February 2020. The editor typed into an admin panel that had neither drafts nor preview, so a typo went live the moment it was saved.
I rebuilt the site and the admin panel from scratch as one isolated Node service: Astro with server-side rendering, SQLite, 44 routes. Every item now has a draft and a published version, and the draft opens in a closed preview. The admin and editor roles are separated: an editor prepares and publishes content but does not manage people and does not delete records.
The new service never talks to the old Rails API and writes nothing to production. It lives on a closed preview behind a password and noindex; the live vera.school and its admin panel are untouched, and switching over is the foundation's decision.
- 01Access. Passwords hashed with scrypt, 14 characters minimum; only a hash of the session token is stored; every write requires a CSRF token and a matching origin; login is limited to eight attempts per 15 minutes. Sign-ins, publications and deletions are written to an audit log without payloads or passwords.
- 02Images. An upload is checked for its real format, stripped of metadata and rebuilt as AVIF, WebP and JPEG in three widths — 705 such files on the site. The CMS keeps up to five previous versions of a photo with a one-click revert.
- 03Release and rollback. GitHub Actions builds an artefact, a release is switched on by a symlink, and rollback is the same symlink pointed back. Before every release the database is backed up with an integrity check; the last 14 are kept.
- 04Checks before release. Lighthouse mobile 96–97, accessibility 100, CLS 0, no axe violations, 31 Playwright scenarios, 14 Vitest tests, and a manual pass at 1440 and 390 px with the keyboard.
One story worth telling: photo uploads returned 502 with not a single error in the logs. Three image codecs were running in parallel inside the rendering process, memory reached the PM2 limit of 512 MB, the process restarted silently, and nginx answered 502. That is why the error log stayed empty while the draft still managed to save. I moved image processing into a separate short-lived worker and put the codecs in a queue: peak memory of the main process dropped to 122 MB, and a 4885 × 3258 photo now uploads in 7.7 seconds.
astro ssr · node 26 · sqlite · sharp · github actions · pm2 · nginx
The work of five specialists, covered by one person
A non-profit of this size has no analyst, no designer, no web developer and no sysadmin on staff, and no budget to hire them. I built a platform of skills for AI agents, where each skill is a separate job with its own access policy. Read-only by default for anything that touches money; secrets live in the system keychain, never in code.
claude code · python · rest api · read-only policies
I found why the site
was losing traffic
A full audit of UX, SEO, the donation funnel and the technical layer. The main finding: organic traffic from Yandex had collapsed, hidden behind growth in Google, with a diagnosis of the cause and a recovery plan. Separately, an audit of visibility in AI search (ChatGPT, Claude, Yandex) with semantic clusters. Generative engine optimisation is a skill few people have practised yet.
What came out of it is a road map: what to fix first, what will bring donations, what will bring reach. The same analysis repeats on any content-heavy site.
google search console · yandex metrica and webmaster · pagespeed / crux · knowledge graph
In progress and in production
- 01Hermes, a multi-agent harness — a personal project: 13 agent roles, routing by complexity, human-approval gates, memory, Telegram and Obsidian (2,483 notes). The engine is open source; the architecture and the wiring around it are mine.
- 02Design production with automation — building PDFs out of HTML and SVG plus scripting Illustrator: dozens of booklets, leaflets and posters without a designer on staff.
- 03Infrastructure migration — deploying front end and back end, DNS, object storage, a runbook, and a handover to a contractor with no downtime.
- 04Financial security — found and diagnosed a carding attack on the donation form and a leak of personal data, and wrote the plan to close both.
- 05An annual report without Readymag — the 2024 report was built on a paid platform that is hard to pay for from Russia. I am building the 2025 one as a hand-written landing page on my own server: no subscription, and full control of the layout.
details of any project on request, within the limits of the foundation's confidentiality
Read-only by default.
Secrets outside the code.
Never invent anything.
If automation is able to move money, it should not be able to. If the data is not there, say so instead of guessing. Fix the cause, not the symptom. These rules are the reason there has been not a single incident in all the time I have worked with live accounts.
Let's build
your system.
telegram — @dojdikkkkkk
github.com/dojdikkkkkk · work projects are private